On 16 October 2011 20:11, Phil Steitz <[email protected]> wrote: > On 10/16/11 12:02 PM, sebb wrote: >> On 16 October 2011 17:30, Phil Steitz <[email protected]> wrote: >>> >>> >>> >>> On Oct 16, 2011, at 8:19 AM, Christian Grobmeier <[email protected]> >>> wrote: >>> >>>> On Sun, Oct 16, 2011 at 3:15 PM, Adrian Cumiskey >>>> <[email protected]> wrote: >>>>> Personally I would favour maintaining Ant over Maven any day of the week, >>>>> although Maven IDE support is generally pretty good I find it so verbose >>>>> and unwieldy. This is probably not within scope of cutting a RC, but I'd >>>>> recommend buildr, its so lightweight, low maintenance and extensible, and >>>>> a nice way to wet your feet with ruby too. >>>>> >>>> Maven parent is used for all components so I think we need Maven here. >>>> >>> Traditionally, we have allowed components to choose their own build tools. >>> The maven parent is there to make it easier to build using maven. It's >>> really up to whoever is working on the component to decide what kinds of >>> builds they want to support and how they want to generate RCs. >> I don't think Maven can be abandoned however, without causing problems >> for building the site. > > I have been meaning to suggest that we consider experimenting with > the ASF CMS for site builds.
I was involved in converting the Apache site to CMS; this was quite tricky, and we found conversion problems for several months afterwards. Parts of it are convenient and easy to use, but parts are even less well documented than Maven... The layout of the menus at the bottom on the main page is something I hope Commons would not copy, but I've no idea how that part works. > Component site builds are still fairly > independent and I at least would prefer to keep it that way. They all inherit from the parent site.xml, which provides standard menus and footer, but otherwise the menu contents are locally defined. I think it makes sense to have some sort of consistency between commons component websites. >> >> If a component exclusively uses a build tool that is not well known, >> there is a danger that not many PMC members will be able to validate >> and vote for releases. > > Yeah, that's exactly how I feel about maven 3 (sorry, could not > resist that). > > Seriously, Ant is not exactly "new" and anything relatively easy to > learn and run without downloading half the internet would be no > harder than maven. Validating build artifacts should be > build-tool-independent. Yes. > Validating that the source builds and tests > succeed requires only that whatever build tool is used supports a > simple command line interface. Yes, but requires that at least some reviewers install the build tool in order to do so. I don't think we should release build scripts that have not been validated. > > Phil >> >> >>> Phil >>> >>>> But hey... I didn't know about buildr. I looked at it now and it is >>>> very nice! Thanks for sending this link. >>>> >>>> Cheers >>>> Christian >>>> >>>> >>>>> Cheers, Adrian. >>>>> >>>>> On Oct 16, 2011, at 1:46 AM, Christian Grobmeier <[email protected]> >>>>> wrote: >>>>> >>>>>> On Sun, Oct 16, 2011 at 12:54 AM, Simone Tripodi >>>>>> <[email protected]> wrote: >>>>>>> looks like last good build.xml commit was done by Niall in the far >>>>>>> 2008 - since [functor] joined the proper recently and I'd like to cut >>>>>>> a RC soon, I propose to drop ant support. >>>>>> +1 >>>>>> >>>>>>> What are plans for ant builds maintenance? Does it make sense maintain >>>>>>> ant builds for already released components, but omit it for new ones? >>>>>> Not sure why we still care on ant builds. Its just double maintenance. >>>>>> Another question is if we should support Maven 3 only (my preference) >>>>>> >>>>>> Cheers >>>>>> Christian >>>>>>> Many thanks in advance, all the best! >>>>>>> Simo >>>>>>> >>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>> http://simonetripodi.livejournal.com/ >>>>>>> http://twitter.com/simonetripodi >>>>>>> http://www.99soft.org/ >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> http://www.grobmeier.de >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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] >>>>> >>>>> >>>> >>>> >>>> -- >>>> http://www.grobmeier.de >>>> >>>> --------------------------------------------------------------------- >>>> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
