On 8 Jun 07, at 11:26 AM 8 Jun 07, Arnaud HERITIER wrote:
Instead of writing specifications couldn't we write tests ? There's
no/few
doubts with tests ;-)
Kenney has already posted, and I agree with what he says but
essentially you can't write tests until you have the basic principles
down.
Concrete example is that I've been chatting with John and Kenney
about removing any inserting of repositories during the resolution
and that all repositories be known up front. This means no more
chicken and egg and all required repositories be in your settings, or
shared settings.
Without actually deciding this actual detail amongst the group you
might go write tests for a very complicated mechanism and then it be
useless once you decide to simplify it. I think there are many
simplifications we can make like this but they need to be decided on,
written down and then we can go to town writing tests and the
implementation.
(But we'll also write a complete documentation about that ...)
Arnaud
On 07/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Ultimately the short answer is who cares what 2.0.x does.
Why?
Because we didn't write the spec first and anything that has been
done has been embodied in code and subject to changes like MNG-1577.
We need a spec, define the behavior and then write to that. Trying to
do anything with 2.0.x or the artifact resolution mechanism as it
stands is a complete waste of time. Decide the behavior amongst
ourselves and then make the new mechanism work that way. I've already
run into a half dozen cases where what I worked on doesn't work
generally and so I'm convinced all that matters is the spec. I have a
technically better implementation at the plexus level but how POMs
are read, where repositories can be injected, how profiles are
injected, at what level and how scopes can change all need to be
nailed down.
It's obvious from just this short thread people have differing
opinions.
On 6 Jun 07, at 12:35 PM 6 Jun 07, Joakim Erdfelt wrote:
> Sorry for the 1950's Horror Movie Catchphrase. I'm just odd like
> that. ;-)
>
> The following has been filed as http://jira.codehaus.org/browse/
> MNG-3038
> and I encourage discussion on this.
>
> I was recently working out some discrepancies between what maven
> client, mpir and archiva show as dependency tree's on some
> projects, and discovered something.
>
> MNG-1577 as discussed isn't done (yet).
>
> I created the teeny example project following the example that
> Carlos described on
> http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-
> behavior-p9506667s177.html
>
> | What about this use case for transitive dependencyManagement? has
> been tested?
> |
> | A -> B -> C -> D
> |
> | C depends on D 1.0
> | B has D 2.0 in dependencyManagement, no D in dependencies
> |
> | A should get D 2.0
>
> Source for project:
> http://joakim.erdfelt.com/maven/carlos_transitive_version.tar.gz
>
> I found that maven 2.0.6 does not handle this use case.
>
> When working on project A, i was expecting to see module D version
> 2.0 in use, but didn't.
> Here's what I see in mvn -X clean package of module A.
>
> [DEBUG] net.example:A:jar:1.0 (selected for null)
> [DEBUG] Adding managed depedendencies for net.example:B
> [DEBUG] net.example:D:jar:2.0
> [DEBUG] net.example:B:jar:1.0:compile (selected for compile)
> [DEBUG] net.example:C:jar:1.0:compile (selected for compile)
> [DEBUG] net.example:D:jar:1.0:compile (selected for compile)
>
> That shows that D:2.0 is identified as being part of depMan.
>
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-
> plugin:2.0.2:compile' -->
> [DEBUG] (f) basedir = /home/joakim/code/experiments/deptree-
> mng-1577/carlos_transitive_version/A
> [DEBUG] (f) buildDirectory = /home/joakim/code/experiments/
> deptree-mng-1577/carlos_transitive_version/A/target
> [DEBUG] (f) classpathElements = [/home/joakim/code/experiments/
> deptree-mng-1577/carlos_transitive_version/A/target/classes, /home/
> joakim/.m2/repository/net/example/D/1.0/D-1.0.jar,
> /home/joakim/.m2/repository/net/example/B/1.0/B-1.0.jar, /home/
> joakim/.m2/repository/net/example/C/1.0/C-1.0.jar]
> [DEBUG] (f) compileSourceRoots = [/home/joakim/code/experiments/
> deptree-mng-1577/carlos_transitive_version/A/src/main/java]
> [DEBUG] (f) compilerId = javac
> [DEBUG] (f) debug = true
>
> That shows that the compiler plugin is using D:1.0 as part of the
> compiler plugin.
>
> This has been reviewed by Carlos and Brian on irc as not
> implemented correctly on maven client.
>
> --
> - Joakim Erdfelt
> [EMAIL PROTECTED]
> Open Source Software (OSS) Developer
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - [EMAIL PROTECTED]
www.octo.com | blog.octo.com
..........................................................
ASF - [EMAIL PROTECTED]
www.apache.org | maven.apache.org
...........................................................
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
