You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Liu, Raymond" <ra...@intel.com> on 2013/12/10 02:20:45 UTC
How to resolve right dependency which enabled and built/install
with profile?
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How to resolve right dependency which enabled and built/install
with profile?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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:rwheeler@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.connolly@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-unsubscribe@maven.apache.org
>>> <javascript:;> For additional commands, e-mail:
>>> users-help@maven.apache.org<javascript:;>
>>>
>>>
>> --
>> Sent from my phone
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: How to resolve right dependency which enabled and built/install
with profile?
Posted by "Liu, Raymond" <ra...@intel.com>.
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:rwheeler@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.connolly@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-unsubscribe@maven.apache.org
>> <javascript:;> For additional commands, e-mail:
>> users-help@maven.apache.org<javascript:;>
>>
>>
> --
> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How to resolve right dependency which enabled and built/install
with profile?
Posted by Ron Wheeler <rw...@artifact-software.com>.
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.connolly@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-unsubscribe@maven.apache.org
>> <javascript:;> For additional commands, e-mail:
>> users-help@maven.apache.org<javascript:;>
>>
>>
> --
> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How to resolve right dependency which enabled and built/install
with profile?
Posted by Ron Wheeler <rw...@artifact-software.com>.
With the solution that I suggested, A depends on C which is a "provided"
POM so that you can swap versions of libjar to build your fat jar.
Essentially you are lying to A by making it think that C is one thing
not knowing that you will swap C's dependency on libjar later on while
building the fat jar.
This is similar to the technique described here
http://blog.artifact-software.com/tech/?p=121 and
On 11/12/2013 8:56 PM, Liu, Raymond wrote:
> Actually, I think it is possible, though probably could not be done by current Maven implementation. As long as B can know which libjar the shim A is built upon. I am saying that it is possible is because that I can achieve the goal with SBT, when sbt do publish local, it will fill the profile info ( actually not profile in sbt, but some compile time config ) into A's final pom, then when assemble B, the installed A actually do not have any profile info in A's pom. B then assemble with the right libjar which A is built upon.
>
> Best Regards,
> Raymond Liu
>
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Wednesday, December 11, 2013 6:47 PM
> To: Maven Users List
> Subject: Re: How to resolve right dependency which enabled and built/install with profile?
>
> You are looking for the impossible.
>
> You want A to work with any version of libjar
>
> You want B to use A but not know which version of libjar the A it is using depends on... actually to be independent of the version of libjar that A depends on... but also to bundle the specific one...
>
> Rethink what you are asking and you will see that you are asking an impossible request... you are asking somebody to hop on one leg and mandating that the one leg be both their left and right leg.
>
> When you are asking an impossibility, that is usually a sign that you are going at things the wrong way.
>
> If A is going to become part of a fatjar at some point, you need to make a decision *at the point of creating the fatjar* as to which libjar will be included within A.
>
> Or else perhaps, you include all versions of libjar and provide a means for A to decide which version it wants... there are many ways to achieve this...
>
> * use the service provider pattern to introduce another shim layer and then use the shade plugin to put all the shim impl libjar deps into independent package namespaces
> * use a custom classloader and package libjar as resources, so that A's entry point loads the correct libjar at runtime
> * etc.
>
> With the above you would be including *all* versions of libjar within A and the whole thing becomes moot anyway...
>
> -Stephen
>
>
> On 11 December 2013 00:52, Liu, Raymond <ra...@intel.com> 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.connolly@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-unsubscribe@maven.apache.org
>>> <javascript:;> For additional commands, e-mail:
>>> users-help@maven.apache.org<javascript:;>
>>>
>>>
>> --
>> Sent from my phone
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: How to resolve right dependency which enabled and built/install
with profile?
Posted by "Liu, Raymond" <ra...@intel.com>.
Actually, I think it is possible, though probably could not be done by current Maven implementation. As long as B can know which libjar the shim A is built upon. I am saying that it is possible is because that I can achieve the goal with SBT, when sbt do publish local, it will fill the profile info ( actually not profile in sbt, but some compile time config ) into A's final pom, then when assemble B, the installed A actually do not have any profile info in A's pom. B then assemble with the right libjar which A is built upon.
Best Regards,
Raymond Liu
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Wednesday, December 11, 2013 6:47 PM
To: Maven Users List
Subject: Re: How to resolve right dependency which enabled and built/install with profile?
You are looking for the impossible.
You want A to work with any version of libjar
You want B to use A but not know which version of libjar the A it is using depends on... actually to be independent of the version of libjar that A depends on... but also to bundle the specific one...
Rethink what you are asking and you will see that you are asking an impossible request... you are asking somebody to hop on one leg and mandating that the one leg be both their left and right leg.
When you are asking an impossibility, that is usually a sign that you are going at things the wrong way.
If A is going to become part of a fatjar at some point, you need to make a decision *at the point of creating the fatjar* as to which libjar will be included within A.
Or else perhaps, you include all versions of libjar and provide a means for A to decide which version it wants... there are many ways to achieve this...
* use the service provider pattern to introduce another shim layer and then use the shade plugin to put all the shim impl libjar deps into independent package namespaces
* use a custom classloader and package libjar as resources, so that A's entry point loads the correct libjar at runtime
* etc.
With the above you would be including *all* versions of libjar within A and the whole thing becomes moot anyway...
-Stephen
On 11 December 2013 00:52, Liu, Raymond <ra...@intel.com> 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.connolly@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-unsubscribe@maven.apache.org
> > <javascript:;> For additional commands, e-mail:
> > users-help@maven.apache.org<javascript:;>
> >
> >
>
> --
> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How to resolve right dependency which enabled and built/install
with profile?
Posted by Stephen Connolly <st...@gmail.com>.
You are looking for the impossible.
You want A to work with any version of libjar
You want B to use A but not know which version of libjar the A it is using
depends on... actually to be independent of the version of libjar that A
depends on... but also to bundle the specific one...
Rethink what you are asking and you will see that you are asking an
impossible request... you are asking somebody to hop on one leg and
mandating that the one leg be both their left and right leg.
When you are asking an impossibility, that is usually a sign that you are
going at things the wrong way.
If A is going to become part of a fatjar at some point, you need to make a
decision *at the point of creating the fatjar* as to which libjar will be
included within A.
Or else perhaps, you include all versions of libjar and provide a means for
A to decide which version it wants... there are many ways to achieve this...
* use the service provider pattern to introduce another shim layer and then
use the shade plugin to put all the shim impl libjar deps into independent
package namespaces
* use a custom classloader and package libjar as resources, so that A's
entry point loads the correct libjar at runtime
* etc.
With the above you would be including *all* versions of libjar within A and
the whole thing becomes moot anyway...
-Stephen
On 11 December 2013 00:52, Liu, Raymond <ra...@intel.com> 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.connolly@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-unsubscribe@maven.apache.org
> > <javascript:;> For additional commands, e-mail:
> > users-help@maven.apache.org<javascript:;>
> >
> >
>
> --
> Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: How to resolve right dependency which enabled and built/install
with profile?
Posted by "Liu, Raymond" <ra...@intel.com>.
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.connolly@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-unsubscribe@maven.apache.org
> <javascript:;> For additional commands, e-mail:
> users-help@maven.apache.org<javascript:;>
>
>
--
Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How to resolve right dependency which enabled and built/install
with profile?
Posted by Stephen Connolly <st...@gmail.com>.
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-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>
--
Sent from my phone