You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2009/11/01 21:59:36 UTC
What's blocking releasing maven-compiler-plugin?
Now that we have maven-toolchains-plugin released, what is blocking
rolling a release of maven-compiler-plugin?
Toolchains support has been integrated since r649442. All the
integration tests (3 of them) are passing. I am not seeing any issues
in JIRA which are regressions (i.e. releasing now would probably not
make things worse)
There are currently 3 critical issues in JIRA:
MCOMPILER-98 is an issue for plexus-compiler
MCOMPILER-64 is just a higher memory requirement for large compiles with jdk6u4+
MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
If all that is somebody to play release manager I'll go running again.
If getting a release requires applying patches or fixing issues I do
not have the cycles at the moment
-Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What's blocking releasing maven-compiler-plugin?
Posted by Oleg Gusakov <ol...@gmail.com>.
Jason van Zyl wrote:
>
> Yes, about 5 people will do that. No one tries anything until we
> release it the vast majority of the time, unfortunately. We just have
> to be proactive about it. If we tried new plugins on the grid we'll
> likely find most of the problems.
>
> Thanks,
>
> Jason
>
An external look at the problem:
As a manager of B$R team I can attest to this: we'll *never* pick up
anything but a release. And - given our own schedules - any SW
team has a limited capacity to try out new things. Release Candidates
will be tested if they address particular issues. Releases will be
accepted - presuming they work on the first try. If they break - we
revert back to the last known working release and wait for the new one.
On my own I an trying snapshots - but it's only on weekends, if snapshot
does not work on Saturday, I can try to diagnose/fix it. If I cannot
find a solution by Sunday night, I usually abandon it :(
I think the above is more or less what happens in the "real world"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What's blocking releasing maven-compiler-plugin?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-11-01, at 4:36 PM, Dan Tran wrote:
> additionally, you can solicit the maven user list to turn on their
> build to pick up the maven-compile-plugin and maven-surefire-plugin
> snapshots to get feedback early. Then stage them.
>
> I will be happy to do that.
>
Yes, about 5 people will do that. No one tries anything until we
release it the vast majority of the time, unfortunately. We just have
to be proactive about it. If we tried new plugins on the grid we'll
likely find most of the problems.
> -Dan
>
> Btw, I have been using an internal cut of post surefire 2.4.3 for
> quite sometime now.
>
> On Sun, Nov 1, 2009 at 3:24 PM, Jason van Zyl <ja...@sonatype.com>
> wrote:
>> I think it's akin to the surefire plugin. Where it's been so long
>> that if we
>> release this and people get the automatic updates and something is
>> wrong
>> it's not so fun.
>>
>> Maybe you and Benjamin can sort out a way to stage the plugin and
>> run all
>> the projects on the grid to see if it's all good. A similar
>> strategy could
>> be employed for the surefire plugin. The best we can do is run as
>> many
>> projects as we can with these new plugins to make sure they work in
>> the wild
>> as we've seen in the past that sometimes the releases are not so
>> stellar.
>>
>> I'm sure we could find a clean place to inject an override for the
>> default
>> version of the compiler plugin in 3.x and then use that version of
>> Maven to
>> build as many on the grid as we can. Can't think of a better way to
>> test a
>> core plugin to make sure we don't hose anyone.
>>
>> On 2009-11-01, at 12:59 PM, Stephen Connolly wrote:
>>
>>> Now that we have maven-toolchains-plugin released, what is blocking
>>> rolling a release of maven-compiler-plugin?
>>>
>>> Toolchains support has been integrated since r649442. All the
>>> integration tests (3 of them) are passing. I am not seeing any
>>> issues
>>> in JIRA which are regressions (i.e. releasing now would probably not
>>> make things worse)
>>>
>>> There are currently 3 critical issues in JIRA:
>>>
>>> MCOMPILER-98 is an issue for plexus-compiler
>>> MCOMPILER-64 is just a higher memory requirement for large
>>> compiles with
>>> jdk6u4+
>>> MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
>>>
>>> If all that is somebody to play release manager I'll go running
>>> again.
>>> If getting a release requires applying patches or fixing issues I do
>>> not have the cycles at the moment
>>>
>>> -Stephen
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> 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
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What's blocking releasing maven-compiler-plugin?
Posted by Dan Tran <da...@gmail.com>.
additionally, you can solicit the maven user list to turn on their
build to pick up the maven-compile-plugin and maven-surefire-plugin
snapshots to get feedback early. Then stage them.
I will be happy to do that.
-Dan
Btw, I have been using an internal cut of post surefire 2.4.3 for
quite sometime now.
On Sun, Nov 1, 2009 at 3:24 PM, Jason van Zyl <ja...@sonatype.com> wrote:
> I think it's akin to the surefire plugin. Where it's been so long that if we
> release this and people get the automatic updates and something is wrong
> it's not so fun.
>
> Maybe you and Benjamin can sort out a way to stage the plugin and run all
> the projects on the grid to see if it's all good. A similar strategy could
> be employed for the surefire plugin. The best we can do is run as many
> projects as we can with these new plugins to make sure they work in the wild
> as we've seen in the past that sometimes the releases are not so stellar.
>
> I'm sure we could find a clean place to inject an override for the default
> version of the compiler plugin in 3.x and then use that version of Maven to
> build as many on the grid as we can. Can't think of a better way to test a
> core plugin to make sure we don't hose anyone.
>
> On 2009-11-01, at 12:59 PM, Stephen Connolly wrote:
>
>> Now that we have maven-toolchains-plugin released, what is blocking
>> rolling a release of maven-compiler-plugin?
>>
>> Toolchains support has been integrated since r649442. All the
>> integration tests (3 of them) are passing. I am not seeing any issues
>> in JIRA which are regressions (i.e. releasing now would probably not
>> make things worse)
>>
>> There are currently 3 critical issues in JIRA:
>>
>> MCOMPILER-98 is an issue for plexus-compiler
>> MCOMPILER-64 is just a higher memory requirement for large compiles with
>> jdk6u4+
>> MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
>>
>> If all that is somebody to play release manager I'll go running again.
>> If getting a release requires applying patches or fixing issues I do
>> not have the cycles at the moment
>>
>> -Stephen
>>
>> ---------------------------------------------------------------------
>> 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
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> 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: What's blocking releasing maven-compiler-plugin?
Posted by Benjamin Bentmann <be...@udo.edu>.
Stephen Connolly wrote:
> https://svn.apache.org/repos/asf/maven/sandbox/trunk/maven/maven-plugin-enforcer
>
> For M3, drop it in the lib folder and just add
> -Dforce.plugins=gId:aId:ver,gId:aId,ver,etc
OK, with some guidance from John I got Maven 3.0-SNAPSHOT (r832795)
including the maven-plugin-enforcer installed on the grid. Configuring a
job to use this Maven installation and adding the property
-Dforce.plugins=maven-compiler-plugin:2.1-SNAPSHOT should get us going
with the new plugin version.
Next question is probably some test plan. Do/can we clone some existing
jobs or do we temporarily switch existing jobs to use the test distro?
The latter is more resource-friendly. As for the job selection, I guess
as a minimum all our own stuff should be subjected to the test.
Comments?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What's blocking releasing maven-compiler-plugin?
Posted by Stephen Connolly <st...@gmail.com>.
OK this should do the job:
https://svn.apache.org/repos/asf/maven/sandbox/trunk/maven/maven-plugin-enforcer
For M3, drop it in the lib folder and just add
-Dforce.plugins=gId:aId:ver,gId:aId,ver,etc
groupId defaults to org.apache.maven.plugins if omitted
-Stephen
2009/11/3 Stephen Connolly <st...@gmail.com>:
> On 2009-11-03, at 17:50-something, Benjamin Bentmann wrote:
>>
>>> 2009/11/2 Jason van Zyl <ja...@sonatype.com>
>>>
>>>>
>>>>>> I'm sure we could find a clean place to inject an override for the
>>>>>> default
>>>>>> version of the compiler plugin in 3.x and then use that version of
>>>>>> Maven
>>>>>> to
>>>>>> build as many on the grid as we can. Can't think of a better way to
>>>>>> test
>>>>>> a
>>>>>> core plugin to make sure we don't hose anyone.
>>>>>>
>>
>> How about this: We implement some lifecycle participant, let's call it the
>> PluginVersionEnforcer, that would listen for afterProjectsRead() and iterates
>> over all projects in the session in order to mutate plugin versions in their
>> models.
>>
>> This lifecycle participant could be reused for all kinds of plugins if it gets
>> configured via execution properties, that it can read from the session, e.g.
>>
>> -Dorg.apache.maven.plugins:maven-compiler-plugin=2.1-SNAPSHOT
>>
>> which could be added to the configuration of grid builds.
>>
>> This participant would be some little JAR that we could drop into a regular
>> Maven 3.x distro on the grid.
>>
>>
>> Benjamin
>
> +1
>
> -Stephen
>
> P.S. hopefully your SMTP server gets working soon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What's blocking releasing maven-compiler-plugin?
Posted by Stephen Connolly <st...@gmail.com>.
On 2009-11-03, at 17:50-something, Benjamin Bentmann wrote:
>
>> 2009/11/2 Jason van Zyl <ja...@sonatype.com>
>>
>>>
>>>>> I'm sure we could find a clean place to inject an override for the
>>>>> default
>>>>> version of the compiler plugin in 3.x and then use that version of
>>>>> Maven
>>>>> to
>>>>> build as many on the grid as we can. Can't think of a better way to
>>>>> test
>>>>> a
>>>>> core plugin to make sure we don't hose anyone.
>>>>>
>
> How about this: We implement some lifecycle participant, let's call it the
> PluginVersionEnforcer, that would listen for afterProjectsRead() and iterates
> over all projects in the session in order to mutate plugin versions in their
> models.
>
> This lifecycle participant could be reused for all kinds of plugins if it gets
> configured via execution properties, that it can read from the session, e.g.
>
> -Dorg.apache.maven.plugins:maven-compiler-plugin=2.1-SNAPSHOT
>
> which could be added to the configuration of grid builds.
>
> This participant would be some little JAR that we could drop into a regular
> Maven 3.x distro on the grid.
>
>
> Benjamin
+1
-Stephen
P.S. hopefully your SMTP server gets working soon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What's blocking releasing maven-compiler-plugin?
Posted by Jason van Zyl <ja...@sonatype.com>.
There you go, we agree. Grid away!
On 2009-11-02, at 8:28 AM, Stephen Connolly wrote:
> 2009/11/2 Jason van Zyl <ja...@sonatype.com>
>
>>
>> On 2009-11-01, at 11:49 PM, Stephen Connolly wrote:
>>
>> 2009/11/1 Jason van Zyl <ja...@sonatype.com>:
>>>
>>>> I think it's akin to the surefire plugin. Where it's been so long
>>>> that if
>>>> we
>>>> release this and people get the automatic updates and something
>>>> is wrong
>>>> it's not so fun.
>>>>
>>>>
>>> Well how about we release a 2.1-alpha-1 and up its minimum maven
>>> version to 2.0.9
>>>
>>> That way anyone with earlier than 2.0.9 will not be able to use the
>>> alpha and anyone with 2.0.9+ will have a lock-down in place.
>>>
>>> Another way would be to release 2.1-alpha-1 as 2.0.3-alpha-1-for-2.1
>>> and re-release 2.0.2 as 2.0.4.
>>>
>>> If we stage them in one repository and then promote that
>>> repository in
>>> one go then anyone using 2.0.8- will just use m-c-p 2.0.4 which
>>> would
>>> be identical to 2.0.2, and we can get people with lock-downs to try
>>> the newer version.
>>>
>>>
>> You also just simply have to worry that it works. For people who do
>> actually upgrade. It needs to be tested thoroughly before it's
>> released,
>> this just needs to become a priority for core plugins. Just get
>> something
>> working on the grid and think we will have done the best we can do.
>>
>>
> Which was what I said below!!!
>
>
>>
>>
>>>> Maybe you and Benjamin can sort out a way to stage the plugin and
>>>> run all
>>>> the projects on the grid to see if it's all good. A similar
>>>> strategy
>>>> could
>>>> be employed for the surefire plugin. The best we can do is run as
>>>> many
>>>> projects as we can with these new plugins to make sure they work
>>>> in the
>>>> wild
>>>> as we've seen in the past that sometimes the releases are not so
>>>> stellar.
>>>>
>>>>
>>> Yes I agree that this could be a first step. Then we could try as
>>> step 2 a 2.1-alpha-1 with the minimum maven version upped to 2.0.9
>>> and
>>> finally we can roll the 2.1 release with maven 2.0.6 restored as the
>>> minimum version.
>>>
>>> Thoughts?
>>>
>>> Also, we will need to get surefire out the door. There are some
>>> good
>>> fixes in that, but let's get compiler out the door first and
>>> establish
>>> a process for that.
>>>
>>>
> ^^^ See above!!!
>
> ;-)
>
> Stephen
>
>>
>>>> I'm sure we could find a clean place to inject an override for the
>>>> default
>>>> version of the compiler plugin in 3.x and then use that version
>>>> of Maven
>>>> to
>>>> build as many on the grid as we can. Can't think of a better way
>>>> to test
>>>> a
>>>> core plugin to make sure we don't hose anyone.
>>>>
>>>> On 2009-11-01, at 12:59 PM, Stephen Connolly wrote:
>>>>
>>>> Now that we have maven-toolchains-plugin released, what is blocking
>>>>> rolling a release of maven-compiler-plugin?
>>>>>
>>>>> Toolchains support has been integrated since r649442. All the
>>>>> integration tests (3 of them) are passing. I am not seeing any
>>>>> issues
>>>>> in JIRA which are regressions (i.e. releasing now would probably
>>>>> not
>>>>> make things worse)
>>>>>
>>>>> There are currently 3 critical issues in JIRA:
>>>>>
>>>>> MCOMPILER-98 is an issue for plexus-compiler
>>>>> MCOMPILER-64 is just a higher memory requirement for large
>>>>> compiles with
>>>>> jdk6u4+
>>>>> MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
>>>>>
>>>>> If all that is somebody to play release manager I'll go running
>>>>> again.
>>>>> If getting a release requires applying patches or fixing issues
>>>>> I do
>>>>> not have the cycles at the moment
>>>>>
>>>>> -Stephen
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>> http://twitter.com/jvanzyl
>>>> ----------------------------------------------------------
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> 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
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What's blocking releasing maven-compiler-plugin?
Posted by Stephen Connolly <st...@gmail.com>.
2009/11/2 Jason van Zyl <ja...@sonatype.com>
>
> On 2009-11-01, at 11:49 PM, Stephen Connolly wrote:
>
> 2009/11/1 Jason van Zyl <ja...@sonatype.com>:
>>
>>> I think it's akin to the surefire plugin. Where it's been so long that if
>>> we
>>> release this and people get the automatic updates and something is wrong
>>> it's not so fun.
>>>
>>>
>> Well how about we release a 2.1-alpha-1 and up its minimum maven
>> version to 2.0.9
>>
>> That way anyone with earlier than 2.0.9 will not be able to use the
>> alpha and anyone with 2.0.9+ will have a lock-down in place.
>>
>> Another way would be to release 2.1-alpha-1 as 2.0.3-alpha-1-for-2.1
>> and re-release 2.0.2 as 2.0.4.
>>
>> If we stage them in one repository and then promote that repository in
>> one go then anyone using 2.0.8- will just use m-c-p 2.0.4 which would
>> be identical to 2.0.2, and we can get people with lock-downs to try
>> the newer version.
>>
>>
> You also just simply have to worry that it works. For people who do
> actually upgrade. It needs to be tested thoroughly before it's released,
> this just needs to become a priority for core plugins. Just get something
> working on the grid and think we will have done the best we can do.
>
>
Which was what I said below!!!
>
>
>>> Maybe you and Benjamin can sort out a way to stage the plugin and run all
>>> the projects on the grid to see if it's all good. A similar strategy
>>> could
>>> be employed for the surefire plugin. The best we can do is run as many
>>> projects as we can with these new plugins to make sure they work in the
>>> wild
>>> as we've seen in the past that sometimes the releases are not so stellar.
>>>
>>>
>> Yes I agree that this could be a first step. Then we could try as
>> step 2 a 2.1-alpha-1 with the minimum maven version upped to 2.0.9 and
>> finally we can roll the 2.1 release with maven 2.0.6 restored as the
>> minimum version.
>>
>> Thoughts?
>>
>> Also, we will need to get surefire out the door. There are some good
>> fixes in that, but let's get compiler out the door first and establish
>> a process for that.
>>
>>
^^^ See above!!!
;-)
Stephen
>
>>> I'm sure we could find a clean place to inject an override for the
>>> default
>>> version of the compiler plugin in 3.x and then use that version of Maven
>>> to
>>> build as many on the grid as we can. Can't think of a better way to test
>>> a
>>> core plugin to make sure we don't hose anyone.
>>>
>>> On 2009-11-01, at 12:59 PM, Stephen Connolly wrote:
>>>
>>> Now that we have maven-toolchains-plugin released, what is blocking
>>>> rolling a release of maven-compiler-plugin?
>>>>
>>>> Toolchains support has been integrated since r649442. All the
>>>> integration tests (3 of them) are passing. I am not seeing any issues
>>>> in JIRA which are regressions (i.e. releasing now would probably not
>>>> make things worse)
>>>>
>>>> There are currently 3 critical issues in JIRA:
>>>>
>>>> MCOMPILER-98 is an issue for plexus-compiler
>>>> MCOMPILER-64 is just a higher memory requirement for large compiles with
>>>> jdk6u4+
>>>> MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
>>>>
>>>> If all that is somebody to play release manager I'll go running again.
>>>> If getting a release requires applying patches or fixing issues I do
>>>> not have the cycles at the moment
>>>>
>>>> -Stephen
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What's blocking releasing maven-compiler-plugin?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-11-01, at 11:49 PM, Stephen Connolly wrote:
> 2009/11/1 Jason van Zyl <ja...@sonatype.com>:
>> I think it's akin to the surefire plugin. Where it's been so long
>> that if we
>> release this and people get the automatic updates and something is
>> wrong
>> it's not so fun.
>>
>
> Well how about we release a 2.1-alpha-1 and up its minimum maven
> version to 2.0.9
>
> That way anyone with earlier than 2.0.9 will not be able to use the
> alpha and anyone with 2.0.9+ will have a lock-down in place.
>
> Another way would be to release 2.1-alpha-1 as 2.0.3-alpha-1-for-2.1
> and re-release 2.0.2 as 2.0.4.
>
> If we stage them in one repository and then promote that repository in
> one go then anyone using 2.0.8- will just use m-c-p 2.0.4 which would
> be identical to 2.0.2, and we can get people with lock-downs to try
> the newer version.
>
You also just simply have to worry that it works. For people who do
actually upgrade. It needs to be tested thoroughly before it's
released, this just needs to become a priority for core plugins. Just
get something working on the grid and think we will have done the best
we can do.
>>
>> Maybe you and Benjamin can sort out a way to stage the plugin and
>> run all
>> the projects on the grid to see if it's all good. A similar
>> strategy could
>> be employed for the surefire plugin. The best we can do is run as
>> many
>> projects as we can with these new plugins to make sure they work in
>> the wild
>> as we've seen in the past that sometimes the releases are not so
>> stellar.
>>
>
> Yes I agree that this could be a first step. Then we could try as
> step 2 a 2.1-alpha-1 with the minimum maven version upped to 2.0.9 and
> finally we can roll the 2.1 release with maven 2.0.6 restored as the
> minimum version.
>
> Thoughts?
>
> Also, we will need to get surefire out the door. There are some good
> fixes in that, but let's get compiler out the door first and establish
> a process for that.
>
>>
>> I'm sure we could find a clean place to inject an override for the
>> default
>> version of the compiler plugin in 3.x and then use that version of
>> Maven to
>> build as many on the grid as we can. Can't think of a better way to
>> test a
>> core plugin to make sure we don't hose anyone.
>>
>> On 2009-11-01, at 12:59 PM, Stephen Connolly wrote:
>>
>>> Now that we have maven-toolchains-plugin released, what is blocking
>>> rolling a release of maven-compiler-plugin?
>>>
>>> Toolchains support has been integrated since r649442. All the
>>> integration tests (3 of them) are passing. I am not seeing any
>>> issues
>>> in JIRA which are regressions (i.e. releasing now would probably not
>>> make things worse)
>>>
>>> There are currently 3 critical issues in JIRA:
>>>
>>> MCOMPILER-98 is an issue for plexus-compiler
>>> MCOMPILER-64 is just a higher memory requirement for large
>>> compiles with
>>> jdk6u4+
>>> MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
>>>
>>> If all that is somebody to play release manager I'll go running
>>> again.
>>> If getting a release requires applying patches or fixing issues I do
>>> not have the cycles at the moment
>>>
>>> -Stephen
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> 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
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re : What's blocking releasing maven-compiler-plugin?
Posted by Julien HENRY <he...@yahoo.fr>.
> De : Stephen Connolly <st...@gmail.com>
> À : Maven Developers List <de...@maven.apache.org>
> Envoyé le : Lun 2 Novembre 2009, 8 h 49 min 47 s
> Objet : Re: What's blocking releasing maven-compiler-plugin?
>
> 2009/11/1 Jason van Zyl :
> > I think it's akin to the surefire plugin. Where it's been so long that if we
> > release this and people get the automatic updates and something is wrong
> > it's not so fun.
> >
>
> Well how about we release a 2.1-alpha-1 and up its minimum maven
> version to 2.0.9
>
> That way anyone with earlier than 2.0.9 will not be able to use the
> alpha and anyone with 2.0.9+ will have a lock-down in place.
+1
>
> Another way would be to release 2.1-alpha-1 as 2.0.3-alpha-1-for-2.1
> and re-release 2.0.2 as 2.0.4.
>
> If we stage them in one repository and then promote that repository in
> one go then anyone using 2.0.8- will just use m-c-p 2.0.4 which would
> be identical to 2.0.2, and we can get people with lock-downs to try
> the newer version.
I don't like this solution as it will completly mess up dependency history.
(my 2 cents)
>
> >
> > Maybe you and Benjamin can sort out a way to stage the plugin and run all
> > the projects on the grid to see if it's all good. A similar strategy could
> > be employed for the surefire plugin. The best we can do is run as many
> > projects as we can with these new plugins to make sure they work in the wild
> > as we've seen in the past that sometimes the releases are not so stellar.
> >
>
> Yes I agree that this could be a first step. Then we could try as
> step 2 a 2.1-alpha-1 with the minimum maven version upped to 2.0.9 and
> finally we can roll the 2.1 release with maven 2.0.6 restored as the
> minimum version.
>
> Thoughts?
>
> Also, we will need to get surefire out the door. There are some good
> fixes in that, but let's get compiler out the door first and establish
> a process for that.
>
> >
> > I'm sure we could find a clean place to inject an override for the default
> > version of the compiler plugin in 3.x and then use that version of Maven to
> > build as many on the grid as we can. Can't think of a better way to test a
> > core plugin to make sure we don't hose anyone.
> >
> > On 2009-11-01, at 12:59 PM, Stephen Connolly wrote:
> >
> >> Now that we have maven-toolchains-plugin released, what is blocking
> >> rolling a release of maven-compiler-plugin?
> >>
> >> Toolchains support has been integrated since r649442. All the
> >> integration tests (3 of them) are passing. I am not seeing any issues
> >> in JIRA which are regressions (i.e. releasing now would probably not
> >> make things worse)
> >>
> >> There are currently 3 critical issues in JIRA:
> >>
> >> MCOMPILER-98 is an issue for plexus-compiler
> >> MCOMPILER-64 is just a higher memory requirement for large compiles with
> >> jdk6u4+
> >> MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
> >>
> >> If all that is somebody to play release manager I'll go running again.
> >> If getting a release requires applying patches or fixing issues I do
> >> not have the cycles at the moment
> >>
> >> -Stephen
> >>
> >> ---------------------------------------------------------------------
> >> 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
> > http://twitter.com/jvanzyl
> > ----------------------------------------------------------
> >
> >
> > ---------------------------------------------------------------------
> > 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: What's blocking releasing maven-compiler-plugin?
Posted by Stephen Connolly <st...@gmail.com>.
2009/11/1 Jason van Zyl <ja...@sonatype.com>:
> I think it's akin to the surefire plugin. Where it's been so long that if we
> release this and people get the automatic updates and something is wrong
> it's not so fun.
>
Well how about we release a 2.1-alpha-1 and up its minimum maven
version to 2.0.9
That way anyone with earlier than 2.0.9 will not be able to use the
alpha and anyone with 2.0.9+ will have a lock-down in place.
Another way would be to release 2.1-alpha-1 as 2.0.3-alpha-1-for-2.1
and re-release 2.0.2 as 2.0.4.
If we stage them in one repository and then promote that repository in
one go then anyone using 2.0.8- will just use m-c-p 2.0.4 which would
be identical to 2.0.2, and we can get people with lock-downs to try
the newer version.
>
> Maybe you and Benjamin can sort out a way to stage the plugin and run all
> the projects on the grid to see if it's all good. A similar strategy could
> be employed for the surefire plugin. The best we can do is run as many
> projects as we can with these new plugins to make sure they work in the wild
> as we've seen in the past that sometimes the releases are not so stellar.
>
Yes I agree that this could be a first step. Then we could try as
step 2 a 2.1-alpha-1 with the minimum maven version upped to 2.0.9 and
finally we can roll the 2.1 release with maven 2.0.6 restored as the
minimum version.
Thoughts?
Also, we will need to get surefire out the door. There are some good
fixes in that, but let's get compiler out the door first and establish
a process for that.
>
> I'm sure we could find a clean place to inject an override for the default
> version of the compiler plugin in 3.x and then use that version of Maven to
> build as many on the grid as we can. Can't think of a better way to test a
> core plugin to make sure we don't hose anyone.
>
> On 2009-11-01, at 12:59 PM, Stephen Connolly wrote:
>
>> Now that we have maven-toolchains-plugin released, what is blocking
>> rolling a release of maven-compiler-plugin?
>>
>> Toolchains support has been integrated since r649442. All the
>> integration tests (3 of them) are passing. I am not seeing any issues
>> in JIRA which are regressions (i.e. releasing now would probably not
>> make things worse)
>>
>> There are currently 3 critical issues in JIRA:
>>
>> MCOMPILER-98 is an issue for plexus-compiler
>> MCOMPILER-64 is just a higher memory requirement for large compiles with
>> jdk6u4+
>> MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
>>
>> If all that is somebody to play release manager I'll go running again.
>> If getting a release requires applying patches or fixing issues I do
>> not have the cycles at the moment
>>
>> -Stephen
>>
>> ---------------------------------------------------------------------
>> 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
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> 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: What's blocking releasing maven-compiler-plugin?
Posted by Jason van Zyl <ja...@sonatype.com>.
I think it's akin to the surefire plugin. Where it's been so long that
if we release this and people get the automatic updates and something
is wrong it's not so fun.
Maybe you and Benjamin can sort out a way to stage the plugin and run
all the projects on the grid to see if it's all good. A similar
strategy could be employed for the surefire plugin. The best we can do
is run as many projects as we can with these new plugins to make sure
they work in the wild as we've seen in the past that sometimes the
releases are not so stellar.
I'm sure we could find a clean place to inject an override for the
default version of the compiler plugin in 3.x and then use that
version of Maven to build as many on the grid as we can. Can't think
of a better way to test a core plugin to make sure we don't hose anyone.
On 2009-11-01, at 12:59 PM, Stephen Connolly wrote:
> Now that we have maven-toolchains-plugin released, what is blocking
> rolling a release of maven-compiler-plugin?
>
> Toolchains support has been integrated since r649442. All the
> integration tests (3 of them) are passing. I am not seeing any issues
> in JIRA which are regressions (i.e. releasing now would probably not
> make things worse)
>
> There are currently 3 critical issues in JIRA:
>
> MCOMPILER-98 is an issue for plexus-compiler
> MCOMPILER-64 is just a higher memory requirement for large compiles
> with jdk6u4+
> MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
>
> If all that is somebody to play release manager I'll go running again.
> If getting a release requires applying patches or fixing issues I do
> not have the cycles at the moment
>
> -Stephen
>
> ---------------------------------------------------------------------
> 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
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org