On 08/07/2008, at 2:38 AM, Oleg Gusakov wrote:
Jason van Zyl wrote:
On 7-Jul-08, at 12:19 PM, Oleg Gusakov wrote:
That's exactly what the problem is.
To clarify: the new resolver only cares about metadata, not actual
binary. Current artifact, even as late as 3.0-SN, dictates that
even when you try to get artifact metadata, you get all the goods
in the local repo, and then get the metadata. I am trying the
other way around - get metadata only, resolve conflicts, and then
download actual artifacts that are required.
Colour me confused. I'm not sure what things you're referring to in
each case. The current operation only downloads actual artifacts in
the plugin manager (after complete resolution of the tree), or the
project builder's readProjectWithDependencies (after complete
resolution of the tree). You will get multiple different POM files,
but only one artifact per project, post-resolution. You will get
multiple POMs from all over the shop though.
But I think the point Ralph was making was that you already have the
artifact, and will be forced to use that version of it - yet it goes
off to resolve anyway. It's a completely special case for the maven-*
artifacts that are built in, and the resolution of plugins.
Yep - that's the gist of it. With two processes/phases we can
decouple metadata from the binary and can store it anywhere.
Provided we still maintain a strong grasp on the metadata<->binary
mapping, which we do now with a pom in the same folder.
++1.
I've said it before, I'm in favour of metadata-only repositories
(optionally, the sensible default is to lump them back into the same
structure).
FWIW, I'm also in favour of no longer using the POM as the artifact
metadata, but instead something more repository-oriented, concise, and
extensible for the future that is derived from the POM at deployment
time. The POM would just continue to be deployed as any other
secondary artifact.
Cheers,
Brett
Oleg
The problem is that nowhere are the plugins told that maven
2.0.9 jars should be used instead of whatever they specified.
That is exactly a metadata analysis problem. Look at everything
that might be used and make a selection. Not download everything
and then decide.
Instead, it appears there is some "special" code that checks for
maven jars and as a last step ignores artifacts that are already
part of the distribution. In other words, the metadata to
correctly resolve this isn't even present.
It's all part of looking at the metadata. All the stuff gets
downloaded and then there is an artifact filter which blocks all
artifacts that are in the distribution. If the metadata was
pulled in first. Then it could be compared with what is in the
distribution, along with any other calculations, and then what is
actually required to satisfy the session whether that be
artifacts, plugins, or other resources are retrieved.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
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]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
