Re: Maven and SVN [was: Re: [VOTE] Struts 1.2.4 Quality]

[Martin Cooper <mf...@gmail.com>]

On Fri, 17 Sep 2004 06:13:39 -0700 (PDT), David Graham
<gr...@yahoo.com> wrote:
> I don't think we have the volunteer hours to support starting from scratch
> and do you really want to rewrite ActionServlet, Action, etc.?  IMO, we
> have a lot of tested, used, stable code that we should continue to use.
> 
> You're right that we have some crufty old stuff that needs to be removed
> (all jsp tags not in the html lib for example) but it's easier to delete
> these items than starting from scratch.  Let's use Subversion's abilities
> to their fullest and just move things around as needed.
> 
> IMO, the current Ant build is hopelessly complex and a major obstacle to
> cutting releases.  Not that Ant itself is bad but the simplicity of
> running 'maven clean dist' on every Commons project to get all build
> artifacts is a dream compared to Struts' build.

I've seen several people comment on the complexity of the Ant build,
and frankly I don't get it. And I _really_ don't get that it is a
"major obstacle to cutting releases".

Yes, the Ant build requires that you know where you put the packages
that Struts depends on, but surely that's not so hard. Most people
know where they've put stuff after they've downloaded it. ;-) Once
you've done that, there is little more to cutting a release than 'ant
release' (and testing, of course ;).

I can't say for sure how the now-withdrawn 1.2.2 release was built,
but I can say with absolute certainty that it was not done using 'ant
release'. That target is rock solid, and has never failed me. So an
absolute minimum requirement for a move to Maven, in my book, is that
there is a way to construct a release, with the same structure as we
do today, as easily as there is with the Ant build.

When I first started using Maven, I thought it was the bees knees.
After I'd spent more time with it, I continued to believe that it was
a great advance - when things worked as expected. The way it will go
off and download dependencies or deploy the web site is great.

The problem I have with Maven is when things go wrong (which seems to
be all too often for me). Unlike with Ant, with which all is plain for
all to see, when something goes wrong with Maven, it seems to be a
total mystery as to what happened. I'm frequently told "Oh, you need a
later version of the foo plugin". Managing the tool's dependencies
becomes far worse than managing the dependencies of the project I'm
trying to build or release.

--
Martin Cooper


