I am developing several little plugins for Eclipse. Each one having it's own name, view and icon.
I am now having them in separate projects and as I am reviewing my code, package structure etc. I asked myself: Is it possible to bundle them all in one project called (for example) Plugins or does each one has to have a separate project because of plugin.xml, manifest.mf etc.
I know, each plugin needs to have these files, but can there be more then one plugin in them?
Technically it is possible using bnd-tools way of plugin creation but not via PDE. But if you want you can migrate PDE plugins to bnd. If you are interested check http://bndtools.org/
Related
I am building an eclipse plug-in project that acts as a front end. I also have a separate eclipse project that runs as a backend. Right now I can run each of them separately and they communicate just fine using sockets.
I would like the plug-in to create the major components of the back end when it starts but also keep the two projects separate so that I can use other editors to communicate with the back end. So, I added the back end eclipse project to the build properties of the plug-in project and I added some code from the back end driver to the plug-in activator's start(). However, when I run the plug-in project I am getting class not found exceptions for all back end references. It appears to compile fine, but I can't run it. I do not do anything to the MANIFEST.MF file in the plug-in project.
How does one add a second java project to an eclipse plug-in project?
There are several ways you can do this, going from best and most difficult to worst and easiest:
(1) Use a build tool (such as the built-in ANT, or tycho, or (as I'm sure there are) some other). This is by far the best solution, but is quite a bit more involved than the next 2.
(2) Convert your non-plugin project to a plugin project and add it as a plugin dependency in your plugin settings file's dependencies tab
(3) Export your non-plugin to a new .jar in your plugin project directory (e.g. $project_loc/lib/something.jar); go into plugin settings (plugin.xml) and include it in: The Build tab under binary build, and the Runtime tab under Classpath. (Or edit the corresponding entries in manifest.mf and build.properties)
For most cases I'd recommend approach (1); look up a few tutorials online, there are plenty. (3) is the quick-and-dirty non-flexible workaround to your particular situation, good for nothing other than seeing if it actually can run. (2) is somewhere in between -- obviously not ideal, but not as bad as 3.
I want to deliver a single .jar file to my clients, but my project is currently built with Maven, and I have several modules that generate a single .jar each.
I know nesting different .jar files is not a great idea, so I am not sure how can I achieve this.
Any ideas?
If you really want to go this direction, there are several ways to do that:
with the Maven Assembly Plugin and maybe the jar-with-dependencies predefined assembly descriptor (that will unpack dependencies)
with the Maven Shade Plugin (similar to the above one but gives more flexibility)
with the Maven One-Jar Plugin (that uses One-JAR and its custom classloader to allow nesting of JARs)
Depending on your exact requirements and constraints, you might prefer one or the other.
First of all, ask yourself if you have a really good reason for packaging your application and all of its dependencies in to a single jar. I haven't found a very many good reason for this at all (with most reasons being related to organizational policy foolishness or just plain ignorance). The way to go is to keep libraries in their own jars and supplying a .zip/.tar.gz containing all of your libraries and your application with either
An executable .jar with the
classpath setup appropriately in
your MANFIEST.MF file
a .bat/.sh
script that invokes java and builds
an appropriate classpath based on
your deps
Conversely, use JNLP (better known as Java Web Start).
If you really want to have maven bundle all of your dependencies and your application under a single jar, what you want to use is the "jar-with-dependencies" predefined assembly. The maven assembly plugin usage page also shows how you might this up as well.
You can try Maven Shade plugin too.
http://maven.apache.org/plugins/maven-shade-plugin/
General instructions on how to use the Shade Plugin can be found on the usage page. Some more specific use cases are described in the examples given below. Last but not least, users occasionally contribute additional examples, tips or errata to the plugin's wiki page.
In case you still have questions regarding the plugin's usage, please feel free to contact the user mailing list. The posts to the mailing list are archived and could already contain the answer to your question as part of an older thread. Hence, it is also worth browsing/searching the mail archive.
If you feel like the plugin is missing a feature or has a defect, you can fill a feature request or bug report in our issue tracker. When creating a new issue, please provide a comprehensive description of your concern. Especially for fixing bugs it is crucial that the developers can reproduce your problem. For this reason, entire debug logs, POMs or most preferably little demo projects attached to the issue are very much appreciated. Of course, patches are welcome, too. Contributors can check out the project from our source repository and will find supplementary information in the guide to helping with Maven.
Actually, nesting .jar files is not possible. A jar can't have other jars in it.
.war and .ear files can contain jars, and that's a good solution if you're delivering a J2EE application.
If your app is just J2SE, however, I recommend looking at the Maven Assembly plugin. As the name implies, it allows you to create a single binary distribution of your build.
Can I make a single maven project that can be included as a dependency (to reference Java classes inside) and executed as a plugin?
I'm working on a library to help with hosting GWT on a LAMP stack. For someone to use this, they need to extend some Java classes (so it must be a dependency) and they need to invoke a maven plugin (so it needs to be a plugin). The plugin code references the same Java classes, so if they are seperate projects, the plugin one must depend on the library one.
As is, I have the library as a normal maven project, and the plugin as a maven plugin that depends on the library. This means that to do a release, I have to release two different artifacts, and the dependent project must update both version numbers for both artifacts. It'd be nice to have a single project.
You'd be better of by doing the following
project for the jar, Foo:Foo.jar
project that uses Foo:Foo.jar as a
dependency that builds the plugin
Maven parent project that
builds 1&2
The directory structure would look like this
\project\pom.xml
\project\foo\pom.xml
\project\foo\src\main\java\foo.java
\project\plugin\pom.xml
\project\plugin\src\main\resources
\project\plugin\src\main\java
From \project you can do a mvn clean package to build \project\foo\target\foo.jar and \project\plugin\target\plugin.jar
Hope this helps.
If you create a maven plugin it still has a artifactId/groupId/version. There's no reason it can't be references both in your section and in your section. On the other hand, if thats ugly, why not just make a library with the common code that both your main project and your maven plugin project depend on?
EDIT:
Sorry, wasn't clear on the second part. Look into composite maven projects, where there is a top level pom that defines a number of child modules. In this case, the maven plugin and the common library code could be separate children producing separate artifacts, but you only need one version number and one release command executed from the top level. I haven't done this but there are any number of open source projects that do. its often used as an idiom to put testing code into a single module that can be referenced by all the others, without having it go out in any distributable jar.
The best practice is to not do what you're suggesting. Examples of this include PMD, BND, JUnit/TestNG, and so on - no serious projects seem to package the maven plugin with the library proper.
One way to get both alternatives is to use maven assemblies to have two seperate maven projects for each the library proper and the plugin and then a separate packaging as a jar containing the classes from both.
I have a plugin for an RCP app that uses BIRT. I have a target for building my app which contains only the plugins/features that are required. I recently updated the BIRT plugin versions in my IDE, which created an incompatibility in the design files with previous versions of BIRT. I have the old version of BIRT in my target and need to update to the newer plugins.
In the past I have manually updated plugin jars in the target, but BIRT is a complicated platform with dependencies out the wazoo. Is there any utility or way of organizing my target differently that will make this easier to control in the future?
I would recommend to keep all components separately and not copy them into a single folder. You can use Target Definition editor (see File / New / Other... / Target Definition). So, after downloading all the pieces, you can unpack them locally and assemble your Target Platform using Target Definition editor.
You can also do the same using Window / Preferences / Plugin Development / Target Platform preference page. There you can select previously created target definition or specify base Eclipse install and then use "Add..." button to add additional components from local folders or remote sites.
Also, as far as I know the PDE team is currently working on expanding Target platform support in Eclipse 3.5. I think they are planning to allow to select Target Definition per-launch configuration and per-project.
Im not sure if i understand you right, so please let me know if not.
When i use third party libraries, i create a plugin for every single one.
Example:
xstream library:
Import the jars (also the source code)
Add the jars to the MANIFEST
Bundle-ClassPath
Add all xtream packages to the
MANIFEST Export-Package
When a plugin needs the code of the xstream library it has to depend on the xtream plugin. Because the packages are public, every plugin can use the source code of it.
When a new version of xtream is comming, you only have to update the jars and not the dependend plugins. Sometimes you have to update the export packages of the third party plugin.
All depended plugins you dont have to change.
We have a Java codebase that is currently one Web-based Netbeans project. As our organization and codebase grows it seems obvious that we should partition the various independent pieces of our system into individual jars. So one Jar library for the data access layer, one for a general lib, one for a specialized knowledge access, etc. Then we'd have a separate project for the web application, and could have one for a command line tools app, another web app eventually, etc.
What is the recommended practice for doing and managing this? Is it Maven? Can it all be effectively done with just Netbeans alone by simply creating individual projects and setting the dependecies of one project on the jar files of the others?
I'd agree with SteveG above on using Maven2 to help you modularise your code base, but I'd use Nexus as the local repository for Maven instead of Archiva. The guys at Sonatype also have an excellent (free html/pdf) book on how to use Maven, Nexus, and integrate it into IDEs.
Be careful on how you decide to partition up your projects, though. There's no sense in over-complicating your dependencies just for the sake of it.
I would definitely say check Maven(2) out. It is very good for doing this sort of thing. You can define individual models and version then very easily. Netbeans also does a decent job of integrating with.
Also I suggest you set up Archiva which will let you be dependent upon binaries of other artifacts that your company generates internally. This also acts as a proxy and will keep a local copy of any external dependencies your projects might have so its very quick to get the new versions internally.
I would create ant scripts to build the pieces and for deployment. Then you are not depending on your IDE for build/deployment.
It sounds like your code is getting to the point where you're graduating from the WAR approach and have entered into the EAR level.
An EAR is just another archive that contains all the other JARs and WARs that get combined to create an application. There are four types of modules that can reside inside it, Web, EJB, Connectors and Utilities. Most people only use Web and Utilities so they go with using the WEB-INF/lib approach.
But if you're starting to get a lot of interdependencies what you do create an EAR project and make your web project a child of it. Each Utility JAR which is just straight Java code used by other modules also becomes a child of the EAR. Finally in each of your projects there should be a META-INF/manifest.mf file that just has the name of the JARs that JAR/WAR depends on.
I'm an eclipse guy and most of this gets taken care of for you in eclipse, but I'm sure netbeans has very similar functionality.
Now the only problem is that you have to use a full Java EE server to deploy an EAR so I don't think you can use Tomcat if that's what you're currently using.