John Casey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In my opinion, this thread is not particularly useful. As far as I know,
> we have not called for a vote on the final release of Maven 2.0. (we
> haven't even released -beta-1 yet, for crying out loud!)
>
> This is my last reply on this thread; it is fast growing into another
> bitch session and waste of my time.
>
> See my comments inline.
>
> Maczka Michal wrote:
> |
> | a) build won't be reproductable
>
> If you're declaring your API dependencies correctly for your project,
> this absolutely should not have an impact on you. Any POM cleanup
> efforts should be directed at eliminating test-scope dependencies, or in
> some [extremely rare] cases, optional dependencies. The latter case
> should be covered by your project, since if it uses these optional
> parts, it should make some use of these same dependencies.
So you are saying that: you are not going to add any dependencies to any
poms
nor to re order them?
>
> | b) the scenario which you are proposing - everybody maintaining its own
> | maven repository with competing metadata even for open source projects
> | will become the reality. And this is something which in my opinion
> won't be
> | any good for maven nor for improving the quality of the maven central
> | repository. I already know some people which are creating their own m2
> | repositories and the work which there are doing is not at all serving
> maven
> | community. I am all for centralising that effort.
>
> I know of people who won't use Maven or its repository because the
> artifacts aren't signed. Sure, there are going to be people who demand a
> higher level of quality than we are prepared to offer for the meantime;
> that is unavoidable. However, most users should be fine with the level
> of quality we can provide, particularly for the dependency use case.
> Project URLs and such are not as critical for this use case.
>
> |
> | Note then when I am saying that no POMs should not be changed -
this means
> | that no dependency should be added, removed or moved to different
position
> | witin the pom. The algorithm which resolves transitive dependencies is
> very
> | fragile: it is even (accordingly to my knowledge) sensitive to the
> position
> | of the dependency in the pom.
>
> If I understand correctly, you're alluding to the use of the nearest
> dependency-version taking precedence in a collision scenario. This is
> the default policy for m2, but doesn't have to be the only one. Before
> we release m2 final, we will allow (if we don't already) pluggable
> dependency-version conflict resolution policies. I don't agree that the
> transitive dep algorithm is so fragile, particularly when you change the
> version conflict policy...can you be more specific, or will this remain
> an unsubstantiated claim?
Sure I can be more specific.
The algorithm which resolves transitive dependecies does two things:
a) Iterates throgh graph of dependecies
b) Collects some of them into the list appling some conflict resolution
strategy.
Let's analyse togther the following example (and you tell me if I am am
wrong)
We have 4 projects: A, B, C, D
<project> (typical "naked" pom)
<artifactId>A</artifactId>
...
<dependencies/>
</project>
<project>
<artifactId>B</artifactId>
...
<dependencies>
<dependency>
<artifactId>foo</artifactId>
<version>1.1</version>
</dependency>
<dependency>
<dependencies>
</project>
<project>
<artifactId>C</artifactId>
...
<dependencies>
<dependency>
<artifactId>foo</artifactId>
<version>1.2</version>
</dependency>
</dependencies>
</project>
<project>
<artifactId>D</artifactId>
...
<dependencies>
<dependency>
<artifactId>A</artifactId>
</dependency>
<dependency>
<artifactId>B</artifactId>
</dependency>
<dependency>
<artifactId>C</artifactId>
</dependency>
</dependencies>
</project>
When you will be building D
m2 will use foo 1.1 as dependency.
If you will change D to (B and C changed their positions):
<project>
<artifactId>D</artifactId>
...
<dependencies>
<dependency>
<artifactId>A</artifactId>
</dependency>
<dependency>
<artifactId>C</artifactId>
</dependency>
<dependency>
<artifactId>D</artifactId>
</dependency>
</dependencies>
</project>
you will have foo 1.2 as dependency in D.
Now if you will change pom A - that's what's happening now often to
naked poms -
and you will add there some dependencies:
<project>
<artifactId>A</artifactId>
...
<dependencies>
<dependency>
<artifactId>foo</artifactId>
<version>1.3</version>
</dependency>
<dependency>
<dependencies>
</project>
you will have foo 1.3 as dependency in D.
That's how the current policy works.
But there is nothing wrong with it per se - it is impossble to invent
version conflict policy,
which will be insensitive to chages in graph structure (introduced by
changes in individual POMs)
other then the one which is currently used in ... m1:
you explicitly have to list all you dependencies and don't use transtive
dependenies at all.
If the change like the last one (to pom A) will be done after projet D
was relased suddenly
diffrent dependecy from the one which was used during the release will
be imposed on all users
of D (if they are using transitive dependencies).
Devloper of "D" obiously cannot predict such change or what's worst he
may be unaware of it
as long as he is not going to purge his local repository.
And it is not only the issue with conflict resolution. You may add
second, somehow
incompatible xml parser etc in some projects.
[...]
>
>
> My advice: If you're unhappy with the state of the m2 repository, then
> by all means show us where the problem areas are.
Here you are: For me the problem with the respoitory is that it is
constanly changing.
I wish to hear if this will be always a case or you are going to freeze
it from some point
in time. As this will help to evoluate the best strategy for using
public maven repository.
> Submit a MEV issue or
> two, if you will. But cracking a whip over our heads without
> contributing anything the least bit constructive doesn't in any way help
> this development process.
>
I never saw anybody mentionaing this point: so I though it is
constructive for you
to hear what is the feature some users will expect from m2 repository.
> Regards,
>
regards
Michal
----------------------------------------------------------------------
Najnowsze wiadomosci!!! >>> http://link.interia.pl/f18a0
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
