I also had the same thoughts during the initial timeframe when I was setting
up the Maven config.
I think we should stay away from getting too complex with config
inheritance.
I was thinking about this the other day, and what we might want do is move
to a completely independent maven configuration for all subprojects. We
will still share the build/ dir via svn:externals for common stuff like
license and CheckStyle config, but each subproject will be a complete
configuration itself (no <extends>).
By doing it this way, we can create a new project.xml and maven.xml in
current/ which is actually the "normal" way of doing it. This also puts the
subprojects in a position to go ahead and do releases independent of other
subprojects. We need to further discuss how we handle this with respect to
how Maven deals with dependencies. Specifically, someone will need to
maintain a chart of compatibility issues for all projects under Struts.
This will be the only way to keep "what version of core works with what
version of taglibs or el or foo" type questions from making this split even
worth the effort. As it is now, the same issue (sort of) applies across the
commons dependencies. Things can get very complicated, very fast.
In addition to the above, it will be easier for me to fix the problems with
the nightly build that come up every time anything is changed or released.
Currently the release targets are hardcoded in my cron script (because of
the way the files have to be named for the cleanup cron to work properly)
and I'd like to remove that inefficiency.
I'll be making some changes a little later today and more this week (as free
time allows).
With all hope, we can simplify this whole process and get it moved over to
our zone and stop relying on our personal machines and (my) sometimes flaky
network connection.
(Wendy, just got your other email, I'll look into doing that when things
settle down a bit)
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: jmitchtx
----- Original Message -----
From: "Wendy Smoak" <[EMAIL PROTECTED]>
To: "Struts Developers List" <dev@struts.apache.org>
Sent: Sunday, August 14, 2005 8:27 AM
Subject: Common build file issues (was Re: struts-faces won't compile)
Wendy wrote:
But there are things in the common build file that are *not*
common to all subprojects.
We needs a way to make sure that core/taglib/el/apps/plugins are all using
the same versions of their dependencies, without imposing those
dependencies on 'standalone' subprojects.
How about:
/current/build/project.xml
... has the list of committers, reports, etc. Only things that are common
to *all* sub-projects
/current/build/project-core.xml
... <extend>project.xml</extend>
... has the list of dependencies for struts-core
Then each subproject chooses which build file to extend.
- core, taglib, el, struts-tiles, apps, plugins can all extend
build/project-core.xml in order to keep their dependencies on [mostly]
commons libraries in sync. Even if the subproject doesn't necessarily
need
one of the dependencies that struts-core does, you can't use these
subprojects without core, so you end up needing that dependency anyway.
Subprojects can add additional dependencies, but can't remove the ones
they
inherit from core.
- Faces, Standalone Tiles, etc., can extend from the generic 'project.xml'
to pick up the list of committers, reports, etc., but are responsible for
their own dependencies.
--
Wendy
---------------------------------------------------------------------
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]
