You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brian E. Fox" <br...@reply.infinity.nu> on 2008/04/09 18:51:09 UTC
Planning for 2.0.10
Now that 2.0.9 is essentially behind us, I think the focus for the next
release needs to continue on preventing new regressions and stomping out
the old ones. This should take precedence over new features and other
"nice to haves" as we still have a significant user base stuck on
various releases due to changes and regressions we introduced in the
past. There are 27 issues scheduled for .10 currently [1], most of these
issues are things that represent regressions introduced in earlier
releases and issues with the highest number of votes (usually they are
the same). While not set in concrete, we should try to maintain this
list and resist the urge to pile in tons of cruft. Only really important
issues or regressions should be brought forward to .10
I'd like to aim for starting the release process in 4-6 weeks. We should
be cognizant of the no regression plan when fixing any issues so we
don't have to chase them down at the end. This means good unit tests and
core Its should be introduced for all changes. This is important to
build upon to help identify future regressions and more importantly
gives us a concrete set of tests to judge 2.1's compatibility. I've
found that in many cases the unit tests alone simply aren't good enough
to detect issues as we go forward...I think in most cases they just
aren't exhaustive enough, but also they don't cover all the interactions
and classpath weirdness.
As we discussed before, the doxia beta should be introduced to .10 asap
so we have time to work out any issues.
Thanks,
Brian
RE: Planning for 2.0.10
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
That could be a potentially massive undertaking but I agree it's worth
pursuing. The existing Its and infrastructure seems to be pretty stable
now so it's at least manageable.
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Wednesday, April 09, 2008 1:13 PM
To: Maven Developers List
Subject: Re: Planning for 2.0.10
Sounds good.
I think we should consider MNG-3160 - to get all the integration tests
that have been disabled for one reason or another working again.
- Brett
On 10/04/2008, at 2:51 AM, Brian E. Fox wrote:
> Now that 2.0.9 is essentially behind us, I think the focus for the
> next
> release needs to continue on preventing new regressions and stomping
> out
> the old ones. This should take precedence over new features and other
> "nice to haves" as we still have a significant user base stuck on
> various releases due to changes and regressions we introduced in the
> past. There are 27 issues scheduled for .10 currently [1], most of
> these
> issues are things that represent regressions introduced in earlier
> releases and issues with the highest number of votes (usually they are
> the same). While not set in concrete, we should try to maintain this
> list and resist the urge to pile in tons of cruft. Only really
> important
> issues or regressions should be brought forward to .10
>
>
>
> I'd like to aim for starting the release process in 4-6 weeks. We
> should
> be cognizant of the no regression plan when fixing any issues so we
> don't have to chase them down at the end. This means good unit tests
> and
> core Its should be introduced for all changes. This is important to
> build upon to help identify future regressions and more importantly
> gives us a concrete set of tests to judge 2.1's compatibility. I've
> found that in many cases the unit tests alone simply aren't good
> enough
> to detect issues as we go forward...I think in most cases they just
> aren't exhaustive enough, but also they don't cover all the
> interactions
> and classpath weirdness.
>
>
>
> As we discussed before, the doxia beta should be introduced to .10
> asap
> so we have time to work out any issues.
>
>
>
> Thanks,
>
> Brian
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
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: Planning for 2.0.10
Posted by Brett Porter <br...@apache.org>.
Sounds good.
I think we should consider MNG-3160 - to get all the integration tests
that have been disabled for one reason or another working again.
- Brett
On 10/04/2008, at 2:51 AM, Brian E. Fox wrote:
> Now that 2.0.9 is essentially behind us, I think the focus for the
> next
> release needs to continue on preventing new regressions and stomping
> out
> the old ones. This should take precedence over new features and other
> "nice to haves" as we still have a significant user base stuck on
> various releases due to changes and regressions we introduced in the
> past. There are 27 issues scheduled for .10 currently [1], most of
> these
> issues are things that represent regressions introduced in earlier
> releases and issues with the highest number of votes (usually they are
> the same). While not set in concrete, we should try to maintain this
> list and resist the urge to pile in tons of cruft. Only really
> important
> issues or regressions should be brought forward to .10
>
>
>
> I'd like to aim for starting the release process in 4-6 weeks. We
> should
> be cognizant of the no regression plan when fixing any issues so we
> don't have to chase them down at the end. This means good unit tests
> and
> core Its should be introduced for all changes. This is important to
> build upon to help identify future regressions and more importantly
> gives us a concrete set of tests to judge 2.1's compatibility. I've
> found that in many cases the unit tests alone simply aren't good
> enough
> to detect issues as we go forward...I think in most cases they just
> aren't exhaustive enough, but also they don't cover all the
> interactions
> and classpath weirdness.
>
>
>
> As we discussed before, the doxia beta should be introduced to .10
> asap
> so we have time to work out any issues.
>
>
>
> Thanks,
>
> Brian
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Planning for 2.0.10
Posted by Arnaud HERITIER <ah...@gmail.com>.
I'm also interested if we can try to fix this one :
http://jira.codehaus.org/browse/MECLIPSE-394
If we can validate it by reproducing it with another plugin we can
suppose that it i related to the core (I don't see how i can be a bug
in the plugin).
(I already had this bug but I didn't yet take the time to create a testcase)
arnaud
On Wed, Apr 9, 2008 at 10:13 PM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> >It essentially renders maven useless behind a corporate firewall
> because
> >proxying is applied globally in maven - and nonProxyHosts are not taken
>
> >into account.
>
> Someplace with a corporate firewall most likely needs a repo manager
> anyway, which should handle this without blinking.
>
>
> >Even by using a local mirror with proximity or archiva - there is still
>
> >a need for proxy-support to reach external resources like findbugs
> rules
> >etc - or the other way - to access local LAN resources - without going
> >through the corporate proxy.
>
> It's not a good idea to have your build dependent on urls. For one, urls
> have a funny way of changing over time. Second, it breaks offline use
> and possibly outside the network building (pseudo-offline). A better way
> to handle these rules is usually to stick them in a jar with assembly
> and then add them to the plugin's classpath (I know checkstyle and pmd
> can do this, I don't know about findbugs). The added benefit to this is
> you have now versioned your rules with your source. Ever tried to build
> an old codebase after the pmd rules have been tightened?
>
> All that being said, I put in MNG-3512 for 2.0.10 to use the updated
> wagon. We'll try to get the patch applied and wagon released soon so it
> doesn't hold up the .10 release. I still suggest not relying on urls
> strictly for portability reasons, but Maven should still attempt to do
> the right thing.
>
> --Brian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...........................................................
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Planning for 2.0.10
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>It essentially renders maven useless behind a corporate firewall
because
>proxying is applied globally in maven - and nonProxyHosts are not taken
>into account.
Someplace with a corporate firewall most likely needs a repo manager
anyway, which should handle this without blinking.
>Even by using a local mirror with proximity or archiva - there is still
>a need for proxy-support to reach external resources like findbugs
rules
>etc - or the other way - to access local LAN resources - without going
>through the corporate proxy.
It's not a good idea to have your build dependent on urls. For one, urls
have a funny way of changing over time. Second, it breaks offline use
and possibly outside the network building (pseudo-offline). A better way
to handle these rules is usually to stick them in a jar with assembly
and then add them to the plugin's classpath (I know checkstyle and pmd
can do this, I don't know about findbugs). The added benefit to this is
you have now versioned your rules with your source. Ever tried to build
an old codebase after the pmd rules have been tightened?
All that being said, I put in MNG-3512 for 2.0.10 to use the updated
wagon. We'll try to get the patch applied and wagon released soon so it
doesn't hold up the .10 release. I still suggest not relying on urls
strictly for portability reasons, but Maven should still attempt to do
the right thing.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Planning for 2.0.10
Posted by "David J. M. Karlsen" <da...@davidkarlsen.com>.
Brian E. Fox skrev:
> Now that 2.0.9 is essentially behind us, I think the focus for the next
> release needs to continue on preventing new regressions and stomping out
> the old ones. This should take precedence over new features and other
> "nice to haves" as we still have a significant user base stuck on
>
[snip]
All this is important (killing of regressions).
But I also want to bring focus to another really killer-issue which
seems to have been dormant for a long time - and which is a wagon
problem - and which probably is a real PITA for enterprise users - which
is probably a large userbase:
http://jira.codehaus.org/browse/WAGON-80
It has 19 votes and 20 watchers - and is a year old.
It essentially renders maven useless behind a corporate firewall because
proxying is applied globally in maven - and nonProxyHosts are not taken
into account.
Even by using a local mirror with proximity or archiva - there is still
a need for proxy-support to reach external resources like findbugs rules
etc - or the other way - to access local LAN resources - without going
through the corporate proxy.
WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org