I wonder how to version plugins.
There are plenty ways of versioning a software products but they're all 1-dimensional.
Are there best practices for 2-dimensional versioning which indicates both compatibility to the main application and compatibility to the plugin API?
Eclipse for example proposed a versioning scheme for which every plugin uses semantic versioning. Additionally there's a rule to distinguish between development streams by increasing the service number by 100. This ends in versions like that:
Plugin version v1.0.8 for Eclipse v3.1
Plugin version v1.0.108 for Eclipse v3.2
This seems a bit fishy to me. Are there better ways?
Why do you need to show the information about main application version in version of plugin? Does it help users to choose a suitable one?
I prefer put this information in a plugin name. For example, plugin-eclipse31-1.0.8 and plugin-eclipse32-1.0.8. You can put branch name (eclipse31 or eclipse32 in examples) in plugin version, to make things easier.
Related
We have IntelliJ project and module files checked into version control. They great, but if we switch java or android sdks, everyone needs to do something on their own machine (update the sdk, add it to IntelliJ, etc.).
I found http://leolabs.org/blog/making-intellij-portable/, which explains how to set up configuration paths in IntelliJ, which allows us to share things like SDKs. My current plan is to follow that guide and check the IntelliJ install directory into our version control so everyone can run it from there, and it will have sdks all set up.
The problem I see with this technique is then other options are shared as well. That's great for coding style (though you can make coding style project specific, so that's not a real win), but not as good for things like visible white-space.
So my question is: Is there a more granular way to share java and android SDKs and have IntelliJ correctly point to them? Thanks.
SDKs and Global Libraries are referenced in the project files by names, like 1.7 for Java or Android 4.2.2 Platform for Android SDK.
The easiest solution is to agree about the common names for the SDKs and ask all the developers to configure the SDKs using these names (needs to be done only once and when you have to switch to the new major version of the SDK).
This configuration allows the developers to have actual SDK installations in different locations and is also OS independent.
If you decide to share global IDE configuration files (like jdk.table.xml), all the team members will need to have SDKs installed in the same place and it will fail between different operating systems.
I recently switched from Eclipse to Netbeans 7.3 and experiencing a lot of quirks and i'm wondering if anyone else experienced them and/or got a solution. Because of these 'problems' i'm considering switching back to Eclipse again but i'm in doubt because NB has a lot of good things too !
These are the quirks:
when creating a new Java class, and make some typo's e.g. somewhere in a method, NB does not recognize / display the errors directly, but after a very long wait or a restart of NB.
This also happens to existing classes.
background scanning tasks is sometimes stuck at 100%
code completion does take forever. Don't even think about refactoring or renaming a class because it takes >3 minutes to scan the classpath (why, it's a new class for crying out load)
hot-deployment: changes are not always synchronized correctly with the (Glassfish) server.
Sometimes a complete undeploy and deploy is needed to reflect the changes made in the source.
NB manipules my pom.xml and glassfish-web.xml: it adds a deploy hint to the pom.xml and also changes or removes the context-root in the glassfish-web.xml. Please stop doing this!
Why o why can't i do a 'Fix imports' on my entire project. You can do a 'organize import' on the entire project, but this won't add the missing imports. See http://netbeans.org/bugzilla/show_bug.cgi?id=167031#c2
Running NB 7.3 on Windows XP, 3GB RAM, 2+GHz cpu
The project is a Java 7 maven project containing 12 modules / sub projects
I strongly recommend that you DO NOT attempt to install the ScanOnDemand plugin. It completely trashed my Netbeans, forcing me to use the Task Manager to kill the process. No existing projects were found; they were all listed as "unrecognized project; missing plug-in?". I had to re-install Netbeans.
One thing to look for is max heap allowed. Try adding "-J-Xmx2000M" to the Netbeans startup.
ref: Setting Heap Size
I suggest stick to your favourite IDE. Eclipse is still popular and Juno packages are doing good and Kepler is already available. You can try around latest packages.
IntelliJ IDEA looks better than other Java IDEs (light weight, faster, nice integration with SCM(source configuration) tools, possibility of easy cloud deployment, except that if you have freedom to choose your IDE whether you are part of a big/small teams, Otherwise there is no need to shift from one to other.
IntelliJ is the first IDE to give nice in-built support to Play framework
Google Android ADT is completely moving towards AndroidStudio based on community version of IntelliJ IDEA for faster and better GUI and app development.
As a Java developer it is not bad to try the other IDE to do some experiments or for any reason it strikes your mind.
Eg: Netbeans comes with sample apps in Java EE,Java7/Java2EE which looks better, nice examples for websockets, Servlet3.0, NIO examples etc,...but just try it or just ignore if it does not work. It is very easy to generate Entities from Database Tables, creating REST Endpoints in NetBeansIt may come with lot of in-built plugin-support for various java frameworks like RESTful webservice frameworks, JSF2.x, Primefaces3.x, SpringMVC, Struts but you may not sure to use the same version of framework. Some plugins may not work sufficient according to your business needs. Even if you okay with existing version it is not very friendly to develop Rich real-time UI development because Netbeans with Primefaces, instead you need to manually create XHTML templates.
Netbeans comes with nice support for Glassfish and tomcat, (other servers I am not sure but support is in-built). You can remote deployment with ease. Netbeans learning tutorials on JavaEE nice for beginners in the subject.
Netbeans also available as zipped bundle, hence no need to install even on Windows machines.
Eclipse has got better support with Java RoboCode learning tool (initiated by developed by IBM long ago.).
Also Netbeans comes with nice support for HTML5, Groovy, PHP, C++ as well (according to posts by users community, because I did not use them).
For the last few years, we've used m2eclipse without issue, however it seems that the "new" version (ie. m2e) has broken backwards compatibility - something that I really hope that I've just misinterpreted.
My problem is this: I'd like to be able to build my existing project with the minimal amount of fuss. I don't have the time to write connectors for the 3 plugins that don't have them - my understanding of 2 of them is quite limited in the first place, and I have no understanding of the Eclipse plugin mechanism - but I'd still like to be able to use Eclipse to build the project.
Can I achieve this without reverting back to the old (working) version m2eclipse?
Am I correct in my understanding that there is no way to upgrade without having a connector for each plugin?
It seems as if my understanding was correct if this blog post is anything to go by:
http://grumpyapache.blogspot.com.au/2011/08/mess-that-is-m2e-connectors.html
M2E can invoke a plugin as part of the automatic build process if, and only if, there is a connector for the plugin, or you specially configure the plugin
... which means that:
You can no longer use your own plugins in the Eclipse automatic builds, unless you create a connector for the plugin, or create a project-specific configuration
The post goes on to list the issues with this approach. These are many of the same issues I have with the approach.
RANT: So there you have it - the m2e approach does suck as much as I feared it did! I was beginning to think it was just me!
Within the context of upgrading plugins explain how to resolve plugin dependencies when NetBeans user interface's reports specific missing dependencies, yet these do not resolve with a google search or are unmentioned in the netbeans FAQ.
The practical example leading me to ask this question was when I attempted to install an in-development-plugin org-netbeans-modules-htmlprojects.nbm. It requires General Queries API v1.24 and I have v1.19.1.
Have a look at the bug report that mentions the nbm, it's for version 7. This also means that the mentioned version for GQA is also version 7 specific.
You best choice is probably to upgrade to version 7, it has some nice improvements over version 6.9 like HTML5 support. As a new install picks up the configuration of an installed previous version upgrading shouldn't be a lot of work.
EDIT based on restated question:
The short form: you cannot, it's not meant to work that way.
The long form: due to what happened here and the inner workings of Netbeans the error message was less clear than it could have been...
you downloaded a module for a higher version than the installed one
Netbeans' nbm deployment descriptor states dependencies on editor modules, not on editor versions - see inside the nbm which is actually a ZIP file Info/info.xml, manifest element, OpenIDE-Module-Module-Dependencies attribute.
Normally that error would not happen, as the version of the nbm will normally match the editor version, and the dependencies should either be satisfied or satisfiable by on-the-fly installation of the missing dependencies.
Wikipedia Comparison of revision control software User interfaces table shows Bazaar as not having Netbeans support. Is there development underway to provide this feature for Bazaar?
I don't think so. As mentioned in this comment of Bug #298025 (see also its little brother Bug 124436 in NetBeans issue tracker), Bazaar is not supported out of the box:
NetBeans team does not have resources to support every versioning system. But there is support for anyone who wants to write support for favorite versioning system. See http://versioncontrol.netbeans.org#community_support.
And I'm not aware of any third-party plugin (there is a Netbeans bazaar plugin on Launchpad but this looks like an empty shell).
There is a qbazaar plugin which seems to work nicely.
(It looks similar to the eclipse qbazaar plugin - it is a thin wrapper around qt frontends for the bazaar commands - very nice!)