On 25/05/2007, at 6:55 PM, Mark Hobson wrote:
On 25/05/07, Brett Porter <[EMAIL PROTECTED]> wrote:
On 25/05/2007, at 12:57 AM, Mark Hobson wrote:
> Looks like an infinite loop in the first DefaultDownloader.download
> method.
Not sure what you're saying - you've tried it and it doesn't work, or
you just looked at the code and saw a problem?
I looked at the code and was interested in how the local
ArtifactRepository was obtained from a String path, since the first
download method accepts a File and should delegate to the second
download method which accepts an ArtifactRepository. I just noted
that this delegation doesn't actually happen since the File-based
download method simply invokes itself. See:
http://svn.apache.org/repos/asf/maven/shared/trunk/maven-downloader/
src/main/java/org/apache/maven/shared/downloader/
DefaultDownloader.java
Heh. Nice catch! Can you get that into JIRA?
> Right, is there an issue open for this? Could be easier just to
fix
> this, although I guess it'd make the release plugin require 2.0.7 -
> would that be acceptable?
No, I don't think plugins should ever depend on an unreleased version
of Maven since they are adopted faster.
Sure, I was envisaging that it could be fixed in 2.0.7 after which the
release plugin could have 2.0.7 as a prerequisite.
Still an unreleased version :)
I also think that change would be for 2.1 anyway.
Even though it's really a bug fix?
I'm not sure it's going to be a simple fix - it's really going to
need a functional enhancement.
If you consider the other dependencies as being present, you still
need to ensure the goal is running in a phase when the dependencies
will actually exist. If install wasn't called, then that won't be the
case (or at least package if the packaged artifacts can be used from
the target directory).
On 26/05/2007, at 2:01 AM, Mark Hobson wrote:
On 25/05/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
Sure, I was envisaging that it could be fixed in 2.0.7 after which
the
release plugin could have 2.0.7 as a prerequisite.
I've had a look at the code required to simulate
@requiresDependencyResolution, but it will require 2.0.6 due to the
changes introduced by MNG-1577. If we have to depend on 2.0.6, does
it not make sense to fix the root of the problem in 2.0.7 and depend
on that instead?
I'm not sure I understand why 2.0.6/MNG-1577 is required to simulate
@rDR - other plugins already do it on prior versions. However, I'm
still not in favour of the release plugin depending on an unreleased
version of Maven (even if the root problem can be fixed in 2.0.7).
With regard to the proposed solution:
However, there is an alternative: you can combine the reactor
projects (which you should have), with the artifacts returned from
manual resolution (and using the filtering to omit the projects in
the reactor when you perform that).
I'm not sure this will work since the reactor projects would be
filtered from the project's dependencies, thus their transitive
dependencies would not be resolved. Is the effect we're trying to
achieve more akin to putting the reactor project artifacts into the
managed dependencies map?
Yes, I see what you mean. I'm not sure putting them into the managed
dependencies map will help, as they still won't resolve if they
aren't installed.
So the sequence might need to be:
- resolve the project dependencies, filtering out the reactor projects
- add the reactor projects to the list of resolved artifacts
- iterate through the reactor projects and resolve each's
dependencies (again filtering the reactor projects) and add to the
list of resolved artifacts.
Does that make sense?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
