You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ole Ersoy <ol...@yahoo.com> on 2006/12/03 20:10:28 UTC
Comments on Emmanuel's Maven Testing Thoughts
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
Re: Comments on Emmanuel's Maven Testing Thoughts
Posted by Ole Ersoy <ol...@yahoo.com>.
OH - With respect to putting tests in projects with
packaging set to pom.
Here's my thinking on this (Which is probably the same
as yours, I'll just elaborate for sake of clarity).
Projects with packaging pom should be for
configuration management only. All code
(src/main/test and src/main/java) should be in child
projects with packaging set to anything but pom. I
would think that maven would ignore code in pom
packaged projects...but I have not tested it.
--- Emmanuel Lecharny <el...@gmail.com> wrote:
> On 12/3/06, Ole Ersoy <ol...@yahoo.com> wrote:
> >
> > 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.
>
>
> correct
>
> A project A at L1 uses this dependency.
>
>
> correct, so no need to declare the version, just
> declare the dependency in
> L1 pom.xml
>
> Project B at L1 overrides this dependency
> > and sets the version to 3.2.
>
>
> Ok, so you must declare the dependency AND the
> version in B pom.xml
>
> Project C is a parent project and it
> > has two child projects, D and F.
>
>
> I guess that you don't declare a dependencyManagment
> in C pom.xml file
>
> 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.
>
>
> Correct. And if project F is nut using the
> dependency, then you don't
> declare it in its pom.xml.
>
> I assume you meant something like this?
>
>
> more or less
>
> I also assume that there are no tests in projects
> > with packaging of type pom?
>
>
> Not usre I understand the question
>
> If that's the case, then I think we should be fine.
> >
> > Have you had any issues with this type of
> structure?
>
>
> I just try to figure out which structure works, in
> any case, and which is
> not, and if there are some workaround. This is
> obviously a necessary task,
> as, for instance, the eclipse plugin is not able to
> cope with this simple
> needs.
>
> Thanks,
> > - Ole
>
>
> Thanks !
> Emmanuel
>
____________________________________________________________________________________
Need a quick answer? Get one in minutes from people who know.
Ask your question on www.Answers.yahoo.com
Re: Comments on Emmanuel's Maven Testing Thoughts
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 12/3/06, Ole Ersoy <ol...@yahoo.com> wrote:
>
> 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.
correct
A project A at L1 uses this dependency.
correct, so no need to declare the version, just declare the dependency in
L1 pom.xml
Project B at L1 overrides this dependency
> and sets the version to 3.2.
Ok, so you must declare the dependency AND the version in B pom.xml
Project C is a parent project and it
> has two child projects, D and F.
I guess that you don't declare a dependencyManagment in C pom.xml file
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.
Correct. And if project F is nut using the dependency, then you don't
declare it in its pom.xml.
I assume you meant something like this?
more or less
I also assume that there are no tests in projects
> with packaging of type pom?
Not usre I understand the question
If that's the case, then I think we should be fine.
>
> Have you had any issues with this type of structure?
I just try to figure out which structure works, in any case, and which is
not, and if there are some workaround. This is obviously a necessary task,
as, for instance, the eclipse plugin is not able to cope with this simple
needs.
Thanks,
> - Ole
Thanks !
Emmanuel