You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by ep...@apache.org on 2007/02/01 03:46:12 UTC
svn commit: r502089 -
/maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Author: epunzalan
Date: Wed Jan 31 18:46:11 2007
New Revision: 502089
URL: http://svn.apache.org/viewvc?view=rev&rev=502089
Log:
require dependency resolution so snapshot dependency artifacts checking will work
Modified:
maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Modified: maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
URL: http://svn.apache.org/viewvc/maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java?view=diff&rev=502089&r1=502088&r2=502089
==============================================================================
--- maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java (original)
+++ maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java Wed Jan 31 18:46:11 2007
@@ -34,6 +34,7 @@
* @author <a href="mailto:brett@apache.org">Brett Porter</a>
* @version $Id$
* @aggregator
+ * @requiresDependencyResolution test
* @goal prepare
* @todo [!] check how this works with version ranges
*/
Re: release plugin dependency resolution (was: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java)
Posted by Mark Hobson <ma...@gmail.com>.
On 01/06/07, Brett Porter <br...@apache.org> wrote:
> Hi Mark,
>
> Sure, jump on in your morning (or grab me on google talk, yahoo,
> skype :). I'll still be here. Emmanuel should be around then too, and
> he's done the most work on the release plugin recently.
>
> We can post back with what we figure out...
The result of this discussion was to add @rDR back into
release:prepare with the caveat of MNG-3023. I'll attach a patch for
this against MRELEASE-240.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: release plugin dependency resolution (was: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java)
Posted by Brett Porter <br...@apache.org>.
Hi Mark,
Sure, jump on in your morning (or grab me on google talk, yahoo,
skype :). I'll still be here. Emmanuel should be around then too, and
he's done the most work on the release plugin recently.
We can post back with what we figure out...
- Brett
On 01/06/2007, at 1:36 AM, Mark Hobson wrote:
> On 30/05/07, Mark Hobson <ma...@gmail.com> wrote:
>> On 29/05/07, Brett Porter <br...@apache.org> wrote:
>> > 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?
>>
>> Possibly, I'll consider it properly tomorrow and let you of the
>> next problem ;)
>
> I don't think this will work since the ArtifactCollector would be
> bypassed when merging the two sets of dependencies together. This is
> becoming quite some workaround - why not add @rDR back in and have
> 'mvn install' as a workaround to MNG-3023?
>
> Brett, are you available on IRC sometime to chat this through? I'm
> GMT+1, so could be tricky :)
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: release plugin dependency resolution (was: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java)
Posted by Mark Hobson <ma...@gmail.com>.
On 30/05/07, Mark Hobson <ma...@gmail.com> wrote:
> On 29/05/07, Brett Porter <br...@apache.org> wrote:
> > 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?
>
> Possibly, I'll consider it properly tomorrow and let you of the next problem ;)
I don't think this will work since the ArtifactCollector would be
bypassed when merging the two sets of dependencies together. This is
becoming quite some workaround - why not add @rDR back in and have
'mvn install' as a workaround to MNG-3023?
Brett, are you available on IRC sometime to chat this through? I'm
GMT+1, so could be tricky :)
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: release plugin dependency resolution (was: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java)
Posted by Mark Hobson <ma...@gmail.com>.
On 29/05/07, Brett Porter <br...@apache.org> wrote:
> Heh. Nice catch! Can you get that into JIRA?
Done: http://jira.codehaus.org/browse/MNG-3015
> > 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 meant: fix in 2.0.7-SNAPSHOT; release 2.0.7; depend on 2.0.7 - but
I'm sure you got my drift already ;)
> >> 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).
Yeah, it's probably not going to be easy. I've created a failing IT
and raised this issue to keep track of it:
http://jira.codehaus.org/browse/MNG-3023
Feel free to sanity check it if you've got time.
On 29/05/07, Brett Porter <br...@apache.org> wrote:
> 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).
MNG-1577 introduced an API change with
MavenProject.getManagedVersionMap, which is used by the artifact
resolving code I'll be simulating in
DefaultPluginManager.resolveTransitiveDependencies. Surely MNG-1577
will affect the resolved versions used in the release pom, so we can't
use the 2.0 API and expect MNG-1577 style results?
> 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?
Possibly, I'll consider it properly tomorrow and let you of the next problem ;)
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: release plugin dependency resolution (was: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java)
Posted by Brett Porter <br...@apache.org>.
On 25/05/2007, at 6:55 PM, Mark Hobson wrote:
> On 25/05/07, Brett Porter <br...@apache.org> 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 <ma...@gmail.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Mark Hobson <ma...@gmail.com>.
On 25/05/07, Mark Hobson <ma...@gmail.com> 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?
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?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Mark Hobson <ma...@gmail.com>.
On 25/05/07, Brett Porter <br...@apache.org> 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
> > 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.
> I also think that change would be for 2.1 anyway.
Even though it's really a bug fix?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Brett Porter <br...@apache.org>.
On 25/05/2007, at 12:57 AM, Mark Hobson wrote:
> On 24/05/07, Brett Porter <br...@apache.org> wrote:
>> Yep, there's a few examples of plugins that re-use the resolution
>> mechanism and though I've never used it maven-downloader is meant to
>> encapsulate that in an easy to use API as well.
>
> 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?
>
>> The reactor is not considered at the moment, which is the problem in
>> this case.
>
> 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.
I also think that change would be for 2.1 anyway.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Mark Hobson <ma...@gmail.com>.
On 24/05/07, Brett Porter <br...@apache.org> wrote:
> Yep, there's a few examples of plugins that re-use the resolution
> mechanism and though I've never used it maven-downloader is meant to
> encapsulate that in an easy to use API as well.
Looks like an infinite loop in the first DefaultDownloader.download method.
> The reactor is not considered at the moment, which is the problem in
> this case.
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?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Brett Porter <br...@apache.org>.
On 23/05/2007, at 8:27 PM, Mark Hobson wrote:
> On 21/05/07, Brett Porter <br...@apache.org> wrote:
>> Using the manual resolution would only work if an earlier step in the
>> release:prepare process had definitely built all the dependencies.
>>
>> 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 think I see what you mean. Do you envisage similar code to
> DefaultPluginManager.resolveTransitiveDependencies? Only problem is
> that I haven't got access to a MavenSession to obtain the local repo -
> is that obtainable any other way?
Yep, there's a few examples of plugins that re-use the resolution
mechanism and though I've never used it maven-downloader is meant to
encapsulate that in an easy to use API as well.
>
>> Long term, we should reintroduce the tag when Maven itself can
>> properly cope with the projects not being installed.
>
> How would @requiresDependencyResolution resolve dependencies if they
> weren't in a repo nor the reactor? Or is the reactor not considered
> at the moment?
The reactor is not considered at the moment, which is the problem in
this case.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Mark Hobson <ma...@gmail.com>.
On 21/05/07, Brett Porter <br...@apache.org> wrote:
> Using the manual resolution would only work if an earlier step in the
> release:prepare process had definitely built all the dependencies.
>
> 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 think I see what you mean. Do you envisage similar code to
DefaultPluginManager.resolveTransitiveDependencies? Only problem is
that I haven't got access to a MavenSession to obtain the local repo -
is that obtainable any other way?
> Long term, we should reintroduce the tag when Maven itself can
> properly cope with the projects not being installed.
How would @requiresDependencyResolution resolve dependencies if they
weren't in a repo nor the reactor? Or is the reactor not considered
at the moment?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Brett Porter <br...@apache.org>.
Using the manual resolution would only work if an earlier step in the
release:prepare process had definitely built all the dependencies.
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).
Long term, we should reintroduce the tag when Maven itself can
properly cope with the projects not being installed.
- Brett
On 22/05/2007, at 2:26 AM, Mark Hobson wrote:
> On 01/02/07, Brett Porter <br...@apache.org> wrote:
>> Edwin - can we double check the requirement here. I recently removed
>> this to prevent the problem of it failing if you haven't installed
>> the project first.
>
> I was planning to reintroduce @requiresDependencyResolution test on
> release:prepare to generate release poms, since we need the resolved
> artifact versions from project.getArtifacts. Would a manual
> ArtifactResolver.resolveTransitively be any better that introducing
> this annotation, or is there an alternative method of resolving
> artifact versions?
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Mark Hobson <ma...@gmail.com>.
On 01/02/07, Brett Porter <br...@apache.org> wrote:
> Edwin - can we double check the requirement here. I recently removed
> this to prevent the problem of it failing if you haven't installed
> the project first.
I was planning to reintroduce @requiresDependencyResolution test on
release:prepare to generate release poms, since we need the resolved
artifact versions from project.getArtifacts. Would a manual
ArtifactResolver.resolveTransitively be any better that introducing
this annotation, or is there an alternative method of resolving
artifact versions?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Edwin Punzalan <ep...@exist.com>.
But you have a point... i don't think we need transitivity here. If a
dependency is already released, then we can *assume* that it has no
SNAPSHOT dependency as well.
I'll look into it. Thanks.
Brett Porter wrote:
> I see - I suppose it is only failing when the artifacts are not
> present in the repository already, as it was working for me...
>
> Can the code using getArtifacts() be changed to getDependencies()
> without changing the meaning? (Sorry, I haven't looked, I just know
> the dep resolution was problematic)
>
> - Brett
>
> On 01/02/2007, at 2:54 PM, Edwin Punzalan wrote:
>
>> Brett,
>>
>> Its failing in phase check-dependency-snapshot phase... the phase
>> uses project.getArtifacts() which is not populated when its missing
>>
>>
>> Brett Porter wrote:
>>> Edwin - can we double check the requirement here. I recently removed
>>> this to prevent the problem of it failing if you haven't installed
>>> the project first.
>>>
>>> What step does it fail at?
>>>
>>> - Brett
>>>
>>> On 01/02/2007, at 1:46 PM, epunzalan@apache.org wrote:
>>>
>>>> Author: epunzalan
>>>> Date: Wed Jan 31 18:46:11 2007
>>>> New Revision: 502089
>>>>
>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502089
>>>> Log:
>>>> require dependency resolution so snapshot dependency artifacts
>>>> checking will work
>>>>
>>>> Modified:
>>>>
>>>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>>>
>>>>
>>>> Modified:
>>>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>>>
>>>> URL:
>>>> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java?view=diff&rev=502089&r1=502088&r2=502089
>>>>
>>>> ==============================================================================
>>>>
>>>> ---
>>>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>>> (original)
>>>> +++
>>>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>>> Wed Jan 31 18:46:11 2007
>>>> @@ -34,6 +34,7 @@
>>>> * @author <a href="mailto:brett@apache.org">Brett Porter</a>
>>>> * @version $Id$
>>>> * @aggregator
>>>> + * @requiresDependencyResolution test
>>>> * @goal prepare
>>>> * @todo [!] check how this works with version ranges
>>>> */
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
> ---------------------------------------------------------------------
> 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: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Brett Porter <br...@apache.org>.
On 01/02/2007, at 3:57 PM, Edwin Punzalan wrote:
>
> getArtifacts is transitive and getDependencies isn't.
Right - that's what I was sort of implying - does the affect the code
in question? I would have thought that for this phase, it wouldn't -
but I could be (probably am?) wrong.
> How about a manual artifact resolution using the project builder ?
Yes good thinking - that's what I thought would be a possible
alternative, but it's a bit ugly. Probably worth it though, as the
failure is a pain either way.
- Brett
>
>
> Brett Porter wrote:
>> I see - I suppose it is only failing when the artifacts are not
>> present in the repository already, as it was working for me...
>>
>> Can the code using getArtifacts() be changed to getDependencies()
>> without changing the meaning? (Sorry, I haven't looked, I just
>> know the dep resolution was problematic)
>>
>> - Brett
>>
>> On 01/02/2007, at 2:54 PM, Edwin Punzalan wrote:
>>
>>> Brett,
>>>
>>> Its failing in phase check-dependency-snapshot phase... the
>>> phase uses project.getArtifacts() which is not populated when its
>>> missing
>>>
>>>
>>> Brett Porter wrote:
>>>> Edwin - can we double check the requirement here. I recently
>>>> removed this to prevent the problem of it failing if you haven't
>>>> installed the project first.
>>>>
>>>> What step does it fail at?
>>>>
>>>> - Brett
>>>>
>>>> On 01/02/2007, at 1:46 PM, epunzalan@apache.org wrote:
>>>>
>>>>> Author: epunzalan
>>>>> Date: Wed Jan 31 18:46:11 2007
>>>>> New Revision: 502089
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502089
>>>>> Log:
>>>>> require dependency resolution so snapshot dependency artifacts
>>>>> checking will work
>>>>>
>>>>> Modified:
>>>>> maven/release/trunk/maven-release-plugin/src/main/java/org/
>>>>> apache/maven/plugins/release/PrepareReleaseMojo.java
>>>>>
>>>>> Modified: maven/release/trunk/maven-release-plugin/src/main/
>>>>> java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>>>> URL: http://svn.apache.org/viewvc/maven/release/trunk/maven-
>>>>> release-plugin/src/main/java/org/apache/maven/plugins/release/
>>>>> PrepareReleaseMojo.java?view=diff&rev=502089&r1=502088&r2=502089
>>>>> ==================================================================
>>>>> ============
>>>>> --- maven/release/trunk/maven-release-plugin/src/main/java/org/
>>>>> apache/maven/plugins/release/PrepareReleaseMojo.java (original)
>>>>> +++ maven/release/trunk/maven-release-plugin/src/main/java/org/
>>>>> apache/maven/plugins/release/PrepareReleaseMojo.java Wed Jan 31
>>>>> 18:46:11 2007
>>>>> @@ -34,6 +34,7 @@
>>>>> * @author <a href="mailto:brett@apache.org">Brett Porter</a>
>>>>> * @version $Id$
>>>>> * @aggregator
>>>>> + * @requiresDependencyResolution test
>>>>> * @goal prepare
>>>>> * @todo [!] check how this works with version ranges
>>>>> */
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Edwin Punzalan <ep...@exist.com>.
getArtifacts is transitive and getDependencies isn't. How about a
manual artifact resolution using the project builder ?
Brett Porter wrote:
> I see - I suppose it is only failing when the artifacts are not
> present in the repository already, as it was working for me...
>
> Can the code using getArtifacts() be changed to getDependencies()
> without changing the meaning? (Sorry, I haven't looked, I just know
> the dep resolution was problematic)
>
> - Brett
>
> On 01/02/2007, at 2:54 PM, Edwin Punzalan wrote:
>
>> Brett,
>>
>> Its failing in phase check-dependency-snapshot phase... the phase
>> uses project.getArtifacts() which is not populated when its missing
>>
>>
>> Brett Porter wrote:
>>> Edwin - can we double check the requirement here. I recently removed
>>> this to prevent the problem of it failing if you haven't installed
>>> the project first.
>>>
>>> What step does it fail at?
>>>
>>> - Brett
>>>
>>> On 01/02/2007, at 1:46 PM, epunzalan@apache.org wrote:
>>>
>>>> Author: epunzalan
>>>> Date: Wed Jan 31 18:46:11 2007
>>>> New Revision: 502089
>>>>
>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502089
>>>> Log:
>>>> require dependency resolution so snapshot dependency artifacts
>>>> checking will work
>>>>
>>>> Modified:
>>>>
>>>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>>>
>>>>
>>>> Modified:
>>>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>>>
>>>> URL:
>>>> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java?view=diff&rev=502089&r1=502088&r2=502089
>>>>
>>>> ==============================================================================
>>>>
>>>> ---
>>>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>>> (original)
>>>> +++
>>>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>>> Wed Jan 31 18:46:11 2007
>>>> @@ -34,6 +34,7 @@
>>>> * @author <a href="mailto:brett@apache.org">Brett Porter</a>
>>>> * @version $Id$
>>>> * @aggregator
>>>> + * @requiresDependencyResolution test
>>>> * @goal prepare
>>>> * @todo [!] check how this works with version ranges
>>>> */
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
> ---------------------------------------------------------------------
> 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: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Brett Porter <br...@apache.org>.
I see - I suppose it is only failing when the artifacts are not
present in the repository already, as it was working for me...
Can the code using getArtifacts() be changed to getDependencies()
without changing the meaning? (Sorry, I haven't looked, I just know
the dep resolution was problematic)
- Brett
On 01/02/2007, at 2:54 PM, Edwin Punzalan wrote:
> Brett,
>
> Its failing in phase check-dependency-snapshot phase... the phase
> uses project.getArtifacts() which is not populated when its missing
>
>
> Brett Porter wrote:
>> Edwin - can we double check the requirement here. I recently
>> removed this to prevent the problem of it failing if you haven't
>> installed the project first.
>>
>> What step does it fail at?
>>
>> - Brett
>>
>> On 01/02/2007, at 1:46 PM, epunzalan@apache.org wrote:
>>
>>> Author: epunzalan
>>> Date: Wed Jan 31 18:46:11 2007
>>> New Revision: 502089
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=502089
>>> Log:
>>> require dependency resolution so snapshot dependency artifacts
>>> checking will work
>>>
>>> Modified:
>>> maven/release/trunk/maven-release-plugin/src/main/java/org/
>>> apache/maven/plugins/release/PrepareReleaseMojo.java
>>>
>>> Modified: maven/release/trunk/maven-release-plugin/src/main/java/
>>> org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>> URL: http://svn.apache.org/viewvc/maven/release/trunk/maven-
>>> release-plugin/src/main/java/org/apache/maven/plugins/release/
>>> PrepareReleaseMojo.java?view=diff&rev=502089&r1=502088&r2=502089
>>> ====================================================================
>>> ==========
>>> --- maven/release/trunk/maven-release-plugin/src/main/java/org/
>>> apache/maven/plugins/release/PrepareReleaseMojo.java (original)
>>> +++ maven/release/trunk/maven-release-plugin/src/main/java/org/
>>> apache/maven/plugins/release/PrepareReleaseMojo.java Wed Jan 31
>>> 18:46:11 2007
>>> @@ -34,6 +34,7 @@
>>> * @author <a href="mailto:brett@apache.org">Brett Porter</a>
>>> * @version $Id$
>>> * @aggregator
>>> + * @requiresDependencyResolution test
>>> * @goal prepare
>>> * @todo [!] check how this works with version ranges
>>> */
>>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Edwin Punzalan <ep...@exist.com>.
Brett,
Its failing in phase check-dependency-snapshot phase... the phase uses
project.getArtifacts() which is not populated when its missing
Brett Porter wrote:
> Edwin - can we double check the requirement here. I recently removed
> this to prevent the problem of it failing if you haven't installed the
> project first.
>
> What step does it fail at?
>
> - Brett
>
> On 01/02/2007, at 1:46 PM, epunzalan@apache.org wrote:
>
>> Author: epunzalan
>> Date: Wed Jan 31 18:46:11 2007
>> New Revision: 502089
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=502089
>> Log:
>> require dependency resolution so snapshot dependency artifacts
>> checking will work
>>
>> Modified:
>>
>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>
>>
>> Modified:
>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>>
>> URL:
>> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java?view=diff&rev=502089&r1=502088&r2=502089
>>
>> ==============================================================================
>>
>> ---
>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>> (original)
>> +++
>> maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
>> Wed Jan 31 18:46:11 2007
>> @@ -34,6 +34,7 @@
>> * @author <a href="mailto:brett@apache.org">Brett Porter</a>
>> * @version $Id$
>> * @aggregator
>> + * @requiresDependencyResolution test
>> * @goal prepare
>> * @todo [!] check how this works with version ranges
>> */
>>
>
> ---------------------------------------------------------------------
> 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: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
Posted by Brett Porter <br...@apache.org>.
Edwin - can we double check the requirement here. I recently removed
this to prevent the problem of it failing if you haven't installed
the project first.
What step does it fail at?
- Brett
On 01/02/2007, at 1:46 PM, epunzalan@apache.org wrote:
> Author: epunzalan
> Date: Wed Jan 31 18:46:11 2007
> New Revision: 502089
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=502089
> Log:
> require dependency resolution so snapshot dependency artifacts
> checking will work
>
> Modified:
> maven/release/trunk/maven-release-plugin/src/main/java/org/
> apache/maven/plugins/release/PrepareReleaseMojo.java
>
> Modified: maven/release/trunk/maven-release-plugin/src/main/java/
> org/apache/maven/plugins/release/PrepareReleaseMojo.java
> URL: http://svn.apache.org/viewvc/maven/release/trunk/maven-release-
> plugin/src/main/java/org/apache/maven/plugins/release/
> PrepareReleaseMojo.java?view=diff&rev=502089&r1=502088&r2=502089
> ======================================================================
> ========
> --- maven/release/trunk/maven-release-plugin/src/main/java/org/
> apache/maven/plugins/release/PrepareReleaseMojo.java (original)
> +++ maven/release/trunk/maven-release-plugin/src/main/java/org/
> apache/maven/plugins/release/PrepareReleaseMojo.java Wed Jan 31
> 18:46:11 2007
> @@ -34,6 +34,7 @@
> * @author <a href="mailto:brett@apache.org">Brett Porter</a>
> * @version $Id$
> * @aggregator
> + * @requiresDependencyResolution test
> * @goal prepare
> * @todo [!] check how this works with version ranges
> */
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org