On 3/29/07, Brett Porter <[EMAIL PROTECTED]> wrote:
Agreed, in addition to making it easy to lock down your lifecycle
plugin versions. I wonder if I ever sent that proposal out for 2.1...
We just need to manage this as best we can (keep compat on x.y
versions, and separate unstable repo as I posted elsewhere).
Does not work (if you're talking about non snapshot release for unstable)
I tried to release two versions of a plugin to a corporate repo (as a
workaround). So I had maven-war-plugin-2.0.3-preview-1 in my corporate
repo and other standard versions on central.
This lead maven to alway try to get the pom from central which is
obviously not found so it creates a fake one using a template -> boum.
I've discussed this extensively with Kenney and I remember there's
something in Jira but I can't find it back.
IMO, we really need the assembly release. It's been way too long and
it's beta. Can't we fix those things for beta-2?
Stéphane
- Brett
On 29/03/2007, at 11:53 AM, Jason Dillon wrote:
> This is a general problem with the magical RELEASE version that
> plugins use... IMO this is an anti-feature and should be removed in
> general and force people to configure the plugin's version to help
> ensure that future releases of plugins don't break their builds.
>
> --jason
>
>
> On Mar 28, 2007, at 6:49 PM, John Casey wrote:
>
>> The real problem here is that as long as there are tags out there
>> that don't
>> specify plugin versions, we have no mechanism for deprecating or
>> breaking
>> api compat, regardless of the version (2.0 -> 2.1 -> 2.2 -> 99.0).
>>
>> -j
>>
>> On 3/28/07, John Casey <[EMAIL PROTECTED]> wrote:
>>>
>>> MASSEMBLY-192 is fixed in trunk, and I'm just about to apply it
>>> to the
>>> tag...then we could roll another candidate, though I do want to
>>> resolve
>>> Max's issue above as well.
>>>
>>> Max: I'm tempted to say that we should look for decimal versions
>>> of common
>>> octal expressions, then prefix the rest with '0' to ensure they're
>>> interpreted as octal (unless they have 0x in front, that is).
>>>
>>> Is that a decent solution?
>>>
>>> -john
>>>
>>> On 3/28/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>>> >
>>> > -1
>>> >
>>> > But it got really close :)
>>> >
>>> > Unfortunately, I found a regression, though it looks a simple
>>> one to
>>> > fix: http://jira.codehaus.org/browse/MASSEMBLY-192
>>> >
>>> > I'm continuing my testing past this to see if there are any other
>>> > issues, though it looks fine.
>>> >
>>> > - Brett
>>> >
>>> > On 29/03/2007, at 2:59 AM, John Casey wrote:
>>> >
>>> > > Hi everyone,
>>> > >
>>> > > I wanted to call a vote to release a beta version of the new
>>> assembly
>>> > > plugin. There are still some outstanding issues (though not
>>> as many
>>> > > as jira
>>> > > would have you believe; they just need tests), but I think
>>> we're at
>>> > > around
>>> > > 95-99% backward compatibility and the new features seem to be
>>> > > working well.
>>> > > It's been just sitting in SVN for quite awhile now, and many
>>> people
>>> > > are
>>> > > using it directly from there. I'd like to provide better support
>>> > > for those
>>> > > people, and start getting more feedback on exactly what's still
>>> > > broken.
>>> > >
>>> > > The change list is pretty large, but is mainly concerned with
>>> > > refactoring
>>> > > the plugin away from the old monolithic approach to one that
>>> uses
>>> > > phases to
>>> > > handle the different descriptor sections, along with common task
>>> > > classes to
>>> > > handle behavior shared between phases.
>>> > >
>>> > > Road Map:
>>> > >
>>> > > http://jira.codehaus.org/secure/ReleaseNote.jspa?
>>> > > projectId=11126&styleName=Html&version=12617
>>> > >
>>> > >
>>> > > Tag:
>>> > >
>>> > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-
>>> assembly-
>>> > > plugin-2.2-beta-1
>>> > >
>>> > > Staging repository:
>>> > >
>>> > > http://people.apache.org/~jdcasey/stage/repo<http://
>>> people.apache.org/%7Ejdcasey/stage/repo>
>>> > >
>>> > > Also, since this is just a beta, and there are some folks out
>>> there
>>> > > waiting
>>> > > on this release to release some of their own components, I'd
>>> like
>>> > > to make
>>> > > this a shorter vote; say, of around 24-36 hrs max. Regardless of
>>> > > whether we
>>> > > agree to do this in short order, I would like to get this
>>> release
>>> > > out on
>>> > > this vote, so don't let the timing affect your +1...if people
>>> > > complain, I'll
>>> > > just let it sit for the standard 72h.
>>> > >
>>> > > So, let's try for 24hrs. Please vote +1/+0/-1.
>>> > >
>>> > > Here's my +1.
>>> > >
>>> > > -john
>>> >
>>> >
>>> --------------------------------------------------------------------
>>> -
>>> > 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]
---------------------------------------------------------------------
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]
