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,
Hi,
I would like to add an issue in the Maven's Jira,
but it is not possible to create an account.
Someone here could add me in the Maven's Jira, please?
The issue I would like to add is about changing a boring Maven behavior:
when running tests the running XXX test is printed just after the
Am 2013-12-10 18:28, schrieb Leonardo Alexandre Ferreira Leite:
Hi,
I would like to add an issue in the Maven's Jira,
but it is not possible to create an account.
Someone here could add me in the Maven's Jira, please?
Have you filled in this form? https://xircles.codehaus.org/signup
The
OK, thanks!
I have just read Not a member? To request an account, please contact your
JIRA administrators..
But OK, I'll submit the form!
On 10 December 2013 15:36, Michael-O 1983-01...@gmx.net wrote:
Am 2013-12-10 18:28, schrieb Leonardo Alexandre Ferreira Leite:
Hi,
I would like to add
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
Sonar downloads everything it needs (jar file wise) inside the plugin and
adds them to its Maven plugin classpath. If Sonar isn't doing this
properly, its Sonar's fault (I have spent *way* too much time in the
internals of Sonar).
On Tue, Dec 10, 2013 at 11:34 AM, Omar@Gmail
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
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
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
