Emmanuel,
I thought about your scenario a little more.
Here's your scenario:
-----------------------------------------
Level0 -> L2 -> L3
with a test in each level, and each test depends on
a very specific version
-----------------------------------------
This is where I hung for a sec.
>with a test in each level, and each test depends on
>a very specific version.
Then I thought about it like this:
Challenge
We have L0 project
with a dependency in dependencyManagement
that has a version 2.1.1.
A project A at L1 uses this dependency.
Project B at L1 overrides this dependency
and sets the version to 3.2.
Project C is a parent project and it
has two child projects, D and F.
Project D needs version 3.3 of the
dependency. Project F does not
want the dependency at all.
Solution
Project D just overrides and puts in
version 3.3 like project B did.
I assume you meant something like this?
I also assume that there are no tests in projects
with packaging of type pom?
If that's the case, then I think we should be fine.
Have you had any issues with this type of structure?
Thanks,
- Ole
> of commons-collection. For instance, PL2 use
> commons-collection 2.1.1 and
> PL3 use version 3.2.
>
> In the PL2 test, you use
>
ArrayEnumeration<http://jakarta.apache.org/commons/collections/api-2.1.1/org/apache/commons/collections/ArrayEnumeration.html>which
> does not exist anymore in
> 3.2
> In the PL3 test, you use
>
AbstractBagDecorator<http://jakarta.apache.org/commons/collections/api-release/org/apache/commons/collections/bag/AbstractBagDecorator.html>which
> does not exist in
> 2.1.1
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
