Phil Steitz wrote:
Let's start experimenting with a maven2 build infrastructure going
after the various requirements posted here and on the wiki. Unless
someone has a better idea, I think it could be best to just branch
commons-build to create a home for the new stuff and associated
documentation.
A branch will work nicely for the build stuff, but I think the
documentation could be done on the wiki to start with. In that I assume
you mean documenting the process and not the individual components.
We can also branch some "volunteer" components to test
the new build infrastructure. I will do that for [math] and [id] if
there are no objections from the other committers on these components.
A branch for each "volunteer" components seems like a good idea. I have
started working on [logging] locally. I'll put up a page on the wiki
with my experiences so far. Then we can accumulate problems and
(hopefully) solutions there.
A script to do the svn copies into the new structure would be nice to
have if someone has one. I am also assuming that svn will have not
problem merging into the new structure when we have things working.
Are you referring to the preferred maven directory structure? My
experiences thus far indicates that we need to change the structure of
our components for maven to work correctly. I'll put a note on this on
the upcoming wiki page.
See comments interspersed below. I am still learning maven 2
(actually, maven 1 too ;-), so apologies if I have some concepts
wrong.
We learn as long as we live...
On 12/22/05, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Brett Porter wrote:
<snip/>
There are some gotchas.
- Some plugins may not be available. At this point, I am not aware of
anywhere that this is the case in Commons, but I will do a check over
this shortly and report back.
We should establish a list, based on basic build and site gen. See
use cases below.
- Some services are not yet available. Specifically I am thinking of
Gump and the automated repository sync. I am working with Leo on the
gump stuff, and I think it will be all ready by the time Gump 3 is done.
there is always the ability to generate a reasonable ant build script to
use here.
I would consider something like the maven 1 Ant plugin a requirement.
We need to ship working Ant builds, IMHO. Nightlies are a different
issue, but as long as we maintain the ability to generate working
build.xml with a dist goal that works, the current setup will keep
working.
- It's a change, and any change is disruptive. I had planned to get
everything working at least to the level it already does in M1 for some
sandbox components before even bringing it up, so this thread was rather
timely.
OK...lets go :-)
Now, some specific thoughts on what is needed.
Inheritence - I believe the common parent is a good way to go, and Maven
2 facilitates this by allowing it to be in the repository, avoiding a
bizarre checkout structure. This should avoid the need for externals
that has been under discussion.
Why wouldn't we just create a commons archetype to generate a full POM
for each component containing the right stuff?
I am currently working on site inheritence. The descriptor goes in the
repository, facilitating the same as above. I am adding breadcrumbs,
top/bottom navigation inheritence (to prevent the need for the entities
used previously), skins (css + images in a jar that can be shared among
projects), and documenting/facilitating best practices about separation
of different releases and separating developer information from user
information. If the site layout + CSS is still not good enough, a single
velocity template should be able to be added to the skin as well.
So something akin to commons-build becomes a (versioned) formal
dependency? Sounds good, as long as users can build component sites
independently from distros and we can make it easy for interested
parties to play with the l & f (so those who care can be those who do
;-). If you can break out some simple tasks for others to help with,
pls post here or to the ticket below.
Brett, I was going to have a go at the commons look and feel next.
Should I try altering the velocity template or should I await the new
skins feature?
While on the site, most people love the APT format in Maven 2, which is
a definite advantage of using that. Some might want to look into the
i18n aspects as well.
http://docs.codehaus.org/display/MAVEN/Sites+and+Inheritence
Unfortunately this didn't land during the hackathon as I had hoped, but
I'll get it together very soon.
Plugin versions - Maven 2 always treats plugins as dependencies. It has
discovery for versions and by prefix to reduce the burden during
development, but you can always enforce a particular version (or range
of versions) from the POM, and the release plugin locks it in to make
builds reproducible.
Custom plugin - should be easy to write on of these and tie it into the
Maven 2 lifecycle for annotating JARs with extra information. We will
also accept bug reports and patches as mentioned to the core plugins
where it might make more sense to adopt the same practices in general.
I am still getting used to the maven 2 lifcycle. Before starting on a
plugin, we should see how much can be accomplished directly by
configuring or patching the maven 2 plugins. The most common things
we need to do (actually, I think the list may be exhaustive) are:
1) compile and run tests (in some cases selectively)
2) generate sites locally, then publish (components separately, main
site by itself)
I'm working on this. Haven't gotten to the publish step yet.
3) create and deploy snapshot jars to internal apache repo
4) generate clirr/jdiff/clover/pmd/checkstyle and other code analysis
reports periodically
When you say "periodically", do you mean in an automated way? If so,
then this would be a new feature compared to the current commons-build
setup.
We should also standardize which of these reports we should use as much
as possible.
5) manage versioned javadocs
6) our wonderful release process (output is *signed* tarballs, zips
with "the right stuff" and release jar deployed to
/dist/java-repository)
7) generate working ant build.xml
We have some special requirements (at least some of us think so :-)
around jar manifest contents and the JDK version used to compile
distribution jars (not necessarily the same as the JDK that maven
itself runs under).
As I said, I am still grokking the maven 2 setup, so am not sure where
to start with patching existing plugins or creating new ones. I can't
see any but 6) as "special" - so it is probably best to get 1)-5),7)
covered by standard plugins (patched as necessary).
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
