commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan" by MartinCooper
Date Sat, 04 Mar 2006 01:06:52 GMT
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


Mime
View raw message