Arnaud HERITIER wrote:
Instead of writing specifications couldn't we write tests ? There's no/few
doubts with tests ;-)
(But we'll also write a complete documentation about that ...)
1) First we write the specification - what the software is supposed to do.
2) Then we write the design of the implementation - architecture, how it is
supposed to do it.
3) Then we write tests to check if the implementation follows the specification.
4) Then we write the implementation.
3 and 4 can be swapped or done simultaneously. You cannot write a test if you
don't
know the correct behaviour. The tests should be kept up to date with the specs,
and
reflect them. Tests themselves are poorly documented right now, and don't test
for
everything, because there is no specification.
So yes, tests are needed, but they are only an 'aid' in telling us wheter we
live
up to the spec; it cannot be the spec itself. Tests can contain bugs too, or
don't test
all cases. Writing good tests is the hardest part in software developement
processes,
apart from writing a good specification.
-- Kenney
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
