Given a collection of aar files, How can I package them within a CAR?
Initial thought was to place each as a maven artifact into my Nexus, and explicitly add it as a dependency with the CAR pom but the CAR's pom GUI marks it as an error, and the developer studio actually deletes the lines.
I couldn't find a maven documentation for the car plugin other that that within the WSO2 manual, I thought there maybe a library option etc.
Is the bottom line that its not possible? Any other options?
Refer the documentation below, which explains packaging aar using developer studio.
https://docs.wso2.com/display/DVS380/Packaging+Artifacts+Into+Deployable+Archives
Related
I evaluate SOA products of wso2 for few weeks and there are some basic (and crucial to me) features which I cannot find/use or maybe it just does not exist. I want to make sure.
First of all, creating IDE support. As probably most of you know wso2 team delivers Carbon Studio which is quite a nice thing. Unfortunately when it comes to team work so often importing existing projects into IDE I hit a wall because:
1) If I use Distribution Project I'm required to commit .projects files which actually contains nature understand by Carbon Studio. It is acceptable but it is as well bad practice in my opinion.
2) If I use Maven then after import I'm going to loose project nature so plugins are not going to work without preparing .projects.
Am I missing something? I would like get rid of .projects and be able to use IDE on 100%. Is it possible? Can't it be generated or something. Normally plugins are trying to recognize file type and edit it with specified plugin. I understand that most Synapse configs (for example) are all XMLs but that is not a reason for me. Any way, does someone know some kind of solution?
Also Distribution Project cannot be build from command line if known maven repositories cannot deliver some artifact. I can write maven plugin to implicitly build each wanted artifact but it is not something I want to do if maven can do it for me. And I cannot use maven because after import I'll lose IDE features.
To me IDE is useless if I'm required to fix each project before actually importing it. Time is very precious.
The second important and unacceptable feature is importing jars into project when using, for example, generators. Why created project cannot be configured to use dependencies?
Robert
what is the developer studio version you use? From developer studio 2.0.0 there is a feature to import a carbon project. Then you don't need to commit the .project files.
Goto import --> WSO2 --> Existing WSO2 projects into workspace
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.
I want to start using maven in code I distribute but I can't find an efficient way to work with dependencies. Every new dependency takes me far too long to add.
As a simple example, I need to add Tomcat for compilation. Do I really have to manually trawl the repo in my browser to find the group-id, artifact-id and version number?
In every case it seems easier to find the non-maven downloads. I hope I've missed something obvious.
Do I really have to manually trawl the repo in my browser to find the group-id, artifact-id and version number?
No. Use a repository search engine. Some are mentioned here, more here. Some IDE also offer facilities to search and add dependencies (e.g. Eclipse with m2eclipse).
First of all, using some IDE really helps. Eclipse has m2eclipse plugin and if you define locations of remote maven repositories in your pom definition, you can add dependencies in its pom editor and it will automatically search the proper artifacts for you.
What is really helpful is using repository manager like Nexus / Artifactory, where you gather the most important maven repositories and then you don't need to declare particular repository locations in your pom definition for various artifacts, but everything will be proxied via Nexus.
I have some basic questions in eclipse plugin development, can anyone give clarification of the following questions,
When should we have to add features in our plugin development ?
What is the difference between feature and plugin.xml ?
Regards
Mathan
As mentioned in this thread:
A plugin is the eclipse "unit of work". An OSGi bundle that supplies a classpath and can contribute to eclipse through extensions.
A fragment points to a host plugin, and anything it provides (classpath, extensions, etc) are "sucked" into the host plugin. A fragment is also a more specialized OSGi bundle.
A feature represents a versioned collection of plugins, and is used for configuration management in eclipse. They can be deployed manually or through the update manager. If you want to deploy through the update manager, then you need to use features to represent your plugins.
So if you want to manage your plugin or plugins through the update manager, a feature is in order.
You can find more in the Eclipse Help:
Feature
Features do not contain any code.
They merely describe a set of plug-ins that provide the function for the feature and information about how to update it.
Features are packaged in a feature archive file and described using a feature manifest file, feature.xml.
Plugin
While features are organized for the purposes of distributing and updating products, plug-ins are organized to facilitate the development of the product function among the product team. The development team determines when to carve up program function into a separate plug-in.
Plug-ins are packaged in a plug-in archive file and described using a plug-in manifest file, plugin.xml.
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.