> 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" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > > To: "Struts Developers List" <[EMAIL PROTECTED]> > > > 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > > > > > --------------------------------------------------------------------- > > 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]