You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Martin Cooper <ma...@apache.org> on 2004/02/03 04:46:54 UTC
[all] Project consistency (was Re: [math] Re: Getting started
questions)
On Mon, 2 Feb 2004, Phil Steitz wrote:
> Paul Libbrecht wrote:
> > Ah, this question is interesting.
> >
> > I recently removed the dependency on the ../project.xml in Jelly
> > because I think checking out a module should produce free-standing things.
> > Before being a commons-committer, I always patched the project.xml so
> > as to get rid of the project inheritance (which is only for a handful
> > of ownership information for the website anyways).
>
> These are good points. I would be +1 for doing this for [math].
-1
This seems like a bad idea to me. The whole point of doing this was to get
some consistency across Commons components. Remember that Commons is ONE
Jakarta subproject. It is not, and was never intended to be, a bunch of
independent projects. As such, it should have a consistent build system,
and a consistent web site. That is not going to happen if all of the
components start breaking away from the commonality we have managed to
introduce so far.
--
Martin Cooper
>
> <snip/>
>
> >
> > Also, why do you need jakarta-commons/xdocs/
>
> My mistake. All is actually needed is jakarta-commons/incl_nav.xml.
>
> Phil
>
>
> ---------------------------------------------------------------------
> 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: [all] Project consistency (was Re: [math] Re: Getting started questions)
Posted by Brent Redeker <br...@cc.edu>.
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
Re: [all] Project consistency (was Re: [math] Re: Getting started
questions)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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.
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.
> Although I'm new here, this thread kind of started because of my
> question. So my suggestion is that (perhaps in the Developer's Guide),
> using just build.xml for development should be encouraged.
Good Point.
> 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?
> This won't reduce external Maven dependencies, though. If there really
> is a desire to reduce external dependencies, could a second project.xml
> file be created in math that removes references to '../project.xml'?
> Then Maven could be called with 'maven -p onlymath.xml' (unless I
> misunderstand the -p switch), and this would be used only by developers
> who want less to download from CVS.
>
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Project consistency (was Re: [math] Re: Getting started questions)
Posted by Brent Redeker <br...@cc.edu>.
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.
Although I'm new here, this thread kind of started because of my
question. So my suggestion is that (perhaps in the Developer's Guide),
using just build.xml for development should be encouraged. 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. This won't reduce external Maven
dependencies, though. If there really is a desire to reduce external
dependencies, could a second project.xml file be created in math that
removes references to '../project.xml'? Then Maven could be called with
'maven -p onlymath.xml' (unless I misunderstand the -p switch), and
this would be used only by developers who want less to download from
CVS.
Anyway, just my 2 cents.
Brent Redeker
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Project consistency (was Re: [math] Re: Getting started
questions)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Martin Cooper wrote:
> On Mon, 2 Feb 2004, Phil Steitz wrote:
>
>
>>Paul Libbrecht wrote:
>>
>>>Ah, this question is interesting.
>>>
>>>I recently removed the dependency on the ../project.xml in Jelly
>>>because I think checking out a module should produce free-standing things.
>>>Before being a commons-committer, I always patched the project.xml so
>>>as to get rid of the project inheritance (which is only for a handful
>>>of ownership information for the website anyways).
>>
>>These are good points. I would be +1 for doing this for [math].
>
>
> -1
>
> This seems like a bad idea to me. The whole point of doing this was to get
> some consistency across Commons components. Remember that Commons is ONE
> Jakarta subproject. It is not, and was never intended to be, a bunch of
> independent projects. As such, it should have a consistent build system,
> and a consistent web site. That is not going to happen if all of the
> components start breaking away from the commonality we have managed to
> introduce so far.
>
> --
> Martin Cooper
>
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.
>
>
>><snip/>
>>
>>>Also, why do you need jakarta-commons/xdocs/
>>
>>My mistake. All is actually needed is jakarta-commons/incl_nav.xml.
>>
>>Phil
>>
>>
>>---------------------------------------------------------------------
>>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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org