Stephen Colebourne wrote:
Clever ;-) One slight flaw. Maven still won't run on a standlone release as
the maven.xml now requires commons-build ;-)


It is only a development time requirement, If your working on a commons project, you either checkout everything or checkout that which you want and commons-build. This has always been the status since we started using Maven (only in the beginning, you only needed the "jakarta-commons/project.xml" which is now in commons-build).


We could copy the maven.xml bit to each project's mavenxml (it should be a
standalone goal, not a post goal, so it isn't run when users call dist)


its currently only as postGoal in the generation of the source dist. I hope users aren't downloading the source dist and the calling the "dist" goal, they should be calling the "jar" goal.



However, I've tried a simpler solution in [collections]. commons.xml is checked into the CVS, as a copy of the shared version.

Project.xml:
<extend>${common.project.xml.file}</extend>

Project.properties:
# For active development
common.project.xml.file=../commons-build/project.xml
# For released code
#common.project.xml.file=commons.xml

This makes it not a "common" file, if your going to go that route, then we should abandon the whole extend feature in the first place. Something I'm starting to feel wishy washy about. The whole point of of the common build env. was to make sure that each project got the same settings. I'm not convinced this is a requirement if we are using entity includes and project.properties to modulate the site generation, I'm not really sure the extend feature really gains us anything but pain now. if we have properly templated project.xml in all the projects. then life could be easier.



At least a user can probably work that one out even if the release manager forgets to make the switch.

(Not sure how clever you could get. It would be better if it could test
whether the shared file exists and drop back, but I doubt that can be done
in one ${...} )

> Stephen

I'm avoiding conditional logic in the project.xml at all costs...

-Mark


-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to