Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of flamefew@gmail.com designates
 64.233.162.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=IlNDS2oO6lEGDsQQ68af3Ni00GqC8I5oorUHXG888V0ZmuvlpqVYBrRaI1qEuVzO/yPnbtNy75eNj4nNmDICRQXLoVvwiTiIyel2Wfhbo1Lt3e9k33qLr984k5XmsDHjBZrX2QQDnP24tDM75VU0QCA8LN4grw+yTsflY0jgLy0=
Message-ID: <31cc37360603031706p331ce691jbea9ffd026a3529@mail.gmail.com>
Date: Fri, 3 Mar 2006 17:06:52 -0800
From: "Henri Yandell" <flamefew@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of
 "Maven2MigrationPlan" by MartinCooper
In-Reply-To: <8a81b4af0603031659g75c3413cke2cb782b46222f47@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <31cc37360603031504g733dc4d3k3e4c351fd6d65d82@mail.gmail.com>
	 <8a81b4af0603031659g75c3413cke2cb782b46222f47@mail.gmail.com>

On 3/3/06, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 3/3/06, Henri Yandell <flamefew@gmail.com> wrote:
> > That's a very good point. Do we:
> >
> > 1) Want to keep Commons on a unified build system?
> > 2) Want to keep Commons sites on a similar style?
> > 3) Want to only support one build system?
> >
> > My personal view is that our Maven-1 current build system for Commons
> > is overly complicated - it needs to be simpler.
>
> Are you talking about the code-build-test cycle, site generation,
> creating distributions,  or all three?  I have an open mind on this,
> but pretty much agree with Martin that things aren't really broken
> that badly.  I agree also that we need to keep supporting ant and
> would not like to see us go back to the sites all looking different.

I really mean site generation here. Dists are a pain, but not due to
our build system.

> >The Maven-2 proposed
> > one is definitely better,
>
> How, exactly?  The painful stuff around rolling distros and getting
> the right stuff into them will not go away as far as I can see, unless
> we relax requirements or do some sort of custom plugins, which we
> could also do in m1.  The signing and notices stuff we *can't* relax.
> Again, I am open to moving and will help if and when we decide we want
> to move, but want to make sure we don't think that moving to m2 will
> solve everything magically.

Guess this is a question for Brett. M2 sounds like it will be solving
this kind of thing, will we be getting that kind of thing in M1? PGP
signing, auto md5 etc.

> > and we need to make sure we don't get sloppy
> > and start using unreleased or complex things. Not that we can move to
> > Maven-2 as things aren't released.
> >
>
> Agree with you and Brett on this point.  Question is does it make
> sense to try to fix things in m1 in the mean time - e.g. fix the
> entity stuff in the menus that makes maven 1.1 choke and add the
> explicit xdoc dependency into all of the poms?

If we decide to stay on M1, we should do that.

> > Currently we support Ant and Maven-1; though poorly. We need a CI
> > system that runs maven ant on the chiefly Maven-1 ones, and warns when
> > the chiefly Ant ones change build.xml's without an m1 change.
>
> Don't follow this.  Not all changes to the POM will result in changes
> to build.xml nor vice-versa.  Also, running maven ant will change the
> file even if the POM has not changed. If you mean we need a better
> nightly build system, here again, it ain't broke from my perspective
> (other than maybe Craig starting to feel like we are the guests who
> never leave ;-)

2 build systems is 1 too many; they get out of sync. So we need to
keep them synced, which CI can do for us (or a CI like thing).

> >I can't
> > imagine getting away from Ant builds - so unless we go back to Ant
> > alone, we'll always have 2 systems.
> >
> > I'd like to get around the issue of keeping the sites similar by
> > making the sites hugely simpler - another place where we
> > over-complicate I think.
>
> How exactly?  You think we should eliminate the reports?  If kept up
> to date, these can be useful.  Maybe you mean the custom site.jsl and
> the entities-based menus.  Those are really the source of all of the
> site build problems.  But if you use maven 1.0.2 and xdoc 1.9.2,
> things work fine.

I think we should be folding the site into one site, with manuals per
subproject. Release info would be put in a release structure (src,
javadoc) and other reports would be hooked into the CI system.
Separating the user and developer consumer-requirements, hopefully
making our life easier.

Hen

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