A has code
C has no code and is there to allow you to compile A and B with libjar
without getting libjar into your A jar.
"provided" is there to tell maven not to put libjar into A.
It says that you will do that after A is built and before B is executed.
You then assemble a deliverable jar with A.jar, B.jar and the version of
libjar that you want at run-time, using maven-assembly or maven-shade
plug-in or better yet with an installer that allows the system admin to
specify the deployment environment and get the right libjar at
installation time.
Avoids profiles and makes your poms follow "Best Practices".
Ron
On 11/12/2013 1:40 AM, Liu, Raymond wrote:
Well. The reason for using different version of libjar is that it's a client
API, and working with different version of server counter part code.
They are not compatible, instead, A is a shim layer that hook into different
libjar API and provide a common interface for B to use. So that to hide the API
changes across version.
And in my case B need to be assembled into a fat jar for easy usage. So
switching C in runtime won't be possible. Otherwise, not need an extra C, just
switching libjar is ok.
Best Regards,
Raymond Liu
-----Original Message-----
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: Wednesday, December 11, 2013 12:24 PM
To: users@maven.apache.org
Subject: Re: How to resolve right dependency which enabled and built/install
with profile?
B depends on A
A depends on C
C depends on libjar x.0 "provided"
C has no code and is only a pom not a jar.
You can then swap in any compatible version of libjar by providing it at
run-time.
Still not sure why you can not just use the latest version of libjar if any
version will work at run-time.
On 10/12/2013 7:52 PM, Liu, Raymond wrote:
Thanks Stephen
I see your solution is let B manage the libjar version. While this is
against my wish, I wish B to know nothing about A's internal implementation. In
the future, A might depends on a v3.0 libjar, I do wish to just repackage B to
make it work not revise B's code or assembly rules. And sometime A might be
buried deep in the dependent tree, Those project might not even aware it
depends on A, they just wish it works on whatever current A's binary jar, which
then need the right libjar dependency when assembly.
And I know it seems hard to use profiles to manipulate dependencies.
While by theory, I think this is a reasonable requirement that a project do not
need to take care of its dependencies' internal implementation of what it
depends on, It just wish it works. E.g. if the POM file is installed in a way
that when it build with profile, the corresponding dependencies and any other
modifying is fill in the final POM file. ( since the profile is not used anyway
when resolve dependencies, why keep it there? For source jar? ) Then those
project depend on it won't worry about A's profile, it's already the correct
one which been used on building A with this installed or downloaded binary jar.
So , using profile might not be the right solution, While if there
isn't an automatic way to meet this requirement, can I take it as a feature
missing?
Best Regards,
Raymond Liu
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: Tuesday, December 10, 2013 6:57 PM
To: Maven Users List
Subject: Re: How to resolve right dependency which enabled and built/install
with profile?
Using profiles to manipulate dependencies is a route to madness.
An modules dependencies should be a constant... It was a mistake to allow
<dependencies> within <profile>.
The correct solution is to create additional modules that aggregate in the
corresponding lib versions (this is also a bad plan, but less worse than your
current plan by quite some margin). The additional modules would depend on A
and the respective version of libjar and bundle the two together.
Then B can depend if the corresponding internmediate... Now at this point you
will start to see the madness returning... That is if you need two versions of
B.
The better solution is to just let B depend in A and then do the
fatjar as the final later after B and *override* the transitive dep on
libjar in the two fatjar building modules
On Tuesday, 10 December 2013, Liu, Raymond wrote:
Hi
I have a project with module A that will be built with or without
profile say -Pnewlib , thus I can have it build with different
version of library dependency let's say by default use libjar-1.0 and
when -Pnewlib will use libjar-2.0.
Then, I have a module B to depends on module A. The issue is that how
can I get the right dependency in module B for libjar? I want to
assemble a fat jar so I need to figure out which version of libjar to include.
In my test, it seems to me that when mvn -Pnewlib install module A,
though it will build with libjar-2.0. but the installed pom do not reflect this.
Thus when module B resolve the dependency, it will resolve the
dependency as libjar-1.0 ( though when building module B, -Pnewlib is
also passed in, But I think this will not pass to the dependent
package when resolve the dependency).
I don't want to have module B know anything about the libjar-1.0 and
libjar-2.0. it should handle by module A, and module B just simply
call into module A.
Actually, I think this apply the same if A and B are not modules in
one project, but standalone projects. In which case B will not define
profile at all.
So how can I achieve this goal? say, A take care of lib dependency
when build and install. B who depends on A, when assembly can retrive
the right lib dependency.
Best Regards,
Raymond Liu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
<javascript:;> For additional commands, e-mail:
users-h...@maven.apache.org<javascript:;>
--
Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
