On 04/10/2010, at 6:06 PM, Marcus Linke wrote:
> OK accepted. But if this shouldn't be within the responsibility of the
> release plugin but of the versions plugin, do you know a possibility to
> hide this versions plugin goal execution from the users point of view? So
> is there a way to hook in
On 04/10/2010, at 10:36 PM, Marcus Linke wrote:
> Hi brett, of course it is. So should i open a new issue for this feature
> in the JIRA or will you do so? ;)
It's all yours.
- Brett
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
--
Hi brett, of course it is. So should i open a new issue for this feature
in the JIRA or will you do so? ;)
"Maven Developers List" writes:
>On 04/10/2010, at 6:06 PM, Marcus Linke wrote:
>
>> OK accepted. But if this shouldn't be within the responsibility of the
>> release plugin but of the vers
OK accepted. But if this shouldn't be within the responsibility of the
release plugin but of the versions plugin, do you know a possibility to
hide this versions plugin goal execution from the users point of view? So
is there a way to hook in the versions plugin goal execution into the
release proc
On 30/09/2010, at 7:05 PM, Marcus Linke wrote:
> For my own usecase where we have strongly coupled projects and usually
> changes are made in both projects we desire behavior b) but other users
> would like prefer behavior a).
Understood, but we're talking about the default behaviour, and it see
The part where you say:
>> I retained one exception for the use case where it was a more recent
>> snapshot than the release you selected, and the original choice is restored.
I like (+1).
One use case I see for this is where the dependency is actually a parent pom.
Here's an example:
Conside
On 2010-09-29 15:50, Brett Porter wrote:
> Hi,
>
> The release plugin has a mode where it can assist you in updating snapshot
> dependencies at release time. A lot of this is better manipulated with the
> versions plugin now, but it seems a useful feature to have at release time if
> you can.
>
> The first question was redundant - you'd already said you wanted to update
> snapshots and the other option is failure. The second one assumes you'll be
> setting the snapshot to the equivalent release, then automatically to the
> next dev't version. The inflexibility of the first part was poi
The release plugin must avoid snapshot dependencies in the release of an
artifact. This is true. But the question is whether the dependency is
kicked to the next snapshot in the next development version of that
artifact or it stays at the release version. For example project A depends
on artifact B
+1
On 29 September 2010 14:50, Brett Porter wrote:
> Hi,
>
> The release plugin has a mode where it can assist you in updating snapshot
> dependencies at release time. A lot of this is better manipulated with the
> versions plugin now, but it seems a useful feature to have at release time
> if y
+1 too.
Personnally I'd like we fix MRELEASE-594 too.
IMHO it's not a "normal" practice and cause some issues when releasing childs.
We should at least ask user thru an interactive question "Are you sure
you want to release with SNAPSHOT declaration(s) in depMgmt ?" (or
something similar).
WDYT
>>>
>>
>> That's what it does - it still fails if there are snapshots. It gives you
>> the option if it finds a snapshot to let you change that to a released
>> version.
>
> What's the use case here? You have a snapshot of log4j and there's a release
> version you can use?
>
> POM says 2.0-S
Brett Porter wrote:
However, I disagree with the default choice of updating the dependency to
another snapshot - since this is outside of the reactor it's a better practice
to pin to the release you just chose. I retained one exception for the use case
where it was a more recent snapshot than
On Sep 29, 2010, at 11:25 AM, Brett Porter wrote:
>
> On 29/09/2010, at 11:57 PM, Jason van Zyl wrote:
>
>>
>> On Sep 29, 2010, at 9:50 AM, Brett Porter wrote:
>>
>>> Hi,
>>>
>>> The release plugin has a mode where it can assist you in updating snapshot
>>> dependencies at release time. A l
On 29/09/2010, at 11:57 PM, Jason van Zyl wrote:
>
> On Sep 29, 2010, at 9:50 AM, Brett Porter wrote:
>
>> Hi,
>>
>> The release plugin has a mode where it can assist you in updating snapshot
>> dependencies at release time. A lot of this is better manipulated with the
>> versions plugin now
On Sep 29, 2010, at 9:50 AM, Brett Porter wrote:
> Hi,
>
> The release plugin has a mode where it can assist you in updating snapshot
> dependencies at release time. A lot of this is better manipulated with the
> versions plugin now, but it seems a useful feature to have at release time if
>
Hi,
The release plugin has a mode where it can assist you in updating snapshot
dependencies at release time. A lot of this is better manipulated with the
versions plugin now, but it seems a useful feature to have at release time if
you can.
The previous behaviour was a bit weird, though. It wo
---
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/snapsh
On 5/18/07, Evan Worley <[EMAIL PROTECTED]> wrote:
Barrie,
Have you tried running with the "U" option? This forces maven to check for
snapshot updates. If you don't specify the U option, maven will check for
updates according to your snapshot update policy interval. I believe the
default is o
Barrie,
Have you tried running with the "U" option? This forces maven to check for
snapshot updates. If you don't specify the U option, maven will check for
updates according to your snapshot update policy interval. I believe the
default is once a day.
-Evan
On 5/16/07, Barrie Treloar <[EMAI
On 5/17/07, Brett Porter <[EMAIL PROTECTED]> wrote:
Hi Zak,
Your interpretation sounds correct, so I'm not sure why that happens
incorrectly. Do you see this every time, or only in a clean repository?
The metadata file is indeed used to determine the latest - check the
lastUpdated timestamp ins
Hi Zak,
Your interpretation sounds correct, so I'm not sure why that happens
incorrectly. Do you see this every time, or only in a clean repository?
The metadata file is indeed used to determine the latest - check the
lastUpdated timestamp inside the file. The locally installed version
is
Hi -
I have a question about how mvn determines when to pull a snapshot
dependency from the local repository vs. the remote repository. We have the
following scenario:
CruiseControl publishes snapshot builds on each successful build.
moduleA depends on moduleB and moduleC, all versions and de
23 matches
Mail list logo
