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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
