-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dependencySet does not include transitive dependencies #3
Comments
I think that, for proposition 1, a parameter like includeTransitiveDependencies would work. I will try to add this in a few days. Thanks, |
@claudius108 I think the default should be to include transitive dependencies. I don't see any reason for not having them, as the POM really sets up the deps. If you need to exclude some (I can't imagine why?) then you could add an |
@claudius108 @adamretter any updates/progress on this subject? |
@dizzzz Not that I know of. The manual copy/paste workaround will help you immediately. |
I am contemplating it. |
One related aspect is.... it would be good to exclude specific transient dependencies as well... in pom.xml: <dependency>
<groupId>${project.groupId}</groupId>
<artifactId>app</artifactId>
<version>${project.version}</version>
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency> |
i think our monex problems might be related see eXist-db/monex#92 |
Hi, I think that the plugin behaves correctly as to the EXPath Packaging System specification, namely one has to define every component to be included. I also asked once @fgeorges what happens when they are tens of dependent files, and your issue with transitive dependencies is of the same kind. One solution for this issue with transitive dependencies is to have a fat jar including everything needed. This is the solution. The Apache Maven Shade Plugin already creates a a distributable jar with all the dependencies, so I think it is better to not duplicate this functionality within this plugin, and keep it simple instead. I think that any other solution would not be in the spirit of the above-mentioned specification. Maybe @fgeorges can share us this thoughts about the issue you are facing... I think that Packaging specification could use the knowledge associated with the maven storage system, by using URNs for naming the components, as it is possible for this plugin, see an example below: <components>
<resource>
<public-uri>http://exist-db.org/xquery/jms</public-uri>
<file>urn:java:class:org.exist.jms.xquery.JmsModule</file>
</resource>
</components> I also suggested once this kind of storage for eXist to @wolfgangmm, so to avoid packing, for instance, commons-io-2.6.jar in my library when one can find it in $EXIST_DB/lib/core/. |
When building a complex Java extension which we wish to use EXPath XAR packaging for, the Java application will have dependencies other than its own class files which need to be included in the EXPath package.
These dependencies are correctly expressed in the
pom.xml
and we can for example use the Maven Shade (or even the Maven Assembly) plugin to assemble an uber/fat jar which contains all of the class files that we would need if we were distributing as a Java artifact.However, when using the XAR plugin we need to also include all of the transitive dependencies of the project manually as it fails to detect these correctly whereas the Shade or Assembly plugins do. Including all these manually is frustrating as we have to repeat all the dependencies (which are effectively runtime scope) from the
pom.xml
into thexar-assembly.xml
.For examples see:
I can see two possible solutions:
pom.xml
.classifier
to thedependencySet
in thexar-assembly.xml
which allows us to specify the shaded artifact for our project (which will already include all transitive dependencies).Ideally I think we should implement both facilities. I also think there is room for cleaning up the
xar-assembly.xml
and itsdependencySet
andfileSet
features, to make them behave more on convention and to use more of the information that is already defined in thepom.xml
without having to repeat ourselves.I would be happy to undertake some work to do an overhaul of the plugin and improve it to be more
Maven
like ;-) Thoughts?The text was updated successfully, but these errors were encountered: