commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Redeker <brede...@cc.edu>
Subject Re: [all] Project consistency (was Re: [math] Re: Getting started questions)
Date Tue, 03 Feb 2004 17:32:39 GMT

On Feb 3, 2004, at 9:43 AM, Mark R. Diggory wrote:
> Brent Redeker wrote:
>> On Feb 3, 2004, at 6:54 AM, Mark R. Diggory wrote:
>>>
>>> Here,here! I recommend using the maven generated, ant build.xml over 
>>> the maven project.xml for developer building and testing. This then 
>>> requires no dependencies on parent project.xml and it runs 
>>> independently in just about any IDE. I reserve my own usage of Maven 
>>> more for building site/releases, in which case you do need the 
>>> dependency on the parent project.xml.
>> I think this is a good suggestion. While I was setting myself up to 
>> be able to read/compile the sources, I really had little need to use 
>> Maven - build.xml is enough to compile and test the math project (and 
>> I assume Maven uses this as part of the process in creating a jar). 
>> Still, from what I can see, Maven might have uses for things other 
>> than just creating the web site and release builds. It downloads 
>> correct versions of all dependency jars, saving a little bit of work. 
>> Also, I imagine that if somebody makes documentation changes, they 
>> would need to do a 'maven site:generate' to see what the changes 
>> actually will look like.
>
> Yes, this is correct, But, at least in the math xdocs, I've provided 
> an xsl stylesheet that mimics the xdoc transform so that you can 
> loosely see what the contents will look like when generated (or at 
> least verify that the xml file is valid. Try looking at any of the 
> math/xdocs in Mozilla or I.E. you should see what I mean then.

Hmmm... learn something new every day, I guess. I hadn't tried looking 
at the xdocs in a browser yet.

> The build.xml file in math is actually generated by calling "maven 
> ant" which creates the build.xml (with the same dependencies as would 
> ahve been resolved by maven itself. Maven doesn't actually use this 
> build.xml file after this point though. So Mavne and build.xml will 
> both generate  approvximately the same jar contents, but any 
> customization to the maven jar goals (via pre/postGoals in the 
> maven.xml) will result in contents being different in the long run.

In light of this, would it be useful for developers to be using Maven 
as well - in case an updated project.xml generates a changed build.xml? 
Or is the build.xml file always updated in CVS if the project.xml file 
is? (In other words, would a developer ever _need_ to run Maven to have 
the latest Ant build file, or is the latest build.xml in CVS always 
current with project.xml?)

>> But for people who want to use Maven (for some reason or other), 
>> there could be instructions that say exactly which files/directories 
>> need to be checked out from jakarta-commons in addition to the 
>> jakarta-commons/math module.
>
> Yes, sensible. Ultimately I wish that the gloabal project contents 
> were not housed in the jakarta-commons root directory, but in another 
> "subproject" directory, then the two projects could be checked out in 
> the same directory (eclipse workspace for instance) and easily built 
> without having to get all the other commons projects. This would be 
> something to bring up to everyone on the developers list. Then all 
> project.xml would do something like
>
> <extend>../site/project.xml</extend>
>
> All that wold be required to checkout and build any project would be:
>
> cvs checkout site
>
> cvs checkout math
>
> This would also keep all the site dependencies well organized would it 
> not?

That's a great idea; it makes complete sense to me. This would still 
preserve consistency among Commons projects, while making the necessary 
steps to check out a single sub-project a little more concise. Probably 
a much better idea in the long run than just maintaining a special 
project.xml file without the parent directory dependencies.

Brent Redeker


---------------------------------------------------------------------
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