> 
> David
> 
> 
> 
> 
> --- James Mitchell <jm...@apache.org> wrote:
> 
> > On the topic of Maven and SVN...
> >
> > SVN:
> > We have discussed moving our current repository over to SVN and I know
> > there
> > are fancy scripts to do the conversion and all.  We also have been
> > discussing what 1.2.x, 1.3.x, and maybe 1.4.x will be adding vs. what
> > 2.0
> > will bring.
> >
> > Would it make sense just to 'start 2.0 from scratch'?  What I mean is,
> > we
> > can have SVN setup for 2.0 development without the confusion and mess of
> > the
> > existing repository.  I know SVN makes moving files/directories easy,
> > but
> > given the minimum specs we intend to move to, there is just too many
> > hacks
> > and old code in the existing source for supporting the old specs.
> > Starting
> > with a clean slate just seems to make the most sense to me.  Do you
> > agree?
> >
> >
> > Maven:
> > I have spent many hours over the last few weeks over in the commons
> > sandbox
> > 'playing around' with Maven (pun intended).  I moved the Hibernate
> > resource
> > implementation (and tests) over to sf.net.  Both distributions are 100%
> > mavenized.
> >
> > I may have been critical of Maven in the past, but I have earned a new
> > appreciation for this tool.  It really is far superior to just using
> > Ant.  I
> > believe no matter what path we take, with regards to SVN, that we should
> > move our primary build system to Maven.  We will lose nothing from what
> > the
> > current Ant script does, and yes, I am volunteering to help with this.
> >
> > So, that said, I am +1 for setting up a clean slate (2.0) on SVN and
> > making
> > it a 100% Mavenized build (multiproject).
> >
> >
> > Your thoughts?
> >
> >
> > --
> > James Mitchell
> > Software Engineer / Open Source Evangelist
> > EdgeTech, Inc.
> > 678.910.8017
> > AIM: jmitchtx
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Ted Husted" <hu...@apache.org>
> > To: "Struts Developers List" <de...@struts.apache.org>
> > Sent: Thursday, September 16, 2004 6:06 PM
> > Subject: Re: [VOTE] Struts 1.2.4 Quality
> >
> >
> > I'm not using Struts in production myself right now, so I'm going to
> > abstain
> > from voting in favor of them that do. :)
> >
> > I do still plan to help support the release once it is out.
> >
> > As to the voting in general ...
> >
> > On Thu, 16 Sep 2004 08:09:18 -0500, Joe Germuska wrote:
> > > I wouldn't veto GA, but I'm not ready to say that I think this
> > > release is GA either.
> >
> > A release is a majority vote. It can't be blocked by a veto. If there
> > are 3
> > +1s and more (binding) +1s than -1s, the vote passes. (So, as of now,
> > the
> > vote passes. By convention, we wait 72 hours before taking action on a
> > vote,
> > so that people have a chance to weigh in.)
> >
> > Any PMC Member can unilaterally veto changes to the codebase and
> > documentation on technical grounds (consensus vote), but most everything
> > else is a (political) majority vote. No one person can block a release.
> >
> > On Thu, 16 Sep 2004 08:09:18 -0500, Joe Germuska wrote:
> > > I vote "beta", because I haven't had (and won't have) time to test
> > > it, and I see no reason to rush to call it GA.
> >
> > :) Then you probably shouldn't vote it beta, either. :)
> >
> >
> > > I thought the whole
> > > point of the new releasing scheme was to allow us to not have to
> > > cut a new release if beta testing truly demonstrated release
> > > quality.
> >
> > As I understand it, the point of the new releasing scheme is to
> >
> > * avoid re-tagging and re-rolling the final beta in a series, if it is
> > otherwise ready to go.
> >
> > * reduce the need to "freeze" the repository for any longer than
> > absolutely
> > necessary.
> >
> > Aside from all that, a *huge* problem for Struts is that we keep making
> > GA
> > releases "triggers" for other events.
> >
> > * We decided not to transfer the repository to SVN until after we had
> > put a
> > 1.2.x GA release to bed.
> >
> > * Until we have a Struts 1.2.x GA, we're also holding the Struts Chain
> > in
> > abeyance, along with other proposed changes.
> >
> > * Until we have a Struts under SVN, everyone is reluctant to move
> > forward
> > with reorganizing the project, so we don't have to release *everything*
> > at
> > once. (Ironic, this one, since the reorganization would simplify the
> > releases that are preventing us from reorganizing.)
> >
> > * Pending the reorganization, we have held off introducing new sub
> > projects,
> > like Struts Scripting.
> >
> > So, you see, a 1.2.x GA is the first in a long line of dominoes -- bam,
> > bam,
> > bam, bam, bam.
> >
> > Of course, the biggest reason of all to bring out a GA release is that:
> >
> > *** until we can stamp 1.2.x GA, over a year's worth Struts development
> > is
> > unavailable to thousands of teams that use Struts, but can't use
> > anything
> > but a GA. ***
> >
> > Sad, but true.
> >
> > We shouldn't stamp it GA unless it is GA. But, yes, it *is* urgent that
> > we
> > determine whether 1.2.4 is GA or not, so we can fix it and and roll it
> > again, or let it go and move on.
> >
> > -Ted.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Maven and SVN [was: Re: [VOTE] Struts 1.2.4 Quality]

[James Mitchell <jm...@apache.org>]

> I can't say for sure how the now-withdrawn 1.2.2 release was built,
> but I can say with absolute certainty that it was not done using 'ant
> release'.

You are correct sir.  I attempted this manually.  I know I have run the
release target in the past, guess I just had a brain fart that day.  Anyway,
that is not important now.

While I would like to see more use of Maven, I don't agree that the Ant
build is a "major obstacle to cutting releases".  I do think it is pretty
complex.  I understand and use Ant almost to it's fullest extent on this and
other projects.  I guess I haven't used Maven enough to run into the
problems Martin states.  That would be a show stopper for me also.


