I would like to move specific declarations of plugin versions up out of the specifc poms into a higher pom. The idea is to centralize the versioning of the plugins just like I do with dependencies via the dependencyManagement element of the parent pom. Is there a way to do this?
pluginManagement
<pluginManagement/>
http://maven.apache.org/pom.html#Plugin_Management
Related
One thing that was great in maven was the ability to use the dependency management tags to make a pom.xml that specified what versions of dependencies to use. So when you made that a dependency and didn't include the exact versions of your other dependencies, it would use all the versions specified in your starter. This way you could have one pom of all the versions of your dependencies that are compatible with each other and tested. While still letting your modules only include the dependencies they actually needed.
Is there a way to accomplish this in nuget?
I was thinking of making a nuget that has all the dependencies with their versions in it to then have all the modules dependent on the one nuget. However, that would then make every independent module now have all the nuget packages instead of just the ones it needs.
Thanks in advance!
I have a small issue that is annoying me somewhat. We have built numerous commons libraries for all our applications deployed on JBoss/Wildfly. Some of those common libraries have dependencies to JBoss modules.
The common way for EAR and WAR files is to add a jboss-deployment-structure.xml to the archive, which contains a bunch of module-dependencies.
I have tried several times to add a jboss-deployment-structure.xml to my Commons JARs so that the WAR/EAR-archives that import them will automatically see the dependencies the JAR has as it's own, however, no attempt of doing this renders the correct result.
Has anyone successfully managed to declare "transitive" dependencies in JAR-files packed inside of WAR-files without having to redeclare the same dependencies in the WAR-file's jboss-deployment-structure.xml?
Any examples would be greatly appreciated!
You can use the MANIFEST.MF to declare dependencies for a JAR. The line will look something like:
Dependencies: org.some.module, org.another.module
The Maven plugin maven-jar-plugin will add it for you as part of the build process.
Your best option is to create your own JBoss module to hold all your common JARs used by all your different applications. This module would have it's own module.xml file declaring the dependencies on the JARs contained within it and one any libraries on other JBoss modules. These custom modules can also be versioned and applications can also depend on specific versions.
I'm working one an Eclipse RCP project. Currently we create a dependencies plug-in project and put all jars libraries into that project and export all packages. This method will give a huge repo, thus we want to use Tycho/Maven and let it figure out the dependencies for us.
The first approach is removing dependenciec project and use p2-maven-pluging to transform existing jars libraries to p2 format repo. Install all libraries from p2 repos and add required bundle in Require-Bundle section in each MANIFEST.MF. This is a little bit tedious since in every project having dependencies in Require-Bundle, I have to manually replace it to corresponding bundle names. And in the end, the project build using Tycho could successfully run, but in Eclipse it gives me java.lan.NoClassDefFoundError: Could not initialize class X.
I think there are few configuration files, where Tycho depends on some of them and Eclipse depends on the rest, but I'm not sure what it is.
The second approach is removing all jars in dependencies project but adding them in Require-Bundle or Import-Package. However, both won't work since in Export-Package section Eclipse will complain these packages are not existed. Thus other projects depends on this dependencies project won't find those packages they need, which causing more errors in Eclipse.
Does anyone know the best practice to deal with this issue?
Update:
I'm using basically the first approach, but add dependencies in Import-Package in each project instead of Require-Bundle. This would eliminate the need to specify the specific bundle version, as long as they provide the same API and they are compatible, your application would work. So everytimes I update private p2 repository, I don't need to change MANIFEST.MF in each project.
The only MANIFEST.MF I need to manually add dependencies in Require-Bundle is a library developed by our self. Without it, Tycho won't fetch required dependencies from private p2 repository. If still get NoClassDefFoundError, try adding all plugins in Run -> Run Configuration .. -> plug-ins, it may help.
I definitely not apply your approach 1, with the mega-plugin of exports. There's a related discussion here: Handling non-OSGi dependencies when integrating Maven, Tycho and Eclipse
As a rule, use Import-Package instead of Require-Bundle.
To get bundles will appear in the Export-Package section Eclipse:
if they are non-Eclipse (maven libraries), then build the project and reference the libraries in the Eclipse runtime section.
if they are Eclipse dependences, they should be in your workspace or Target Platform.
More generally, it may help for you to define a Target Platform. You can build/deploy all of your locally created plugins into a local p2 repository (see http://www.sonatype.org/nexus/). Then add that p2 site to your Target Platform.
I have an existing eclipse project with standard dependencies in the classpath. I need to add a new dependency through maven but the rest of the dependencies need to stay there as jars bundled with the project.
I am using m2e, if I right click on the project --> maven --> enable maven, a pom file is created. At this stage I can add my new dependency through the pom file but all the existing dependencies seem to be gone from the classpath.
Hence the question: Is there a way to create a hybrid project that has both standard dependencies and maven dependencies?
You could add your legacy dependencies by using the scope "system" (and the tag "systemPath") ?
See http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.
I don't think you should even attempt to create such a thing, and I don't know why you would want to.
If you want to use Maven, then you should define all your dependencies in your pom so that a maven build will actually work. If all your dependencies aren't defined, how do you expect maven to build your project?
You need to decide which means of dependency resolution you want to use instead of trying to mix two together.
I have a library that I wrote in Scala that uses Bouncy Castle and has a whole bunch of dependencies. When I roll a jar, I can either roll a "fat" jar that has all the dependencies (including scala), which weighs in around 19 MB, or I can roll a skinny jar, which doesn't have dependencies, but is only a few hundred KB.
The problem is that I need to include the Bouncy Castle classes/jar with my library, because if its not on the classpath at runtime, all kinds of exceptions get thrown.
So, I think the ideal situation is if there is some way that I can get either Maven or SBT to include some but not all dependencies in the jar that gets rolled. Some dependencies are needed at compile-time, but not at run time, such as the Scala standard libraries. Is there some way to get that to happen?
Thanks!
I would try out the sbt proguard plugin from https://github.com/nuttycom/sbt-proguard-plugin . It should be able to weed out the classes that are not in use.
If it is sufficient to explicitly define which dependencies should be added (one the artifact-level, i.e., single JARs), you can define an assembly (in case of a single project) or an additional assembly project (in case of a multi-module project). Assembly descriptors can explicitly exclude/include artifacts from the dependencies.
Here is some good documentation on this topic (section 8.5.4), here is the official documentation.
Note that you can include all artifacts that belong to one group by using the wildcard notation in dependecySets, e.g. hibernate:*:jar would include all JAR files belonging to the hibernate group.
Covering maven...
Because you declare your project to be dependent upon bouncy castle in your maven pom, anybody using maven to depend upon your library will by default pull in bouncy castle as a transitive dependency.
You should set the appropriate scope on your dependencies, e.g. compile for stuff needed at compile and runtime, test for dependencies only needed in testing and provided for stuff you expect to be provided by the environment.
Whether your library's dependencies are packaged into dependent projects when they are built is a question of how those are projects configured and setting the scopes will influence the default behaviour.
For example, jar type packaging by default does not include dependencies, whereas war will include those in compile scope (but not test or provided). The design aim here was to have packaging plugins behave in the most commonly required way without needing configuration, but of course packaging plugins in maven can be configured to have different behaviour if needed. The plugins themselves which do packaging are well documented at the apache maven site.
If users of your library are unlikely to be using maven to build their projects, an option is to use the shade plugin which will allow you to produce an "uber-jar" which contains all the dependencies you wish. You can configure particular includes or excludes.
This can be a problematic way to deliver, for example where your library includes dependencies which version clash with the direct dependencies of projects using it, i.e. they use a different version of the same libraries yours does.
However if you can it is best that you leave this to maven to manage so that projects using your library can decide whether they want your dependencies or to specify particular versions giving them more flexibility. This is the idiomatic approach.
For more information on dependencies and scopes in maven, see the reference guide published by Sonatype.
I'm not a scala guy, but I have played around with assembling stuff in Java + Maven.
Have you tried looking into creating your own assembly descriptor for the assembly plugin? https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html
You can copy / paste the jar-with-dependencies descriptor then just add some excludes to your < dependencySet >. I'm not a Maven expert, but you should be able to configure it so different profiles kick off different assembly builds.
EDIT: Ack, didn't see my HTML got hidden