I use scalafmt plugin in my project, also I use scalafmt plugin for Intellj in order to format my Scala code.
Usually I use hot keys or run sbt scalafmt to formatting.
sbt.version=1.0.3
addSbtPlugin("com.geirsson" % "sbt-scalafmt" % "1.3.0")
Question:
Any advice how can I format code with scalafmt automatically on compile time?
UPDATE: just update the plugin version and use
scalafmtOnCompile := true
The answer below is outdated, it recommended using an alternative plugin, but now it's another way round, the official one is up to date and supports this feature out of the box.
From the scalafmt installation instructions for the plugin your use:
The sbt plugin does not provide reformat on compile settings. This gist shows a DIY plugin to enable reformat on compile. YMMV.
Why isn't that gist included in the sbt plugin? See #597.
I recommend you to try neo-sbt-scalafmt instead. It's generally more configurable and better maintained (the other plugin is abandoned, see the issue linked above). With this plugin you can turn on formatting on compilation with simple
scalafmtOnCompile := true
See docs for more options.
Related
I'm new to developing with Meteor and node-based apps.
I intend to create a PR for a problem i noticed in Rocket.Chat.
I git cloned the Rocket.Chat dev branch and made a change to a certain file:
https://github.com/RocketChat/Rocket.Chat/blob/develop/packages/rocketchat-oembed/client/oembedImageWidget.html
After that i ran the build-script successfully. My build started, but the change is not included.
Using the Chrome Dev Tools to inspect the change, i still see the original unchanged code.
I know it's a rather generic question and i'm sure the solution is kind of stupid, but any idea why ?
Thank you.
Kind regards
It looks like the file you modified is in the packages directory. This is dealt with differently.
Check the .meteor/packages files to see if this package is referenced, if it is, then it will install the package from the atmosphere package management system.
Here the steps required to make your changes work...
1) Edit the .meteor/packages file and change the reference to rocketchat:oembed to be simply oembed
2) Edit the file packages/rocketchat-oembed/package.js and do the same thing, change rocketchat:oembed to be simply oembed
Package.describe({
name: 'oembed',
version: '0.0.1',
summary: 'Message pre-processor that insert oEmbed widget in template',
git: ''
});
I think you can leave the directory names as is.
Meteor will now use your local package instead of going out to get the published version of it
In addition to #Mikkel's answer: I think you don't have to change package name, but just change its version. That should be enough for Meteor to rebuild this package from its source and you won't have any dependency issues.
I'm looking to remove/modify the autocomplete-plus package that is bundled together with atom on install.
After a while of struggling and failing, I come to the wisdom of stack-overflow for how I can either:
Modify behaviour of autocomplete-plus
prevent it from loading in the first place (i.e. remove it from the bundle)
The default packages are stored inside an asar file (i.e. Atom.app/Contents/Resources/app.asar on macOS), so it's highly impractical to tamper with its contents, not to mention that your changes are getting lost with each Atom update.
Since you haven't given us a reason why you would want to do that, there is no ideal answer to your question. Generally speaking, I think there are better alternatives:
Disable the autocomplete-plus package and install your fork as you would install any other package. The Atom API offers ways to disable packages programmatically, if you want your fork to handle this.
Build your own custom version of Atom that suits your needs. The default packages are listed as packageDependencies in package.json.
You can go to edit->preferences in the main menu, then check under 'packages' in the left-hand menu, search for 'autocomplete-plus' and then click on 'disable.
Is there any tutorial for the scripted plugin? Or maybe a new way to test plugins. I've found a tutorial that seems to be a bit old.
If I have to resort to Scripted, some questions that come to my mind:
Do I need to publish local my plugin before running scripted?
Can I refer to the version located in version.sbt from my tests?
For the record, I'm also using the cross-build plugin, so if possible, the tests would need to cover both 0.12 and 0.13 versions.
(Author of the linked testing sbt plugins here) There hasn't been major changes to scripted since I first wrote it, but I updated some of the details.
To test the plugin end-to-end, publishing locally I think makes sense.
See the updated post. You can pass version number as a property using scriptedLaunchOpts, and catch it with System.getProperty on the other side.
Eugene's answer is still relevant, but now, Sbt Plugins Testing has a proper documentation page in the official sbt documnetation site:
http://www.scala-sbt.org/release/docs/Testing-sbt-plugins.html
I downloaded someone's Drupal module (non core) I changed 1 function in there. I want my changes to not be over written by future module updates however still able to enjoy new updates.
How do you do this?
Thanks.
Generally if you have changed something, this means you are no longer having the version that can be maintained by the original developer (unless he applies the same change in his/her module).
But your options are:
making original module more flexible / expanding it: If you are familiar with the concept of Drupal's hooks, you can use them to build your own module and that way modify the way this module behaves. If it has no hooks in the feature you need, you can add them and ask author to merge the changes so when someone installs your module, it seamlessly integrates with his/her module.
using version control system: Alternatively you can check the updates in a different way, not from Drupal itself. You can use Git to download that module (drupal.org modules directory provides you with Git access), and use it to merge new versions to your code - then what you need is to be more familiar with Git versioning system.
Better to use hooks, but if there are no other solutions ...
Simplest solution : create a diff, apply a patch manually after module's automatic update.
http://jungels.net/articles/diff-patch-ten-minutes.html
Or You could edit try to edit Your module's info file, overriding the configuration of the version & the datestamp of Your module, to avoid automatic updates.
If your changed function fix a bug or something else, is better to create a path and propose your modification to the maintainer.
Otherwise, if you just modify the function to help your project, you should also create a patch and apply it after every update of your module.
Another solution, but less elegant, its to clone the module and create your own with the modified function (like this, your module can be out of updates).
I need to define a model for newly created projects in Aptana.
Basically, I want, anytime, when I create a new project, it adds some defined directories/files (not existing files, but new ones) to this project.
I'm not even sure it's possible.
Aptana doesn't appear to support that.
Maybe you can just create a small external sript to do it for you? Not the ideal solution, but better then none.
This might be a longshot, but it is worth mentioning. Since Aptana is based on Eclipse, you might be able to see how Eclipse would handle custom project templates. It appears that the easiest way to go about this is to actually create an Eclipse plugin that has a Template Wizard. IBM has a nice guide on how to use PDE to create a Custom Template. I am not sure if you will be able use PDE from within Aptana (you might be able to), otherwise, you might need to download a stock version of Eclipse, create the Plugin, then install it in Aptana.
Aptana is based on eclipse, so you could use a combination of Maven Archetypes and the Maven eclipse plugin to achieve this really easily.
Download and install maven
Create a basic maven project using the quickstart archetype, Archetypes are project templates used to rubber stamp new project structures. The quickstart is a very basic project template
mvn archetype:generate
generate the eclipse project files using the eclipse plugin. This will create the standard
mvn eclipse:eclipse
tweak the pom until and re-run step 3 until you're satisfied with the layout etc. You'll no doubt have to add configuration the eclipse plugin to add the correct build spec and project nature. If you open an existing .project file it will contain the values you need. you can see here how to add them.
once the project is set up to your liking you can create your own archetype out of it and use this to rubber stamp new projects in the future.
mvn:archetype:create-from-project
now you can run the generate again and can select your archetype from the list. If its not there, you may need to run this first to update the list of archetypes
mvn archetype:crawl
Open Source your archetype for others to use ;)
It's very simple in Studio 3. Try the following: http://wiki.appcelerator.org/display/tis/Creating+a+new+template#Creatinganewtemplate-Creatinganewprojecttemplate
Basically you create a .zip file of the project content, and then write a few lines of Ruby code to reference it.
Aptana uses (as I'm sure you know) its own 'new rails' project that gives you a variety of options.
I don't think it's beyond Will (the RadRails maintainer) to add a simple text field to that Wizard that would allow you to enter a command-line option parameter. He's always been very responsive with my previous bug and feature requests.
If you want to give that a try, and that works, then I would HIGHLY and STRONGLY recommend that you look into one of the new Rails features 'templates' in which you could make a generic template, then call it through the new input box. We use templates at my current job and they save us about 4 hours of work on each project. They are very easy to use...def...definitely.
If you can't wait for the input box, then you could always write the template then call it from within the command line (see
http://m.onkey.org/2008/12/4/rails-templates
for info about templates)
Unless RadRails three is light-years ahead of the latest release, though, you'll be missing out on a lot of very handy advantages of using a more community-supported solution such as VIM or TextMate. (I switched to VIM from RadRails about 4 months ago and have never looked back).
Eclipse has a Plugin Development Environment. If I'm not mistaken, you can also create project templates with it. Please try: http://www.ibm.com/developerworks/library/os-eclipse-pde/