--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

----- Original Message -----
From: "Martin Cooper" <mf...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Saturday, September 18, 2004 2:17 AM
Subject: Re: Maven and SVN [was: Re: [VOTE] Struts 1.2.4 Quality]


> On Fri, 17 Sep 2004 06:13:39 -0700 (PDT), David Graham
> <gr...@yahoo.com> wrote:
> > I don't think we have the volunteer hours to support starting from
scratch
> > and do you really want to rewrite ActionServlet, Action, etc.?  IMO, we
> > have a lot of tested, used, stable code that we should continue to use.
> >
> > You're right that we have some crufty old stuff that needs to be removed
> > (all jsp tags not in the html lib for example) but it's easier to delete
> > these items than starting from scratch.  Let's use Subversion's
abilities
> > to their fullest and just move things around as needed.
> >
> > IMO, the current Ant build is hopelessly complex and a major obstacle to
> > cutting releases.  Not that Ant itself is bad but the simplicity of
> > running 'maven clean dist' on every Commons project to get all build
> > artifacts is a dream compared to Struts' build.
>
> I've seen several people comment on the complexity of the Ant build,
> and frankly I don't get it. And I _really_ don't get that it is a
> "major obstacle to cutting releases".
>
> Yes, the Ant build requires that you know where you put the packages
> that Struts depends on, but surely that's not so hard. Most people
> know where they've put stuff after they've downloaded it. ;-) Once
> you've done that, there is little more to cutting a release than 'ant
> release' (and testing, of course ;).
>
> I can't say for sure how the now-withdrawn 1.2.2 release was built,
> but I can say with absolute certainty that it was not done using 'ant
> release'. That target is rock solid, and has never failed me. So an
> absolute minimum requirement for a move to Maven, in my book, is that
> there is a way to construct a release, with the same structure as we
> do today, as easily as there is with the Ant build.
>
> When I first started using Maven, I thought it was the bees knees.
> After I'd spent more time with it, I continued to believe that it was
> a great advance - when things worked as expected. The way it will go
> off and download dependencies or deploy the web site is great.
>
> The problem I have with Maven is when things go wrong (which seems to
> be all too often for me). Unlike with Ant, with which all is plain for
> all to see, when something goes wrong with Maven, it seems to be a
> total mystery as to what happened. I'm frequently told "Oh, you need a
> later version of the foo plugin". Managing the tool's dependencies
> becomes far worse than managing the dependencies of the project I'm
> trying to build or release.
>
> --
> Martin Cooper
>
>
> >
> > David
> >
> >
> >
> >
> > --- James Mitchell <jm...@apache.org> wrote:
> >
> > > On the topic of Maven and SVN...
> > >
> > > SVN:
> > > We have discussed moving our current repository over to SVN and I know
> > > there
> > > are fancy scripts to do the conversion and all.  We also have been
> > > discussing what 1.2.x, 1.3.x, and maybe 1.4.x will be adding vs. what
> > > 2.0
> > > will bring.
> > >
> > > Would it make sense just to 'start 2.0 from scratch'?  What I mean is,
> > > we
> > > can have SVN setup for 2.0 development without the confusion and mess
of
> > > the
> > > existing repository.  I know SVN makes moving files/directories easy,
> > > but
> > > given the minimum specs we intend to move to, there is just too many
> > > hacks
> > > and old code in the existing source for supporting the old specs.
> > > Starting
> > > with a clean slate just seems to make the most sense to me.  Do you
> > > agree?
> > >
> > >
> > > Maven:
> > > I have spent many hours over the last few weeks over in the commons
> > > sandbox
> > > 'playing around' with Maven (pun intended).  I moved the Hibernate
> > > resource
> > > implementation (and tests) over to sf.net.  Both distributions are
100%
> > > mavenized.
> > >
> > > I may have been critical of Maven in the past, but I have earned a new
> > > appreciation for this tool.  It really is far superior to just using
> > > Ant.  I
> > > believe no matter what path we take, with regards to SVN, that we
should
> > > move our primary build system to Maven.  We will lose nothing from
what
> > > the
> > > current Ant script does, and yes, I am volunteering to help with this.
> > >
> > > So, that said, I am +1 for setting up a clean slate (2.0) on SVN and
> > > making
> > > it a 100% Mavenized build (multiproject).
> > >
> > >
> > > Your thoughts?
> > >
> > >
> > > --
> > > James Mitchell
> > > Software Engineer / Open Source Evangelist
> > > EdgeTech, Inc.
> > > 678.910.8017
> > > AIM: jmitchtx
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Ted Husted" <hu...@apache.org>
> > > To: "Struts Developers List" <de...@struts.apache.org>
> > > Sent: Thursday, September 16, 2004 6:06 PM
> > > Subject: Re: [VOTE] Struts 1.2.4 Quality
> > >
> > >
> > > I'm not using Struts in production myself right now, so I'm going to
> > > abstain
> > > from voting in favor of them that do. :)
> > >
> > > I do still plan to help support the release once it is out.
> > >
> > > As to the voting in general ...
> > >
> > > On Thu, 16 Sep 2004 08:09:18 -0500, Joe Germuska wrote:
> > > > I wouldn't veto GA, but I'm not ready to say that I think this
> > > > release is GA either.
> > >
> > > A release is a majority vote. It can't be blocked by a veto. If there
> > > are 3
> > > +1s and more (binding) +1s than -1s, the vote passes. (So, as of now,
> > > the
> > > vote passes. By convention, we wait 72 hours before taking action on a
> > > vote,
> > > so that people have a chance to weigh in.)
> > >
> > > Any PMC Member can unilaterally veto changes to the codebase and
> > > documentation on technical grounds (consensus vote), but most
everything
> > > else is a (political) majority vote. No one person can block a
release.
> > >
> > > On Thu, 16 Sep 2004 08:09:18 -0500, Joe Germuska wrote:
> > > > I vote "beta", because I haven't had (and won't have) time to test
> > > > it, and I see no reason to rush to call it GA.
> > >
> > > :) Then you probably shouldn't vote it beta, either. :)
> > >
> > >
> > > > I thought the whole
> > > > point of the new releasing scheme was to allow us to not have to
> > > > cut a new release if beta testing truly demonstrated release
> > > > quality.
> > >
> > > As I understand it, the point of the new releasing scheme is to
> > >
> > > * avoid re-tagging and re-rolling the final beta in a series, if it is
> > > otherwise ready to go.
> > >
> > > * reduce the need to "freeze" the repository for any longer than
> > > absolutely
> > > necessary.
> > >
> > > Aside from all that, a *huge* problem for Struts is that we keep
making
> > > GA
> > > releases "triggers" for other events.
> > >
> > > * We decided not to transfer the repository to SVN until after we had
> > > put a
> > > 1.2.x GA release to bed.
> > >
> > > * Until we have a Struts 1.2.x GA, we're also holding the Struts Chain
> > > in
> > > abeyance, along with other proposed changes.
> > >
> > > * Until we have a Struts under SVN, everyone is reluctant to move
> > > forward
> > > with reorganizing the project, so we don't have to release
*everything*
> > > at
> > > once. (Ironic, this one, since the reorganization would simplify the
> > > releases that are preventing us from reorganizing.)
> > >
> > > * Pending the reorganization, we have held off introducing new sub
> > > projects,
> > > like Struts Scripting.
> > >
> > > So, you see, a 1.2.x GA is the first in a long line of dominoes --
bam,
> > > bam,
> > > bam, bam, bam.
> > >
> > > Of course, the biggest reason of all to bring out a GA release is
that:
> > >
> > > *** until we can stamp 1.2.x GA, over a year's worth Struts
development
> > > is
> > > unavailable to thousands of teams that use Struts, but can't use
> > > anything
> > > but a GA. ***
> > >
> > > Sad, but true.
> > >
> > > We shouldn't stamp it GA unless it is GA. But, yes, it *is* urgent
that
> > > we
> > > determine whether 1.2.4 is GA or not, so we can fix it and and roll it
> > > again, or let it go and move on.
> > >
> > > -Ted.
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org