Hi i have a quite simple question about maven dependency. I have 2 modules of one project. So first module is dependent on second. Second module has dependencies on some libs. Second module can be itself installed as standalone app. So when i build the project the first war will contain packaged second module as well as all libs that second module depends on.
I need that when i package first module the second module should be included without it's dependencies. How it is possible to manage?
Thx
I need that when i package first module the second module should be included without it's dependencies. How it is possible to manage?
Somehow, this is an hint that the dependencies of the 2nd module are provided when it gets packaged inside the war. IOW, declaring the dependencies of the 2nd module with a provided scope would do it, they wouldn't get pulled transitively.
Depending on how you create the standalone distribution of the 2nd module, you might need to combine dependencies scope with profiles, or not. Can't say since you didn't say anything about this :)
References
Dependency Scope
Related
I have a JDK 9 project. When running mvn install, everything works fine. When using IntelliJ 2017.2.6 with JDK 9.0.4 I come up
with dozens of compilation errors due to split packages. For example, in my POM I set a dependency on org.apache.solr:solr-core:7.2.1. One of the errors displayed by IntelliJ is:
Error:java: module solr.core reads package org.apache.lucene.search from both lucene.misc and lucene.sandbox
The rationale for the compilation error issued by IntelliJ is:
solr-core has Maven dependencies on artifacts lucene-misc and lucene-sandbox
Both lucene-misc.jar and lucene-sandbox.jar define classes in package org.apache.lucene.search
IntelliJ considers that lucene-misc.jar and lucene-sandbox.jar are JDK 9 modules (if fact, they are not modules, they have no module-info.java file). As two JDK 9 modules cannot participate to the same package, IntelliJ issues a compilation error.
By contrast, the Maven compiler pluging issues no error, because it considers lucene-misc.jar and lucene-sandbox.jar as belonging to
the class path, not to the module path.
I obviously don't want to re-package the Lucene stuff.
So my problem boils down to the following: how can I mute IntelliJ errors Error:java: module Mod1 reads package P from both Mod2 and Mod3?
[Short]
It's impossible if you want to run your application from a module code. You have to migrate your code which depend on collision JARs to non-module code and add your collitions jar on the class path. (as suggested in comments)
[Long]
Behind the scene the Intellij try to run the JVM, so the Intellij can run your application only if the JVM can do that.
When you run an application from module jar, that means that you run your application from named module. The module must require all of its dependencies which should be name modules. Note that even automatic modules which are created from your non-module JARs are indeed named.
Java 9 does not allow split-packages for the reason of the reliable configuration, only unnamed modules are excepted from this rule.
The only way to make it works it move your collision jars to unnamed module, but named module cannot depend on unnamed module
A named module cannot, in fact, even declare a dependence upon the unnamed module. This restriction is intentional, since allowing named modules to depend upon the arbitrary content of the class path would make reliable configuration impossible.
so if you don't want repackage collision jars you have to move your modules which require collision jars to non-module jar.
Your maven plugin done with it, because as #Nicolai said:
Maven places them on the class path (where split packages don't matter), whereas IntelliJ places them on the module path (leading to the problems you observe).
See also this answer about running the application from non-module code.
I have an minecraft forge workspace that is made by gradle, I have an project in which I have an module with the mod I'm working on and one module with my library mod, I want to somehow access classes from my library mod from the other module, I imported modules by using their build.gradle and now I have 2 different modules but I can't access one module from another one.
You need to add a dependency from the working module on the library module. If this is a multi-module Gradle build where both projects are modules, you can simply add a project(':library') dependency. If those are separate Gradle builds, you need to add a normal dependency like 'your.group:library-module:1.0' and then either install the library module to some repository like the local maven repository with the mavenPublish plugin to be able to use it from the working module, or use a composite build to replace the dependency by the automatically built result of the library module. For more information on how to do either, you should read the Gradle Userguide.
Using the search I already found some great answers to similar questions, but still I am not sure if I understood it correctly.
From these answers I learned that dependencies are required to run the application while devDependencies are only required while developing (like unit tests).
But how about this: My application depends on jQuery, but during a build step (with the help of my devDependencies), everything is bundled into one file. In this case, should I list jQuery as dependency or as devDependency?
To make my point more clear take a module like this:
define(['jquery'], function($) {
// use jQuery in this module
})
Later on, this module will be compiled into somehing like application.build.js which then contains this module and the jQuery dependency.
Since the end result is the same, there doesn't seem to be a definite rule here, but I found a couple of discussions on the matter:
If you're building an application
https://github.com/webpack/webpack/issues/520
A browser app built by [insert build tool/bundler] has no runtime node dependencies, and thus all frontend dependencies should be listed as devDependencies. The dependencies vs devDependencies naming convention stems historically from node being a server side package manager (...) It is as far as I can tell harmless to list frontend dependencies under dependencies, but it is wrong.
(...) as a general recommendation for everyone, move everything into devDependencies until it is actually needed under dependencies.
If you're building a library:
https://github.com/inuitcss/inuitcss/issues/225
In many frontend projects, all code served to the browser is compiled, there are no runtime dependencies. This would mean that there are no dependencies, only devDependencies – all dependencies are included in the build done during development.
One could also argue that dependencies are required for development as well, so it would be okay to list everything unter dependencies.
I think the fact that we have the optional distinction indicates a reasonable way to use them. It makes sense (to me) that the dependencies designation would represent the 'minimum viable' code to use and as an indicator of what's nonessential for something to work.
As I see it, anything that goes on to become part of the production code is a dependency.
Epilogue
Personally, I agree more with the last quote. It makes sense that dependencies tells us what the application code needs to run, and devDependencies what the developer needs to build/deploy/whatever the application/library.
One caveat though is that if someone npm installs your library to use the bundle as a module in their own application, they will download a lot of dependencies they don't actually need.
Module A uses module B. I compile module B which implies a new jar in ~/.ivy2/local/[group]/B/[version]/B-[version].jar.
~/.ivy2/cache is not updated.
My problem is that Module A is trying to find B in ~/.ivy2/cache (that's what IvyDE indicates).
How can I ensure the cache is updated once project B is compiled?
Regards
You may want to use the workspace resolver feature of IvyDe:
This will makes all eclipse projectes directly available, without the need to build/publish th artfifacts.
Note: The Screenshot ist for 2.2.0Beta, but the feature exists for the current version, too.
I’m trying to embed some JARs into single OSGi bundle using the feature of maven-bundle-plugin
The thing that worries me is that all packages of embedded JARs are put into the Import-Package header of the generated MANIFEST.MF.
If I specify explicitly to use only the packages I need, like in the following snippet:
Import-Package: org.osgi.framework
The build fails with BND error (unresolved references).
So, the question here is how can I build the bundle with embedded JARs with "Import-Package" header I need?
All the packages that are imported in your classes will be imported by bnd. Perhaps you do not want those packages imported because you know that at runtime you won't be needing them. If you cannot stop bnd from importing them, you can make them optional so that your bundle will still resolve even if they are not supplied by another bundle (at wire time). Try to add this:
<Import-Package>*;resolution:=optional<Import-Package>
To your maven bnd configuration in maven.
One possible reason why you are seeing "unexpected" packages in Import-Package header is the following:
A general good practice that supports collaboration model in OSGi is to import all packages that you export -- see this blog post by Peter Kriens for detailed explanation why. Bnd (and hence also maven-bundle-plugin) follows this practice by default and automatically imports all exported packages. Therefore you should first check your Export-Package header and make sure that you export only the packages you want.
Also if you want to export packages from the embedded dependencies then you should be careful to avoid duplication inside your bundle -- see section Embed-Dependency and Export-Package of the maven-bundle-plugin documentation.
You should use Bundle-ClassPath if you want to make classes available inside a bundle that contains JARs e.g.
Bundle-ClassPath: foo.jar,other.jar
Import-Package: org.osgi.framework,org.other.imported
You'll need to list the classes that foo.jar and other.jar import/use, but you won't need to list any of the packages in foo.jar or other.jar unless you're actually exporting them.
You can remove some packages from import-package scope when you embed a JAR into your bundle:
<Import-Package>![package_name9]<Import-Package>
inside pom.xml or if you use external *.bnd files:
Import-Package: ![package_name]