import scope questions

[Tom Huybrechts <to...@gmail.com>]

I read about the new import scope in the 2.0.9 release notes. This
looks very promising to me, but I have a questions on the details of
how this works.
I looked in the mailing list history for discussions on this feature,
but couldn't find anything. There is a wiki page, but it has few
details (and no discussion).

I've set up a few simple test projects:
- project-A has a managed dependency for log4j:log4j:1.2.13
- project-B has a managed dependency for log4j:log4j:1.2.14
- project-C imports managed dependencies from A and B, and has a
version-less dependency on log4j:log4j.

What version of log4j is now used by project-C ? It looks like this
now depends on the order of the imports. If project-A is first in the
dependency list, it will be 1.2.13, and if project-B is first it is
1.2.14. If project-C defines it own managed dependency for
log4j:log4j, then that wins always, irrespective of ordering.
Is this the intended behaviour ?

I then extended these POMs.
- project-A got a module a1, and a managed dependency for a1. Then I
released versions 1 and 2 of project-A and a1.
- project-B gets a managed dependency on version 1 of a1.
- project-C gets a version-less dependency on a1, and the managed
dependency on project-A is updated to version 2.

I want to import the parent project-A to avoid having to set
dependency versions for all of project-A's modules. This would be very
useful to increase manageability.
But as I kind of expected, the version of a1 in project-C is still
dependent on ordering.
If project-B (which depends on a1:1) is listed first, project-C will
depend on a1:1 too. Even though I have a direct dependency import for
project-A:2.
Someone else mentioned the principle of least surprise recently. This
was defnitely violated for me here :(

One last thing I wanted to check is how this would interact with older
Maven versions, so I created project-D that depends on project-C.
With 2.0.9 dependency:tree on project-D nicely prints the transitive
dependencies on log4j and a1.
But switching back to 2.0.8, I get:
 [WARNING] POM for 'x:project-C:pom:1:compile' is invalid. It will be
ignored for artifact resolution. Reason: Failed to validate POM for
project x:project-C at Artifact [x:project-C:pom:1:compile]
and the transitive dependencies are gone.
Does this mean we'll start seeing dependencies in the repository that
cannot reliably be used by older Maven versions ?

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: import scope questions

["Brian E. Fox" <br...@reply.infinity.nu>]

  
>The design pattern I would recommend is one where the pom being
imported 
>contains nothing but the managed dependencies, i.e. it defines a
library 
>of related artifacts. You wouldn't use such a pom in any other way so I

>don't see this as a compatibility problem.

But any poms that are consuming this other pom won't parse in <2.0.9.
(Even when deployed)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: import scope questions

[Ralph Goers <Ra...@dslextreme.com>]

Brian E. Fox wrote:
>> I read about the new import scope in the 2.0.9 release notes. This
>> looks very promising to me, but I have a questions on the details of
>> how this works.
>> I looked in the mailing list history for discussions on this feature,
>> but couldn't find anything. There is a wiki page, but it has few
>> details (and no discussion).
>>     
>
> Ralph is hopefully putting together some guides for this before we
> release 2.0.9
>   
I will do my best but I am leaving on vacation for a week tomorrow 
night. I will try to get to it tonight.
>   
>> Does this mean we'll start seeing dependencies in the repository that
>> cannot reliably be used by older Maven versions ?
>>     
>
> Yes that is the case if you use the new scope. It makes me wonder if
> this really is appropriate to add to 2.0.x given that we can't increment
> the pom version.
>
>   
The design pattern I would recommend is one where the pom being imported 
contains nothing but the managed dependencies, i.e. it defines a library 
of related artifacts. You wouldn't use such a pom in any other way so I 
don't see this as a compatibility problem.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: import scope questions

["Brian E. Fox" <br...@reply.infinity.nu>]

>I read about the new import scope in the 2.0.9 release notes. This
>looks very promising to me, but I have a questions on the details of
>how this works.
>I looked in the mailing list history for discussions on this feature,
>but couldn't find anything. There is a wiki page, but it has few
>details (and no discussion).

Ralph is hopefully putting together some guides for this before we
release 2.0.9

>Does this mean we'll start seeing dependencies in the repository that
>cannot reliably be used by older Maven versions ?

Yes that is the case if you use the new scope. It makes me wonder if
this really is appropriate to add to 2.0.x given that we can't increment
the pom version.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: import scope questions

[Ralph Goers <Ra...@dslextreme.com>]

Tom Huybrechts wrote:
> I read about the new import scope in the 2.0.9 release notes. This
> looks very promising to me, but I have a questions on the details of
> how this works.
> I looked in the mailing list history for discussions on this feature,
> but couldn't find anything. There is a wiki page, but it has few
> details (and no discussion).
>
> I've set up a few simple test projects:
> - project-A has a managed dependency for log4j:log4j:1.2.13
> - project-B has a managed dependency for log4j:log4j:1.2.14
> - project-C imports managed dependencies from A and B, and has a
> version-less dependency on log4j:log4j.
>
> What version of log4j is now used by project-C ? It looks like this
> now depends on the order of the imports. If project-A is first in the
> dependency list, it will be 1.2.13, and if project-B is first it is
> 1.2.14. If project-C defines it own managed dependency for
> log4j:log4j, then that wins always, irrespective of ordering.
> Is this the intended behaviour ?
>   
Yes.
> I then extended these POMs.
> - project-A got a module a1, and a managed dependency for a1. Then I
> released versions 1 and 2 of project-A and a1.
> - project-B gets a managed dependency on version 1 of a1.
> - project-C gets a version-less dependency on a1, and the managed
> dependency on project-A is updated to version 2.
>
> I want to import the parent project-A to avoid having to set
> dependency versions for all of project-A's modules. This would be very
> useful to increase manageability.
> But as I kind of expected, the version of a1 in project-C is still
> dependent on ordering.
> If project-B (which depends on a1:1) is listed first, project-C will
> depend on a1:1 too. Even though I have a direct dependency import for
> project-A:2.
> Someone else mentioned the principle of least surprise recently. This
> was defnitely violated for me here :(
>   
importing is exactly that. The pom being imported is simply replaced 
with the managed dependencies listed in that pom. If that pom imports 
other poms those must be replaced first. I can envision how this could 
be changed and if that is the consensus I'd be happy to do it, but not 
until I get back from vacation.
> One last thing I wanted to check is how this would interact with older
> Maven versions, so I created project-D that depends on project-C.
> With 2.0.9 dependency:tree on project-D nicely prints the transitive
> dependencies on log4j and a1.
> But switching back to 2.0.8, I get:
>  [WARNING] POM for 'x:project-C:pom:1:compile' is invalid. It will be
> ignored for artifact resolution. Reason: Failed to validate POM for
> project x:project-C at Artifact [x:project-C:pom:1:compile]
> and the transitive dependencies are gone.
> Does this mean we'll start seeing dependencies in the repository that
> cannot reliably be used by older Maven versions ?
>
>   
Now that I've read this and thought about this I do see the issue you 
are pointing out.

The issue is that in 2.0.8 the transitive dependency doesn't have the 
information provided by the managed dependency.  My gut response (based 
solely on how I use Maven) would be to tell you that you should be 
importing or defining managed dependencies for anything that might be 
used as a dependency, whether it be a direct dependency or transitive. 
In other words, and this is just my opinion, relying on transitive 
dependencies to provide the version for you will lead to nothing but 
misery. But, having gotten that off my chest, I'll have to take a look 
at the recommended use case and see if this can be avoided.

Ralph



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org