You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2008/07/07 09:29:25 UTC
Maven dependencies on itself.
Maybe this won't strike you as strange but it did me. I ran a mvn
install on a project using 2.0.9. In the course of that
maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and
maven-project-2.0.9 were downloaded, installed into the local repo and
then used in the build. As you would expect this is due to the use of
the various plugins used during the build. Knowing what I know about
maven I understand why this us. But the question remains, doesn't this
just seem wrong? Shouldn't maven 2.0.9 only use maven 2.0.9 jars?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Ralph Goers <Ra...@dslextreme.com>.
Yes, looking at the log it is clear that they are ignored. Yet when I
was running under my IntelliJ debugger in one case it actually stepped
into the 2.0 version of DefaultMavenProjectBuilder. I don't really know
why. But I couldn't debug it since I had the 2.0.9 version of the source
and it was only showing me the class file.
As you may or may not know, I'm not a fan of "intelligent resolution of
versions", especially since artifacts can't declare how they are
compatible with their various versions. I don't believe that relying on
projects "knowing" what versions of their dependencies they are
compatible with won't scale and will lead to incorrect version ranges
all over the place.
I guess I'd rather see Maven be able to automatically add
managedDependencies for the Maven artifacts to the plugins it ships
with. Unfortunately, that isn't really possible since plugins can't have
a dependencyManagement section.
Ralph
Brett Porter wrote:
> Yes.
>
> Considering that Maven will actually only use the built-in ones at
> runtime for plugins it is actually quite silly to download all the
> other ones for plugins.
>
> Though this is really indicative of a wider problem where we don't do
> much in the way of intelligent resolution of versions. Hopefully this
> is something any work on the artifact code works to address.
>
> - Brett
>
> On 07/07/2008, at 5:29 PM, Ralph Goers wrote:
>
>> Maybe this won't strike you as strange but it did me. I ran a mvn
>> install on a project using 2.0.9. In the course of that
>> maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and
>> maven-project-2.0.9 were downloaded, installed into the local repo
>> and then used in the build. As you would expect this is due to the
>> use of the various plugins used during the build. Knowing what I know
>> about maven I understand why this us. But the question remains,
>> doesn't this just seem wrong? Shouldn't maven 2.0.9 only use maven
>> 2.0.9 jars?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Brett Porter <br...@apache.org>.
Yes.
Considering that Maven will actually only use the built-in ones at
runtime for plugins it is actually quite silly to download all the
other ones for plugins.
Though this is really indicative of a wider problem where we don't do
much in the way of intelligent resolution of versions. Hopefully this
is something any work on the artifact code works to address.
- Brett
On 07/07/2008, at 5:29 PM, Ralph Goers wrote:
> Maybe this won't strike you as strange but it did me. I ran a mvn
> install on a project using 2.0.9. In the course of that maven-
> project-2.0, maven-project-2.0.6, maven-2.0.7, and maven-
> project-2.0.9 were downloaded, installed into the local repo and
> then used in the build. As you would expect this is due to the use
> of the various plugins used during the build. Knowing what I know
> about maven I understand why this us. But the question remains,
> doesn't this just seem wrong? Shouldn't maven 2.0.9 only use maven
> 2.0.9 jars?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Jason van Zyl <ja...@maven.org>.
On 7-Jul-08, at 10:42 AM, Ralph Goers wrote:
> Jason van Zyl wrote:
>>
>>
>> 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.
>>
> Again, what metadata? The filter isn't metadata.
There is the metadata and then the process that acts on the metadata.
The filter is obviously not metadata but can be created from metadata
(we just happen to do it by hand now). The information about every
plugin and artifact that would be used as part of a session we do
have. We also know what is in the distribution. Given all the
information we can look at everything and not download 7 versions of
maven-core.
>
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jason van Zyl wrote:
>
>
> 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.
>
Again, what metadata? The filter isn't metadata.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Oleg Gusakov <ol...@gmail.com>.
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.
>>
>
> Yes, but downloading the set once known is relatively easy compared to
> finding out what's required. What's import is that the two processes
> are separated.
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.
>
>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Jason van Zyl <ja...@maven.org>.
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.
>
Yes, but downloading the set once known is relatively easy compared to
finding out what's required. What's import is that the two processes
are separated.
> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Oleg Gusakov <ol...@gmail.com>.
Barrie Treloar wrote:
> On Wed, Jul 9, 2008 at 2:05 AM, Oleg Gusakov
> <ol...@gmail.com> wrote:
>
>> At the moment - metadata includes a URI to the actual binary. I am working
>> on integrating it with a new delivery vehicle, and that will be the "first"
>> found. So all is defined by the order of repositories. As Nexus repository
>> manager hides all those complexities - I don't want to worry too much about
>> this issue for now, in most cases - Nexus will be the only repository
>> visible on the client anyway.
>>
>
> Can you explain this a bit further please?
> The client should be using the correct URI for the request, but is
> redirected to the the "proxy".
> So the repository order should not impact the metadata resolution.
>
I outlined the "3 phase" resolution process in
http://docs.codehaus.org/display/MAVEN/SAT+Based+Dependency+Resolution
In short - metadata is collected first. The piece of metadata is URI of
the binary. Then dependency tree [graph] - is resolved for conflicts,
which leaves only valid artifacts metadata. Then this metadata is used
to locate and download the actual binaries. Whatever URI Nexus will give
me with the metadata, will be used to get the binary.
If Nexus is not in the picture and remote repositories are dumb http
file systems, the order will matter. The one where md is found, will be
in the URI. Which will be the one first searched - TBD
Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
Re: Maven dependencies on itself.
Posted by Barrie Treloar <ba...@gmail.com>.
On Wed, Jul 9, 2008 at 2:05 AM, Oleg Gusakov
<ol...@gmail.com> wrote:
> At the moment - metadata includes a URI to the actual binary. I am working
> on integrating it with a new delivery vehicle, and that will be the "first"
> found. So all is defined by the order of repositories. As Nexus repository
> manager hides all those complexities - I don't want to worry too much about
> this issue for now, in most cases - Nexus will be the only repository
> visible on the client anyway.
Can you explain this a bit further please?
The client should be using the correct URI for the request, but is
redirected to the the "proxy".
So the repository order should not impact the metadata resolution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Oleg Gusakov <ol...@gmail.com>.
Barrie Treloar wrote:
> On Tue, Jul 8, 2008 at 1:49 AM, Oleg Gusakov
> <ol...@gmail.com> wrote:
>
>> 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.
>>
>> Oleg
>>
>
> Are you handling the problem of "Single Artifact can not be available
> on multiple repositories"?
> http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins
> http://www.nabble.com/forum/ViewPost.jtp?post=7884079&framed=y&skin=177
>
> The metadata needs to include the repository that the artifact is
> available from.
At the moment - metadata includes a URI to the actual binary. I am
working on integrating it with a new delivery vehicle, and that will be
the "first" found. So all is defined by the order of repositories. As
Nexus repository manager hides all those complexities - I don't want to
worry too much about this issue for now, in most cases - Nexus will be
the only repository visible on the client anyway.
Oleg
> At the moment i think it uses the "last" repository
> searched.
>
> Cheers
> Barrie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
Re: Maven dependencies on itself.
Posted by Barrie Treloar <ba...@gmail.com>.
On Tue, Jul 8, 2008 at 1:49 AM, Oleg Gusakov
<ol...@gmail.com> wrote:
> 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.
>
> Oleg
Are you handling the problem of "Single Artifact can not be available
on multiple repositories"?
http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins
http://www.nabble.com/forum/ViewPost.jtp?post=7884079&framed=y&skin=177
The metadata needs to include the repository that the artifact is
available from. At the moment i think it uses the "last" repository
searched.
Cheers
Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Oleg Gusakov <ol...@gmail.com>.
Jason van Zyl wrote:
>
> On 7-Jul-08, at 10:19 AM, Ralph Goers wrote:
>
>>
>>
>> Jason van Zyl wrote:
>>>
>>> On 7-Jul-08, at 3:29 AM, Ralph Goers wrote:
>>>
>>>> Maybe this won't strike you as strange but it did me. I ran a mvn
>>>> install on a project using 2.0.9. In the course of that
>>>> maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and
>>>> maven-project-2.0.9 were downloaded, installed into the local repo
>>>> and then used in the build. As you would expect this is due to the
>>>> use of the various plugins used during the build. Knowing what I
>>>> know about maven I understand why this us. But the question
>>>> remains, doesn't this just seem wrong? Shouldn't maven 2.0.9 only
>>>> use maven 2.0.9 jars?
>>>
>>> Yes, it's wrong. It's become the metadata is not processed first and
>>> then the artifacts selected. It's done incrementally along the way
>>> which is wrong and inefficient. This is the whole crux of what Oleg
>>> is working on with the new artifact resolution code. Metadata
>>> analysis first, artifact retrieval second. What you are seeing will
>>> not happen with the code.
>>>
>> How does Oleg's code fix this? The problem doesn't have to do with
>> how metadata is processed and then artifacts selected.
>
> 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.
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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Jason van Zyl <ja...@maven.org>.
On 7-Jul-08, at 10:19 AM, Ralph Goers wrote:
>
>
> Jason van Zyl wrote:
>>
>> On 7-Jul-08, at 3:29 AM, Ralph Goers wrote:
>>
>>> Maybe this won't strike you as strange but it did me. I ran a mvn
>>> install on a project using 2.0.9. In the course of that maven-
>>> project-2.0, maven-project-2.0.6, maven-2.0.7, and maven-
>>> project-2.0.9 were downloaded, installed into the local repo and
>>> then used in the build. As you would expect this is due to the use
>>> of the various plugins used during the build. Knowing what I know
>>> about maven I understand why this us. But the question remains,
>>> doesn't this just seem wrong? Shouldn't maven 2.0.9 only use maven
>>> 2.0.9 jars?
>>
>> Yes, it's wrong. It's become the metadata is not processed first
>> and then the artifacts selected. It's done incrementally along the
>> way which is wrong and inefficient. This is the whole crux of what
>> Oleg is working on with the new artifact resolution code. Metadata
>> analysis first, artifact retrieval second. What you are seeing will
>> not happen with the code.
>>
> How does Oleg's code fix this? The problem doesn't have to do with
> how metadata is processed and then artifacts selected.
That's exactly what the problem is.
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jason van Zyl wrote:
>
> On 7-Jul-08, at 3:29 AM, Ralph Goers wrote:
>
>> Maybe this won't strike you as strange but it did me. I ran a mvn
>> install on a project using 2.0.9. In the course of that
>> maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and
>> maven-project-2.0.9 were downloaded, installed into the local repo
>> and then used in the build. As you would expect this is due to the
>> use of the various plugins used during the build. Knowing what I know
>> about maven I understand why this us. But the question remains,
>> doesn't this just seem wrong? Shouldn't maven 2.0.9 only use maven
>> 2.0.9 jars?
>
> Yes, it's wrong. It's become the metadata is not processed first and
> then the artifacts selected. It's done incrementally along the way
> which is wrong and inefficient. This is the whole crux of what Oleg is
> working on with the new artifact resolution code. Metadata analysis
> first, artifact retrieval second. What you are seeing will not happen
> with the code.
>
How does Oleg's code fix this? The problem doesn't have to do with how
metadata is processed and then artifacts selected. The problem is that
nowhere are the plugins told that maven 2.0.9 jars should be used
instead of whatever they specified. 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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Jason van Zyl <ja...@maven.org>.
On 7-Jul-08, at 3:29 AM, Ralph Goers wrote:
> Maybe this won't strike you as strange but it did me. I ran a mvn
> install on a project using 2.0.9. In the course of that maven-
> project-2.0, maven-project-2.0.6, maven-2.0.7, and maven-
> project-2.0.9 were downloaded, installed into the local repo and
> then used in the build. As you would expect this is due to the use
> of the various plugins used during the build. Knowing what I know
> about maven I understand why this us. But the question remains,
> doesn't this just seem wrong? Shouldn't maven 2.0.9 only use maven
> 2.0.9 jars?
Yes, it's wrong. It's become the metadata is not processed first and
then the artifacts selected. It's done incrementally along the way
which is wrong and inefficient. This is the whole crux of what Oleg is
working on with the new artifact resolution code. Metadata analysis
first, artifact retrieval second. What you are seeing will not happen
with the code.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven dependencies on itself.
Posted by Dennis Lundberg <de...@apache.org>.
Ralph Goers wrote:
> Maybe this won't strike you as strange but it did me. I ran a mvn
> install on a project using 2.0.9. In the course of that
> maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and
> maven-project-2.0.9 were downloaded, installed into the local repo and
> then used in the build. As you would expect this is due to the use of
> the various plugins used during the build. Knowing what I know about
> maven I understand why this us. But the question remains, doesn't this
> just seem wrong? Shouldn't maven 2.0.9 only use maven 2.0.9 jars?
One thing we could do to at least minimize the confusion, is to
synchronize the versions of dependencies on Maven artifacts in a project.
Say that we have plugin A that has a prerequisite of Maven 2.0.6. Then
all Maven dependencies in plugin A, that are included in the Maven core,
should be set to version 2.0.6. Then at least only artifacts of that
particular Maven version is downloaded when plugin A is executed.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org