You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2006/03/04 00:04:05 UTC
Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan" by MartinCooper
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. The Maven-2 proposed
one is definitely better, 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.
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. 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.
Hen
On 3/3/06, Apache Wiki <wi...@apache.org> wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.
>
> The following page has been changed by MartinCooper:
> http://wiki.apache.org/jakarta-commons/Maven2MigrationPlan
>
> ------------------------------------------------------------------------------
> * el
> * email
> * feedparser
> - * fileupload
> + * fileupload - Happy with Maven 1. No interest in moving to Maven 2.
> * httpclient
> * io
> * jelly - m1 Jelly plugin needs moving to Jelly and then converting to an m2 plugin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan" by MartinCooper
Posted by Martin Cooper <ma...@apache.org>.
On 3/3/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 3/3/06, Martin Cooper <ma...@apache.org> wrote:
> > On 3/3/06, Henri Yandell <fl...@gmail.com> wrote:
> >
> > <snip/>
> >
> >
> > > 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.
> >
> >
> > If all that was in place, how many sites would the average Commons
> developer
> > be required to maintain? It sounds like 3 to me - the component site,
> the
> > shared site, and the CI site. IMO, that is 2 too many. Right now, we're
> only
> > at 1 too many.
> >
> > If anything, I would be in favour of moving in the opposite direction.
> > Everything about component X stays on the component X site, so the
> > developers of component X only need to worry about maintaining one site.
> If
> > someone wanted to add some automation to 'pull' some information from
> > component sites to the main Commons site, that would be fine, but don't
> make
> > the component developers have to go put it there. What makes the site
> > updates a pain today is that there is more than one to maintain.
>
> Right. So I'm suggesting:
>
> 1) Shared site. Containing links to the important info. Commons blurb.
>
> A larger version of: http://www.osjava.org/genjava/ (which needs
> improving to handle versions).
>
> 2) Component site. Though site is the wrong word. Ideally there
> shouldn't be a component site; there's no reason for one. What it is
> is a series of release items that are stored in versioned structure:
>
> i) javadoc
> ii) source xref if we think that's important enough
> iii) user manual
> iv) release notes (probably fold dependencies list into this).
>
> All the individual items that are linked to from 1) basically - and
> probably matching those included in the zip. The downside here is a
> lessening of component individuality - it's an enforced information
> architecture.
This doesn't make sense to me. If I'm looking at a particular user guide and
decide I want to look at the release notes, I have to go to the main Commons
site to do that? And if your answer is no, there's a nav link in the user
guide that will take me there, why do I not have a component site any more?
There's your need for a component site right there - one place I can go to
get all of the information on a specific component, without having to wade
through a list of all available components (again - I already had to do that
to get to the user guide).
I think doing (1) is fine, if that's what floats your boat, but that should
be generated from what's in the component's SVN and / or site, and the
component sites should be left alone.
--
Martin Cooper
3) CI site. Lots of developer reports - such as Maven loves to
> produce. Updated nightly, so the reports are actually useful.
>
> I don't know about whether that is more work or less. It is a change
> of mindset on releases; a release is more than just a zip/tar.gz/jar -
> there's a structure of documentation to go with it - but not a
> website.
>
> This all probably just comes down to:
>
> a) CI site. Something I should just go ahead and try and work on to
> see if people like it. http://builds.osjava.org/osjava/ is my
> prototype demo.
>
> b) Moving standard information from the individual Commons component
> index pages to the Commons index page so they become (quite sparse)
> user manuals in some cases, and having a structured main Commons site.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan" by MartinCooper
Posted by Henri Yandell <fl...@gmail.com>.
On 3/3/06, Martin Cooper <ma...@apache.org> wrote:
> On 3/3/06, Henri Yandell <fl...@gmail.com> wrote:
>
> <snip/>
>
>
> > 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.
>
>
> If all that was in place, how many sites would the average Commons developer
> be required to maintain? It sounds like 3 to me - the component site, the
> shared site, and the CI site. IMO, that is 2 too many. Right now, we're only
> at 1 too many.
>
> If anything, I would be in favour of moving in the opposite direction.
> Everything about component X stays on the component X site, so the
> developers of component X only need to worry about maintaining one site. If
> someone wanted to add some automation to 'pull' some information from
> component sites to the main Commons site, that would be fine, but don't make
> the component developers have to go put it there. What makes the site
> updates a pain today is that there is more than one to maintain.
Right. So I'm suggesting:
1) Shared site. Containing links to the important info. Commons blurb.
A larger version of: http://www.osjava.org/genjava/ (which needs
improving to handle versions).
2) Component site. Though site is the wrong word. Ideally there
shouldn't be a component site; there's no reason for one. What it is
is a series of release items that are stored in versioned structure:
i) javadoc
ii) source xref if we think that's important enough
iii) user manual
iv) release notes (probably fold dependencies list into this).
All the individual items that are linked to from 1) basically - and
probably matching those included in the zip. The downside here is a
lessening of component individuality - it's an enforced information
architecture.
3) CI site. Lots of developer reports - such as Maven loves to
produce. Updated nightly, so the reports are actually useful.
I don't know about whether that is more work or less. It is a change
of mindset on releases; a release is more than just a zip/tar.gz/jar -
there's a structure of documentation to go with it - but not a
website.
This all probably just comes down to:
a) CI site. Something I should just go ahead and try and work on to
see if people like it. http://builds.osjava.org/osjava/ is my
prototype demo.
b) Moving standard information from the individual Commons component
index pages to the Commons index page so they become (quite sparse)
user manuals in some cases, and having a structured main Commons site.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan" by MartinCooper
Posted by Martin Cooper <ma...@apache.org>.
On 3/3/06, Henri Yandell <fl...@gmail.com> wrote:
<snip/>
> 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.
If all that was in place, how many sites would the average Commons developer
be required to maintain? It sounds like 3 to me - the component site, the
shared site, and the CI site. IMO, that is 2 too many. Right now, we're only
at 1 too many.
If anything, I would be in favour of moving in the opposite direction.
Everything about component X stays on the component X site, so the
developers of component X only need to worry about maintaining one site. If
someone wanted to add some automation to 'pull' some information from
component sites to the main Commons site, that would be fine, but don't make
the component developers have to go put it there. What makes the site
updates a pain today is that there is more than one to maintain.
--
Martin Cooper
Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan" by MartinCooper
Posted by Henri Yandell <fl...@gmail.com>.
On 3/3/06, Phil Steitz <ph...@gmail.com> wrote:
> On 3/3/06, Henri Yandell <fl...@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
Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan" by MartinCooper
Posted by Phil Steitz <ph...@gmail.com>.
On 3/3/06, Henri Yandell <fl...@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.
>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.
> 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?
> 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 ;-)
>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.
Phil
>
> Hen
>
> On 3/3/06, Apache Wiki <wi...@apache.org> wrote:
> > Dear Wiki user,
> >
> > You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.
> >
> > The following page has been changed by MartinCooper:
> > http://wiki.apache.org/jakarta-commons/Maven2MigrationPlan
> >
> > ------------------------------------------------------------------------------
> > * el
> > * email
> > * feedparser
> > - * fileupload
> > + * fileupload - Happy with Maven 1. No interest in moving to Maven 2.
> > * httpclient
> > * io
> > * jelly - m1 Jelly plugin needs moving to Jelly and then converting to an m2 plugin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan" by MartinCooper
Posted by Henri Yandell <fl...@gmail.com>.
On 3/3/06, Brett Porter <br...@apache.org> wrote:
> It's dangerous that Hen has nothing better to do right now :) I think
> this is being pushed forward at a rate faster than I had expected
> because the prerequisites are not ready yet.
>
> Anyone wanting to spend time on this should first be looking at the site
> plugin and helping there. Those that are happy with things as they are
> should be able to safely ignore.
Will talk to you about that offline, see if I can help with site-plugin.
Yeah, looking for organizing things to do; along with helping out on
release managements etc. It's that or go insane on the Jakarta is a
mess issue.
> Martin Cooper wrote:
> > Where I'm coming from is that all I really care about is that I have
> > 'clean', 'jar', 'dist' and 'site' goals / targets that work. Right now, I
> > have that. In the little time I have to put in to FileUpload, I want to work
> > on the code, not on learning a new build system every other year. If it
> > ain't broke, which it ain't for some of us at least, don't fix it.
>
> The way I'd hoped to see a migration was that all of those should work
> first, and be applied to commons as a whole, so those building their own
> projects should just be installing m2 and running "mvn" instead of "maven".
Yep. The question of whether we want to move is important too, but
sounds like I should be testing which of the 4 important goals work
right now as each component goes to m2.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan"
by MartinCooper
Posted by Brett Porter <br...@apache.org>.
It's dangerous that Hen has nothing better to do right now :) I think
this is being pushed forward at a rate faster than I had expected
because the prerequisites are not ready yet.
Anyone wanting to spend time on this should first be looking at the site
plugin and helping there. Those that are happy with things as they are
should be able to safely ignore.
Martin Cooper wrote:
> Where I'm coming from is that all I really care about is that I have
> 'clean', 'jar', 'dist' and 'site' goals / targets that work. Right now, I
> have that. In the little time I have to put in to FileUpload, I want to work
> on the code, not on learning a new build system every other year. If it
> ain't broke, which it ain't for some of us at least, don't fix it.
The way I'd hoped to see a migration was that all of those should work
first, and be applied to commons as a whole, so those building their own
projects should just be installing m2 and running "mvn" instead of "maven".
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Happy with Maven1 Was: [Jakarta-commons Wiki] Update of "Maven2MigrationPlan" by MartinCooper
Posted by Martin Cooper <ma...@apache.org>.
On 3/3/06, Henri Yandell <fl...@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.
Where I'm coming from is that all I really care about is that I have
'clean', 'jar', 'dist' and 'site' goals / targets that work. Right now, I
have that. In the little time I have to put in to FileUpload, I want to work
on the code, not on learning a new build system every other year. If it
ain't broke, which it ain't for some of us at least, don't fix it.
--
Martin Cooper
The Maven-2 proposed
> one is definitely better, 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.
>
> 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. 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.
>
> Hen
>
> On 3/3/06, Apache Wiki <wi...@apache.org> wrote:
> > Dear Wiki user,
> >
> > You have subscribed to a wiki page or wiki category on "Jakarta-commons
> Wiki" for change notification.
> >
> > The following page has been changed by MartinCooper:
> > http://wiki.apache.org/jakarta-commons/Maven2MigrationPlan
> >
> >
> ------------------------------------------------------------------------------
> > * el
> > * email
> > * feedparser
> > - * fileupload
> > + * fileupload - Happy with Maven 1. No interest in moving to Maven 2.
> > * httpclient
> > * io
> > * jelly - m1 Jelly plugin needs moving to Jelly and then converting
> to an m2 plugin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>