You are viewing a plain text version of this content. The canonical link for it is here.
Posted to alexandria-dev@jakarta.apache.org by co...@apache.org on 2003/01/05 14:33:07 UTC
cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
conor 2003/01/05 05:33:07
Modified: project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml
xml-xerces.xml
Log:
First pass at making jaxp and jsse optional so that packages are not required
under jdk 1.4
Revision Changes Path
1.84 +15 -15 jakarta-gump/project/jakarta-ant.xml
Index: jakarta-ant.xml
===================================================================
RCS file: /home/cvs/jakarta-gump/project/jakarta-ant.xml,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -w -u -r1.83 -r1.84
--- jakarta-ant.xml 21 Dec 2002 23:24:44 -0000 1.83
+++ jakarta-ant.xml 5 Jan 2003 13:33:07 -0000 1.84
@@ -108,7 +108,7 @@
<project name="bootstrap-ant">
<script name="bootstrap"/>
- <depend project="jaxp"/>
+ <option project="jaxp"/>
<home nested="bootstrap"/>
<jar name="lib/ant.jar"/>
1.96 +8 -8 jakarta-gump/project/jakarta-commons.xml
Index: jakarta-commons.xml
===================================================================
RCS file: /home/cvs/jakarta-gump/project/jakarta-commons.xml,v
retrieving revision 1.95
retrieving revision 1.96
diff -u -w -u -r1.95 -r1.96
--- jakarta-commons.xml 31 Dec 2002 13:56:09 -0000 1.95
+++ jakarta-commons.xml 5 Jan 2003 13:33:07 -0000 1.96
@@ -187,7 +187,7 @@
<ant basedir="httpclient" target="dist"/>
<depend project="jakarta-ant" inherit="runtime"/>
<depend project="xml-xerces"/>
- <depend project="jsse"/>
+ <option project="jsse"/>
<depend project="jakarta-log4j"/>
<depend project="commons-logging"/>
<!-- included in JDK 1.4 depend project="jce"/-->
1.47 +2 -2 jakarta-gump/project/jakarta-taglibs.xml
Index: jakarta-taglibs.xml
===================================================================
RCS file: /home/cvs/jakarta-gump/project/jakarta-taglibs.xml,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -w -u -r1.46 -r1.47
--- jakarta-taglibs.xml 9 Dec 2002 13:36:53 -0000 1.46
+++ jakarta-taglibs.xml 5 Jan 2003 13:33:07 -0000 1.47
@@ -363,7 +363,7 @@
<depend property="dom.jar" project="jaxp" id="dom"/>
<depend property="jdbc2_0-stdext.jar" project="jdbc"/>
<depend property="jaxen-full.jar" project="jaxen"/>
- <depend property="jaxp-api.jar" project="jaxp" id="jaxp-api"/>
+ <option property="jaxp-api.jar" project="jaxp" id="jaxp-api"/>
<depend property="jxpath.jar" project="commons-jxpath"/>
<depend property="sax.jar" project="jaxp" id="sax"/>
<depend property="saxpath.jar" project="saxpath"/>
@@ -428,7 +428,7 @@
<ant basedir="xtags" target="dist">
<depend property="crimson.jar" project="xml-xerces" id="parser"/>
<depend property="dom4j.jar" project="dom4j"/>
- <depend property="jaxp.jar" project="xml-xerces" id="apis"/>
+ <option property="jaxp.jar" project="xml-xerces" id="apis"/>
<depend property="servlet.jar" project="jakarta-servletapi-4"/>
<depend property="xalan.jar" project="xml-xalan2"/>
<property name="build.dir" path="build"/>
1.6 +2 -2 jakarta-gump/project/uddi4j.xml
Index: uddi4j.xml
===================================================================
RCS file: /home/cvs/jakarta-gump/project/uddi4j.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -w -u -r1.5 -r1.6
--- uddi4j.xml 20 Jul 2002 06:11:25 -0000 1.5
+++ uddi4j.xml 5 Jan 2003 13:33:07 -0000 1.6
@@ -16,7 +16,7 @@
<depend project="jakarta-ant" inherit="runtime"/>
<option project="xml-soap"/>
<option project="xml-axis"/>
- <depend project="jsse"/>
+ <option project="jsse"/>
<work nested="build/classes"/>
<home nested="build"/>
1.9 +3 -3 jakarta-gump/project/xml-crimson.xml
Index: xml-crimson.xml
===================================================================
RCS file: /home/cvs/jakarta-gump/project/xml-crimson.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -w -u -r1.8 -r1.9
--- xml-crimson.xml 31 Jul 2002 14:47:38 -0000 1.8
+++ xml-crimson.xml 5 Jan 2003 13:33:07 -0000 1.9
@@ -13,7 +13,7 @@
<ant target="dist">
<property name="build.dir" value="build"/>
</ant>
- <depend project="jaxp" ids="jaxp-api dom sax parser" />
+ <option project="jaxp" ids="jaxp-api dom sax parser" />
<depend project="bootstrap-ant"/>
<javadoc nested="build/docs/api"/>
<home nested="build"/>
1.20 +2 -2 jakarta-gump/project/xml-xerces.xml
Index: xml-xerces.xml
===================================================================
RCS file: /home/cvs/jakarta-gump/project/xml-xerces.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -w -u -r1.19 -r1.20
--- xml-xerces.xml 31 Jul 2002 14:47:38 -0000 1.19
+++ xml-xerces.xml 5 Jan 2003 13:33:07 -0000 1.20
@@ -11,7 +11,7 @@
<project name="xml-xerces1">
<ant basedir="java" target="jar"/>
- <depend project="jaxp"/>
+ <option project="jaxp"/>
<depend project="bootstrap-ant"/>
<home nested="java/build"/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>> I was thinking about the conceptual idea of having
>> descriptors for Centipede projects in Gump CVS, and how this would
>> make things difficult for Centipede projects.
>
> Suggestion: let's just note that it is very easy to move descriptors.
>
> For ASF projects which are not (yet) centipede based, the path of least
> resistance seems to be to put them in the gump cvs repository.
>
> Given the current implementation of Centipede, the path of least
> resistance for projects which are currently and actively using centipede
> is to put such project descriptors in the project cvs.
>
> Moving project descriptors in anticipation of future use seems
> counter-productive at this time.
>
> Future versions of gump or centipede (or centigump or gumpipede or
> whatever) may change these observations.
[...]
> Peace?
:-)
I agree on all the line. Well said. Thank you.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>> I was thinking about the conceptual idea of having
>> descriptors for Centipede projects in Gump CVS, and how this would
>> make things difficult for Centipede projects.
>
> Suggestion: let's just note that it is very easy to move descriptors.
>
> For ASF projects which are not (yet) centipede based, the path of least
> resistance seems to be to put them in the gump cvs repository.
>
> Given the current implementation of Centipede, the path of least
> resistance for projects which are currently and actively using centipede
> is to put such project descriptors in the project cvs.
>
> Moving project descriptors in anticipation of future use seems
> counter-productive at this time.
>
> Future versions of gump or centipede (or centigump or gumpipede or
> whatever) may change these observations.
[...]
> Peace?
:-)
I agree on all the line. Well said. Thank you.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
>> well, no (and it's not to be taken as a proposal ;). But it is the
>> easiest thing that could possibly work (in that I could probably set
>> it up). I'm totally supportive for real solutions, but I'm okay with
>> hacky solutions until those real solutions arrive (to paraphrase Berin
>> "waiting until the next release of [the maven and centipede] projects").
>
> Yes, I agree too. I was thinking about the conceptual idea of having
> descriptors for Centipede projects in Gump CVS, and how this would make
> things difficult for Centipede projects.
Suggestion: let's just note that it is very easy to move descriptors.
For ASF projects which are not (yet) centipede based, the path of least
resistance seems to be to put them in the gump cvs repository.
Given the current implementation of Centipede, the path of least
resistance for projects which are currently and actively using centipede
is to put such project descriptors in the project cvs.
Moving project descriptors in anticipation of future use seems
counter-productive at this time.
Future versions of gump or centipede (or centigump or gumpipede or
whatever) may change these observations.
Finally, despite these observations, people are free to put their
descriptors in any accessible location as long as they are willing to
actively maintain them.
Peace?
- Sam Ruby
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
>> well, no (and it's not to be taken as a proposal ;). But it is the
>> easiest thing that could possibly work (in that I could probably set
>> it up). I'm totally supportive for real solutions, but I'm okay with
>> hacky solutions until those real solutions arrive (to paraphrase Berin
>> "waiting until the next release of [the maven and centipede] projects").
>
> Yes, I agree too. I was thinking about the conceptual idea of having
> descriptors for Centipede projects in Gump CVS, and how this would make
> things difficult for Centipede projects.
Suggestion: let's just note that it is very easy to move descriptors.
For ASF projects which are not (yet) centipede based, the path of least
resistance seems to be to put them in the gump cvs repository.
Given the current implementation of Centipede, the path of least
resistance for projects which are currently and actively using centipede
is to put such project descriptors in the project cvs.
Moving project descriptors in anticipation of future use seems
counter-productive at this time.
Future versions of gump or centipede (or centigump or gumpipede or
whatever) may change these observations.
Finally, despite these observations, people are free to put their
descriptors in any accessible location as long as they are willing to
actively maintain them.
Peace?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Nicola Ken Barozzi wrote:
>
>>> To solve the centipede problem @ apache: simply make the gump repo a
>>> requirment for building the project! That might also help 'edjucate'
>>> ignorant developers (like, until recently, me) about the wonders and
>>> importance of gump.
>>
[...]
>> Doesn't it also have to work?
>
>
> Nicola, I'm really not trying to make your life harder, or make your job
> on centipede more difficult. Really. But fact-of-the-matter, right now,
> and for the past few months, the avalon peeps (including you and me)
> have been terrible at maintaining gump descriptors (or even the build
> process), and until I see things work differently (I've been trying) I'm
> thinking along the same lines Sam is.
For Avalon, as for any *Ant* project, now that Gump is open to all
Apache, I agree. I have in fact moved now the descriptor back in Gump CVS.
My point is about *Centipede* projects. POI now builds fine with Gump,
and it uses Centipede.
If Centipede makes it compulsory to have a descriptor just to do normal
builds, I reckon that putting the descriptor in Gump CVS is not needed,
and even, as I'm trying to suggest, a problem.
[...]
>> Honestly, Leo, imagine you're a Centipede developer. And you want to
>> give an easy build system to your users. Do you really think that your
>> proposal is a real solution?
>
>
> well, no (and it's not to be taken as a proposal ;). But it is the
> easiest thing that could possibly work (in that I could probably set it
> up). I'm totally supportive for real solutions, but I'm okay with hacky
> solutions until those real solutions arrive (to paraphrase Berin
> "waiting until the next release of [the maven and centipede] projects").
Yes, I agree too. I was thinking about the conceptual idea of having
descriptors for Centipede projects in Gump CVS, and how this would make
things difficult for Centipede projects.
>> Look at it from my perspective too.
>
> I am, I am!
:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Nicola Ken Barozzi wrote:
>
>>> To solve the centipede problem @ apache: simply make the gump repo a
>>> requirment for building the project! That might also help 'edjucate'
>>> ignorant developers (like, until recently, me) about the wonders and
>>> importance of gump.
>>
[...]
>> Doesn't it also have to work?
>
>
> Nicola, I'm really not trying to make your life harder, or make your job
> on centipede more difficult. Really. But fact-of-the-matter, right now,
> and for the past few months, the avalon peeps (including you and me)
> have been terrible at maintaining gump descriptors (or even the build
> process), and until I see things work differently (I've been trying) I'm
> thinking along the same lines Sam is.
For Avalon, as for any *Ant* project, now that Gump is open to all
Apache, I agree. I have in fact moved now the descriptor back in Gump CVS.
My point is about *Centipede* projects. POI now builds fine with Gump,
and it uses Centipede.
If Centipede makes it compulsory to have a descriptor just to do normal
builds, I reckon that putting the descriptor in Gump CVS is not needed,
and even, as I'm trying to suggest, a problem.
[...]
>> Honestly, Leo, imagine you're a Centipede developer. And you want to
>> give an easy build system to your users. Do you really think that your
>> proposal is a real solution?
>
>
> well, no (and it's not to be taken as a proposal ;). But it is the
> easiest thing that could possibly work (in that I could probably set it
> up). I'm totally supportive for real solutions, but I'm okay with hacky
> solutions until those real solutions arrive (to paraphrase Berin
> "waiting until the next release of [the maven and centipede] projects").
Yes, I agree too. I was thinking about the conceptual idea of having
descriptors for Centipede projects in Gump CVS, and how this would make
things difficult for Centipede projects.
>> Look at it from my perspective too.
>
> I am, I am!
:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
>> To solve the centipede problem @ apache: simply make the gump repo a
>> requirment for building the project! That might also help 'edjucate'
>> ignorant developers (like, until recently, me) about the wonders and
>> importance of gump.
>
> Checking out the Gump repo will help ignorant developers understand the
> wonders and importance of Gump?
well, yeah. You need to be aggressively slamming 'em on the head with
it, and then putting it within their line of sight. I had a filter on
'[GUMP]', sending the messages to a special folder marked 'need-to-fix'
and with a red font. Didn't actually work. Verbally hit me on the head
with something and I'll work on it though (thanks Sam :).
> Doesn't it also have to work?
Nicola, I'm really not trying to make your life harder, or make your job
on centipede more difficult. Really. But fact-of-the-matter, right now,
and for the past few months, the avalon peeps (including you and me)
have been terrible at maintaining gump descriptors (or even the build
process), and until I see things work differently (I've been trying) I'm
thinking along the same lines Sam is.
> Make it easy to use and I can start to
> agree. That's what we want to do by making a system that automatically
> creates a profile for your local Gump, given the local projects.
sounds good to me. More work, better results :D
I'm just being a real pragmatist: I need a fortress release (that's one
of the packages in avalon-excalibur that doesn't work) in a few weeks,
and I'd like a few nightly builds to start testing.
>> If I have to do
>>
>> cvs co jakarta-avalon jakarta-gump
>> centipede jakarta-gump/projects/jakarta-avalon.xml
>>
>> instead of
>>
>> cvs co jakarta-avalon
>> centipede jakarta-avalon/project-descriptor.xml
>>
>> well, I can live with that.
>
> So a user that gets a source distro of a project, he cannot compile
> without also downloading Gump?
IIUC, something that could work right now is copying the gump descriptor
into the base dir of the source distro, and putting in place a different
'.properties' file or something like that?
>> And if I can have the commands
>>
>> cvs co jakarta-avalon
>> ant jakarta-avalon/build.xml
>>
>> result in the same thing, what's left to complain about? :D
btw, my idea was that build.xml would check out gump and centipede,
acting as a 'bootstrap'. Should be doable, no? ie something like:
<project default="main">
<target name="main">
<cvs checkout="${centipede}" repo="${krysalis}"
dir=".."/>
<cvs checkout="${gump}" repo="${jakarta}"
dir=".."/>
<exec script="../${centipede}/bootstrap.sh"/>
<cent/>
<gump/>
</target>
</project>
> Honestly, Leo, imagine you're a Centipede developer. And you want to
> give an easy build system to your users. Do you really think that your
> proposal is a real solution?
well, no (and it's not to be taken as a proposal ;). But it is the
easiest thing that could possibly work (in that I could probably set it
up). I'm totally supportive for real solutions, but I'm okay with hacky
solutions until those real solutions arrive (to paraphrase Berin
"waiting until the next release of [the maven and centipede] projects").
> Look at it from my perspective too.
I am, I am!
cheers,
- Leo
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
>> To solve the centipede problem @ apache: simply make the gump repo a
>> requirment for building the project! That might also help 'edjucate'
>> ignorant developers (like, until recently, me) about the wonders and
>> importance of gump.
>
> Checking out the Gump repo will help ignorant developers understand the
> wonders and importance of Gump?
well, yeah. You need to be aggressively slamming 'em on the head with
it, and then putting it within their line of sight. I had a filter on
'[GUMP]', sending the messages to a special folder marked 'need-to-fix'
and with a red font. Didn't actually work. Verbally hit me on the head
with something and I'll work on it though (thanks Sam :).
> Doesn't it also have to work?
Nicola, I'm really not trying to make your life harder, or make your job
on centipede more difficult. Really. But fact-of-the-matter, right now,
and for the past few months, the avalon peeps (including you and me)
have been terrible at maintaining gump descriptors (or even the build
process), and until I see things work differently (I've been trying) I'm
thinking along the same lines Sam is.
> Make it easy to use and I can start to
> agree. That's what we want to do by making a system that automatically
> creates a profile for your local Gump, given the local projects.
sounds good to me. More work, better results :D
I'm just being a real pragmatist: I need a fortress release (that's one
of the packages in avalon-excalibur that doesn't work) in a few weeks,
and I'd like a few nightly builds to start testing.
>> If I have to do
>>
>> cvs co jakarta-avalon jakarta-gump
>> centipede jakarta-gump/projects/jakarta-avalon.xml
>>
>> instead of
>>
>> cvs co jakarta-avalon
>> centipede jakarta-avalon/project-descriptor.xml
>>
>> well, I can live with that.
>
> So a user that gets a source distro of a project, he cannot compile
> without also downloading Gump?
IIUC, something that could work right now is copying the gump descriptor
into the base dir of the source distro, and putting in place a different
'.properties' file or something like that?
>> And if I can have the commands
>>
>> cvs co jakarta-avalon
>> ant jakarta-avalon/build.xml
>>
>> result in the same thing, what's left to complain about? :D
btw, my idea was that build.xml would check out gump and centipede,
acting as a 'bootstrap'. Should be doable, no? ie something like:
<project default="main">
<target name="main">
<cvs checkout="${centipede}" repo="${krysalis}"
dir=".."/>
<cvs checkout="${gump}" repo="${jakarta}"
dir=".."/>
<exec script="../${centipede}/bootstrap.sh"/>
<cent/>
<gump/>
</target>
</project>
> Honestly, Leo, imagine you're a Centipede developer. And you want to
> give an easy build system to your users. Do you really think that your
> proposal is a real solution?
well, no (and it's not to be taken as a proposal ;). But it is the
easiest thing that could possibly work (in that I could probably set it
up). I'm totally supportive for real solutions, but I'm okay with hacky
solutions until those real solutions arrive (to paraphrase Berin
"waiting until the next release of [the maven and centipede] projects").
> Look at it from my perspective too.
I am, I am!
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Sam Ruby wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> What about making Gump commit the latest descriptors in its CVS at
>>> every run? With the possibility of not-synching for some projects in
>>> case ASF developers want to try and fix the Gump version?
[...]
> For apache, the choice is rather easy to make: we generally trust all
> asf committers to behave, and hence opening up the gump repo should not
> present a problem. With the modest size of the new repo, it is also not
> a big burden to keep a local copy of the gump repo updated. Once you
> adjust to the idea "the project descriptor is in a different cvs",
> there's virtually no difference.
[...]
>
> which leads me to believe that the current setup is the best -- we do both:
>
> Put the ASF project descriptors in the gump repo, and put the non-ASF
> project descriptors elsewhere, where those projects have the option to
> give the dependency magicians (like sam) access to their project
> descriptor.
>
> ---
>
> To solve the centipede problem @ apache: simply make the gump repo a
> requirment for building the project! That might also help 'edjucate'
> ignorant developers (like, until recently, me) about the wonders and
> importance of gump.
Checking out the Gump repo will help ignorant developers understand the
wonders and importance of Gump?
Doesn't it also have to work? Make it easy to use and I can start to
agree. That's what we want to do by making a system that automatically
creates a profile for your local Gump, given the local projects.
> If I have to do
>
> cvs co jakarta-avalon jakarta-gump
> centipede jakarta-gump/projects/jakarta-avalon.xml
>
> instead of
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/project-descriptor.xml
>
> well, I can live with that.
So a user that gets a source distro of a project, he cannot compile
without also downloading Gump?
> And if I can have the commands
>
> cvs co jakarta-avalon
> ant jakarta-avalon/build.xml
>
> result in the same thing, what's left to complain about? :D
Not with Centipede. With Centipede you *need* the descriptor. That's
what it's all about. If you don't need it to build, it will never be
kept updated.
So I reasonably *need* the descriptor to be with the project. I can
synch with Gump, or viceversa, but in the end I need the descriptor in
the project dir.
Honestly, Leo, imagine you're a Centipede developer. And you want to
give an easy build system to your users. Do you really think that your
proposal is a real solution? Look at it from my perspective too.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Sam Ruby wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> What about making Gump commit the latest descriptors in its CVS at
>>> every run? With the possibility of not-synching for some projects in
>>> case ASF developers want to try and fix the Gump version?
[...]
> For apache, the choice is rather easy to make: we generally trust all
> asf committers to behave, and hence opening up the gump repo should not
> present a problem. With the modest size of the new repo, it is also not
> a big burden to keep a local copy of the gump repo updated. Once you
> adjust to the idea "the project descriptor is in a different cvs",
> there's virtually no difference.
[...]
>
> which leads me to believe that the current setup is the best -- we do both:
>
> Put the ASF project descriptors in the gump repo, and put the non-ASF
> project descriptors elsewhere, where those projects have the option to
> give the dependency magicians (like sam) access to their project
> descriptor.
>
> ---
>
> To solve the centipede problem @ apache: simply make the gump repo a
> requirment for building the project! That might also help 'edjucate'
> ignorant developers (like, until recently, me) about the wonders and
> importance of gump.
Checking out the Gump repo will help ignorant developers understand the
wonders and importance of Gump?
Doesn't it also have to work? Make it easy to use and I can start to
agree. That's what we want to do by making a system that automatically
creates a profile for your local Gump, given the local projects.
> If I have to do
>
> cvs co jakarta-avalon jakarta-gump
> centipede jakarta-gump/projects/jakarta-avalon.xml
>
> instead of
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/project-descriptor.xml
>
> well, I can live with that.
So a user that gets a source distro of a project, he cannot compile
without also downloading Gump?
> And if I can have the commands
>
> cvs co jakarta-avalon
> ant jakarta-avalon/build.xml
>
> result in the same thing, what's left to complain about? :D
Not with Centipede. With Centipede you *need* the descriptor. That's
what it's all about. If you don't need it to build, it will never be
kept updated.
So I reasonably *need* the descriptor to be with the project. I can
synch with Gump, or viceversa, but in the end I need the descriptor in
the project dir.
Honestly, Leo, imagine you're a Centipede developer. And you want to
give an easy build system to your users. Do you really think that your
proposal is a real solution? Look at it from my perspective too.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
>
> Sam Ruby wrote:
> [...]
>
>> Suppose centipede had a "gen" step that took a profile or workspace
>> description and produced a single build.xml that could be run
>> completely offline?
>>
>> cvs co jakarta-avalon
>> centipede jakarta-avalon/profile.xml
>> ant jakarta-avalon/build.xml
>>
>> Or, if you prefer, centipede could have options to "gen and run", or
>> "run without regening".
>>
>> Such profiles could even reference multiple projects, and could
>> automatically build each in the correct order.
>>
>> And power users could define workspaces that include multiple
>> profiles, and provide override as appropriate.
>
>
> Welcome to Centipede's view.
>
>
> Actually it would be a bit different.
>
> cvs co jakarta-avalon
> cent
>
> I had at one point included Jenny in Centipede to run gen at every
> project descriptor change, but other things needed to be in place to
> make it run.
>
> So now the goal for me is is:
>
> - centipede builds a single module.
> Dependencies are traversed if the projects are in the same module,
> and centipede builds them in the correct order.
> Outer-module dependencies are automatically downloaded.
> This is a use-case for excalibur.
Lets add another middle goal.
- centipded builds mutliple arbitrary modules.
A user defines a set of modules (a workspace).
centipede all projects, downloading jars for projects not in the
workspace.
This is the use case I need for my clients.
I think supporting this middle ground will cover both ends.
The default workspace is ./module.xml
The max workspace is gump.xml + ./module.xml + others
I think what we con do from centipede is modify gen.sh (probably in
jenny)
Instead of dropping is project when a dependency is not found. add the
depenency as installed package and use ruper(or something) to get the
download the jar.
>
>
> - Centipede shall have a feature that it can automatically install
> a working Gump system with the local Centipede projects.
> The user can then tweak as wanted, and compile every local
> project from local versions using Gump.
> Thus building also non-centipede projects in the process.
>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
>
> Sam Ruby wrote:
> [...]
>
>> Suppose centipede had a "gen" step that took a profile or workspace
>> description and produced a single build.xml that could be run
>> completely offline?
>>
>> cvs co jakarta-avalon
>> centipede jakarta-avalon/profile.xml
>> ant jakarta-avalon/build.xml
>>
>> Or, if you prefer, centipede could have options to "gen and run", or
>> "run without regening".
>>
>> Such profiles could even reference multiple projects, and could
>> automatically build each in the correct order.
>>
>> And power users could define workspaces that include multiple
>> profiles, and provide override as appropriate.
>
>
> Welcome to Centipede's view.
>
>
> Actually it would be a bit different.
>
> cvs co jakarta-avalon
> cent
>
> I had at one point included Jenny in Centipede to run gen at every
> project descriptor change, but other things needed to be in place to
> make it run.
>
> So now the goal for me is is:
>
> - centipede builds a single module.
> Dependencies are traversed if the projects are in the same module,
> and centipede builds them in the correct order.
> Outer-module dependencies are automatically downloaded.
> This is a use-case for excalibur.
Lets add another middle goal.
- centipded builds mutliple arbitrary modules.
A user defines a set of modules (a workspace).
centipede all projects, downloading jars for projects not in the
workspace.
This is the use case I need for my clients.
I think supporting this middle ground will cover both ends.
The default workspace is ./module.xml
The max workspace is gump.xml + ./module.xml + others
I think what we con do from centipede is modify gen.sh (probably in
jenny)
Instead of dropping is project when a dependency is not found. add the
depenency as installed package and use ruper(or something) to get the
download the jar.
>
>
> - Centipede shall have a feature that it can automatically install
> a working Gump system with the local Centipede projects.
> The user can then tweak as wanted, and compile every local
> project from local versions using Gump.
> Thus building also non-centipede projects in the process.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
[...]
> Suppose centipede had a "gen" step that took a profile or workspace
> description and produced a single build.xml that could be run completely
> offline?
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/profile.xml
> ant jakarta-avalon/build.xml
>
> Or, if you prefer, centipede could have options to "gen and run", or
> "run without regening".
>
> Such profiles could even reference multiple projects, and could
> automatically build each in the correct order.
>
> And power users could define workspaces that include multiple profiles,
> and provide override as appropriate.
Welcome to Centipede's view.
Actually it would be a bit different.
cvs co jakarta-avalon
cent
I had at one point included Jenny in Centipede to run gen at every
project descriptor change, but other things needed to be in place to
make it run.
So now the goal for me is is:
- centipede builds a single module.
Dependencies are traversed if the projects are in the same module,
and centipede builds them in the correct order.
Outer-module dependencies are automatically downloaded.
This is a use-case for excalibur.
- Centipede shall have a feature that it can automatically install
a working Gump system with the local Centipede projects.
The user can then tweak as wanted, and compile every local
project from local versions using Gump.
Thus building also non-centipede projects in the process.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
[...]
> Suppose centipede had a "gen" step that took a profile or workspace
> description and produced a single build.xml that could be run completely
> offline?
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/profile.xml
> ant jakarta-avalon/build.xml
>
> Or, if you prefer, centipede could have options to "gen and run", or
> "run without regening".
>
> Such profiles could even reference multiple projects, and could
> automatically build each in the correct order.
>
> And power users could define workspaces that include multiple profiles,
> and provide override as appropriate.
Welcome to Centipede's view.
Actually it would be a bit different.
cvs co jakarta-avalon
cent
I had at one point included Jenny in Centipede to run gen at every
project descriptor change, but other things needed to be in place to
make it run.
So now the goal for me is is:
- centipede builds a single module.
Dependencies are traversed if the projects are in the same module,
and centipede builds them in the correct order.
Outer-module dependencies are automatically downloaded.
This is a use-case for excalibur.
- Centipede shall have a feature that it can automatically install
a working Gump system with the local Centipede projects.
The user can then tweak as wanted, and compile every local
project from local versions using Gump.
Thus building also non-centipede projects in the process.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
>
> If I have to do
>
> cvs co jakarta-avalon jakarta-gump
> centipede jakarta-gump/projects/jakarta-avalon.xml
>
> instead of
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/project-descriptor.xml
>
> well, I can live with that. And if I can have the commands
>
> cvs co jakarta-avalon
> ant jakarta-avalon/build.xml
>
> result in the same thing, what's left to complain about? :D
You posted is thought provoking. Permit me to respond in kind.
The original intent of the project descriptors was that it be extensible
in multiple directions. Not only that a project descriptor could
contain optional elements that would be ignored by some tools, but that
tools like gump would intelligently "merge" multiple project definitions.
Example: a project definition for jakarta-avalon-db would say that it
simply depends on *a* version of jakarta-regexp. A jakarta-avalon
profile could say that version 1.2 is preferred. The LeoSimons
workspace could say: no, not really, I want to use the version that I
built on my hard drive.
Suppose centipede had a "gen" step that took a profile or workspace
description and produced a single build.xml that could be run completely
offline?
cvs co jakarta-avalon
centipede jakarta-avalon/profile.xml
ant jakarta-avalon/build.xml
Or, if you prefer, centipede could have options to "gen and run", or
"run without regening".
Such profiles could even reference multiple projects, and could
automatically build each in the correct order.
And power users could define workspaces that include multiple profiles,
and provide override as appropriate.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
>
> If I have to do
>
> cvs co jakarta-avalon jakarta-gump
> centipede jakarta-gump/projects/jakarta-avalon.xml
>
> instead of
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/project-descriptor.xml
>
> well, I can live with that. And if I can have the commands
>
> cvs co jakarta-avalon
> ant jakarta-avalon/build.xml
>
> result in the same thing, what's left to complain about? :D
You posted is thought provoking. Permit me to respond in kind.
The original intent of the project descriptors was that it be extensible
in multiple directions. Not only that a project descriptor could
contain optional elements that would be ignored by some tools, but that
tools like gump would intelligently "merge" multiple project definitions.
Example: a project definition for jakarta-avalon-db would say that it
simply depends on *a* version of jakarta-regexp. A jakarta-avalon
profile could say that version 1.2 is preferred. The LeoSimons
workspace could say: no, not really, I want to use the version that I
built on my hard drive.
Suppose centipede had a "gen" step that took a profile or workspace
description and produced a single build.xml that could be run completely
offline?
cvs co jakarta-avalon
centipede jakarta-avalon/profile.xml
ant jakarta-avalon/build.xml
Or, if you prefer, centipede could have options to "gen and run", or
"run without regening".
Such profiles could even reference multiple projects, and could
automatically build each in the correct order.
And power users could define workspaces that include multiple profiles,
and provide override as appropriate.
- Sam Ruby
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Leo Simons <le...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>> What about making Gump commit the latest descriptors in its CVS at
>> every run? With the possibility of not-synching for some projects in
>> case ASF developers want to try and fix the Gump version?
>
> Let express my root need or requirement, then we can discuss
> implementations.
>
> My experience is that if descriptors are moved to Avalon, they rot.
yup. Also, I like having the descriptors that gump uses locally as it
makes 'ant gen' run faster, and one can do checking of edits without
having to commit (as it is now, I have to commit the project descriptor
in avalon in order to test it does as it should using gump).
OTOH, if a project descriptor were to actually replace an ant build
file, I really doubt the descriptor would still rot as badly.
> What's worse is that people who care are excluded from making changes.
Which is a thoughtline we could extend to levelling out cvs privs across
the ASF but that's a different argumen t;)
long thought process below (nothing better to do)...
----
I like Seperation of Concerns:
concern 1: building of a software project. You want a way to
automatically build software releases and related materials (website 'n
stuff)
concern 2: testing of a software project. I usually want to do this at
least every hour or so when I'm working on stuff. Avalon has very little
in the way of unittests but for projects at work I often run 'ant test'
using watch, re-running as much as every 5 mins or so.
concern 3: dependency verification for a set of related software
projects. You want to make sure a change in product X doesn't affect
product Y.
concern 4: providing "early access" downloads of development version of
a software project.
(did I get all of em?)
how do these concerns relate?
Well, the first step in testing a project is usually making sure it
builds, ie there's real close coupling between 1 & 2.
The coupling between (1+2) on the one hand and 3 on the other is more
loose: it can be acceptable for a project to work with version y of a
project and then not with version z because of backwards-incompatible
changes, as long as this is a design decision.
The coupling between 4 and 1 is again big: an early acess download
basically is an easily accessible build of the project.
---
The value of ant is that it provides a scripting language for handling
of tasks 1 & 2 (another benefit is that scripting languages are easily
'abused' for other tasks).
The value of gump is that it handles task 3. In doing so, it basically
defers responsibility for task 1 & 2 (which need to be accomplished in
order to do 3) back to ant.
The output of gump automatically results in early access downloads if a
gump run succeeds.
---
The annoying bit is that it is not possible to simply put the data that
gump needs in a form as simple as:
asfRepo="cvs.apache.org:/home/cvspublic";
sfRepo="cvs.sf.net:/home/cvspublic";
...
asfModules="$asfRepo:jakarta-ant $asfRepo:jakarta-avalon
$asfRepo:jakarta-tomcat ...";
...
modules="$asfModules $sfModules ...";
doyourmagicon $modules;
because not every project uses ant, every project that does uses it
slightly differently, it is not so easy to override something defined in
an ant buildfile, and it is not so easy to figure out relationships
between ant buildfiles. Hence the data that must be fed into gump is a
lot more elaborate.
---
So, what's the plan? We replace ant's buildfile by something from which
ant's buildfile is generated (heck, actual use of ant can become
optional!), *and* from which gumps descriptors are also generated. In
fact, it might be possible to generate the ant buildfile by adding just
a little bit of info into the gump descriptor. Tada: centipede!
---
You already knew all this. Now a concern in a different dimension: who
takes care of the various tasks, and how does this fit in with the
technology we use (cvs), and the access control required?
The people that develop the software want to be able to modify their
build script as they modify their software; otherwise testing becomes
problematic.
The people that develop the software apparantly don't care too much for
maintaining the dependency mapping, so you want the people that _do_
care about that to be able to maintain the dependency mappings for them.
When you merge the dependency mapping and the build scripts into a
single file, there's an access priviledge issue: two different groups of
people need access.
---
I see two main options:
1) give the people that develop the software access to the project that
maintains the descriptors (ie give all developers access to gump); give
the people that administer the dependencies access too.
2) give the people that administer the dependencies access to all
software projects.
neither is really satisfactory: giving "all developers" access to gump
would mean wiki-style access control which people are afraid of, whereas
giving the gump admins access to all software is going to affect the
'personal playground feeling and/or software security' of the software
projects.
For apache, the choice is rather easy to make: we generally trust all
asf committers to behave, and hence opening up the gump repo should not
present a problem. With the modest size of the new repo, it is also not
a big burden to keep a local copy of the gump repo updated. Once you
adjust to the idea "the project descriptor is in a different cvs",
there's virtually no difference.
Taking into account the rest of the world is more difficult. However,
for gump in its current form, keeping in sync with "the rest of the
world" appears to be manageable by the gump admins.
---
which leads me to believe that the current setup is the best -- we do both:
Put the ASF project descriptors in the gump repo, and put the non-ASF
project descriptors elsewhere, where those projects have the option to
give the dependency magicians (like sam) access to their project descriptor.
---
To solve the centipede problem @ apache: simply make the gump repo a
requirment for building the project! That might also help 'edjucate'
ignorant developers (like, until recently, me) about the wonders and
importance of gump.
If I have to do
cvs co jakarta-avalon jakarta-gump
centipede jakarta-gump/projects/jakarta-avalon.xml
instead of
cvs co jakarta-avalon
centipede jakarta-avalon/project-descriptor.xml
well, I can live with that. And if I can have the commands
cvs co jakarta-avalon
ant jakarta-avalon/build.xml
result in the same thing, what's left to complain about? :D
g'night!
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Christopher Lenz wrote:
>
>> My view is that the Gump descriptors are the base of the daily builds
>> of a project, so that users will be *forced* to maintain most of it,
>> or else the project won't compile.
>
> I agree. For Cactus, we're keeping a pretty damn good eye on the Gump
> results and tend to react to problems very quickly, because we use Gump
> for our nightly builds. I get cold shivers when I see a Cactus build
> soaked in a red background :-)
Gump *heart* Cactus.
- Sam Ruby
P.S. Avalon's nightlies are also built by gump. Didn't work. Any
other suggestions?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Christopher Lenz wrote:
>
>> My view is that the Gump descriptors are the base of the daily builds
>> of a project, so that users will be *forced* to maintain most of it,
>> or else the project won't compile.
>
> I agree. For Cactus, we're keeping a pretty damn good eye on the Gump
> results and tend to react to problems very quickly, because we use Gump
> for our nightly builds. I get cold shivers when I see a Cactus build
> soaked in a red background :-)
Gump *heart* Cactus.
- Sam Ruby
P.S. Avalon's nightlies are also built by gump. Didn't work. Any
other suggestions?
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Nicola Ken Barozzi wrote:
> Sam Ruby wrote:
>> For projects I care about (and that's a *lot* of projects), I want the
>> descriptors to *either* be actively maintained or someplace that
>> bodewig, conor, Stephen, myself, and several others (hi leosimons and
>> mpoeschl and mvdb and cmlenz!) can update.
>
> This is not your requirement, it's a Gump need. It's quite evident to all.
>
> Your way of making Gump runs work is to have a deep knowledge aff all
> Jakarta codebases and fix them yourself.
>
> My view is that the Gump descriptors are the base of the daily builds of
> a project, so that users will be *forced* to maintain most of it, or
> else the project won't compile.
I agree. For Cactus, we're keeping a pretty damn good eye on the Gump
results and tend to react to problems very quickly, because we use Gump
for our nightly builds. I get cold shivers when I see a Cactus build
soaked in a red background :-)
The vast majority of projects doesn't really on Gump for anything,
though, which gets very evident in the universe of Maven built projects,
for example.
I think keeping the Gump descriptor close to the project makes a lot of
sense. But other situations like the recent mass-optionalizing of jaxp
are also a concern. Perhaps, just following the guideline that projects
should be able to maintain their gump descriptor themselves, as long as
they really *care* about the results, is sufficient here.
For now, I'll leave the Cactus descriptor in jakarta-cactus.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Nicola Ken Barozzi wrote:
> Sam Ruby wrote:
>> For projects I care about (and that's a *lot* of projects), I want the
>> descriptors to *either* be actively maintained or someplace that
>> bodewig, conor, Stephen, myself, and several others (hi leosimons and
>> mpoeschl and mvdb and cmlenz!) can update.
>
> This is not your requirement, it's a Gump need. It's quite evident to all.
>
> Your way of making Gump runs work is to have a deep knowledge aff all
> Jakarta codebases and fix them yourself.
>
> My view is that the Gump descriptors are the base of the daily builds of
> a project, so that users will be *forced* to maintain most of it, or
> else the project won't compile.
I agree. For Cactus, we're keeping a pretty damn good eye on the Gump
results and tend to react to problems very quickly, because we use Gump
for our nightly builds. I get cold shivers when I see a Cactus build
soaked in a red background :-)
The vast majority of projects doesn't really on Gump for anything,
though, which gets very evident in the universe of Maven built projects,
for example.
I think keeping the Gump descriptor close to the project makes a lot of
sense. But other situations like the recent mass-optionalizing of jaxp
are also a concern. Perhaps, just following the guideline that projects
should be able to maintain their gump descriptor themselves, as long as
they really *care* about the results, is sufficient here.
For now, I'll leave the Cactus descriptor in jakarta-cactus.
--
Christopher Lenz
/=/ cmlenz at gmx.de
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> My view is that the Gump descriptors are the base of the daily builds of
> a project, so that users will be *forced* to maintain most of it, or
> else the project won't compile.
When was the last time jakarta-avalon-excalibur built? Have any
suggestions on how I *force* Avalon to actually address this? Daily
nags have not been enough. Perhaps I should revoke all karma?
Meanwhile cocoon has not been built because it prereqs excalibur.
> Please take my view in account also, if you want.
> And reply to my implementation proposal now that you made yourself heard.
Remember, I was the one who added the support for people to have the
descriptors whereever they wanted. You put the descriptor where you
want, and keep your project building and Gump is happy.
You ignore daily nags for months on end and Gump gets grumpy.
http://marc.theaimsgroup.com/?t=101775492600002&r=1&w=2
Meanwhile, I see no need for descriptors which are actively maintained
elsewhere to be redundantly committed automatically to the gump
repository. I also have an aversion (from a security perspective) of
automated commits to cvs.
> Note: I had to rewrite this mail three times.
Quite frankly, I would have prefered if the creative energy was directed
at getting excalibur to build. Being able to use gump is not required,
you can reproduce the problem with simply Ant:
http://marc.theaimsgroup.com/?l=avalon-apps-dev&m=103962398723059&w=2
Net-net: keep the builds clean, and keep the descriptors where you want.
Don't pay attention to the builds, and I will find a way to route
around the damage.
Fair enough?
- Sam Ruby
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> My view is that the Gump descriptors are the base of the daily builds of
> a project, so that users will be *forced* to maintain most of it, or
> else the project won't compile.
When was the last time jakarta-avalon-excalibur built? Have any
suggestions on how I *force* Avalon to actually address this? Daily
nags have not been enough. Perhaps I should revoke all karma?
Meanwhile cocoon has not been built because it prereqs excalibur.
> Please take my view in account also, if you want.
> And reply to my implementation proposal now that you made yourself heard.
Remember, I was the one who added the support for people to have the
descriptors whereever they wanted. You put the descriptor where you
want, and keep your project building and Gump is happy.
You ignore daily nags for months on end and Gump gets grumpy.
http://marc.theaimsgroup.com/?t=101775492600002&r=1&w=2
Meanwhile, I see no need for descriptors which are actively maintained
elsewhere to be redundantly committed automatically to the gump
repository. I also have an aversion (from a security perspective) of
automated commits to cvs.
> Note: I had to rewrite this mail three times.
Quite frankly, I would have prefered if the creative energy was directed
at getting excalibur to build. Being able to use gump is not required,
you can reproduce the problem with simply Ant:
http://marc.theaimsgroup.com/?l=avalon-apps-dev&m=103962398723059&w=2
Net-net: keep the builds clean, and keep the descriptors where you want.
Don't pay attention to the builds, and I will find a way to route
around the damage.
Fair enough?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Ok, getting real, what you say and what I say are IMHO both notable
>> features that fill real needs. Needs are never in discord,
>> implemantations are. Let's see how we can fix implementations to make
>> all needs satisfied.
>
> +1
>
>> What about making Gump commit the latest descriptors in its CVS at
>> every run? With the possibility of not-synching for some projects in
>> case ASF developers want to try and fix the Gump version?
>
>
> Let express my root need or requirement, then we can discuss
> implementations.
> For projects I care about (and that's a *lot* of projects), I want the
> descriptors to *either* be actively maintained or someplace that
> bodewig, conor, Stephen, myself, and several others (hi leosimons and
> mpoeschl and mvdb and cmlenz!) can update.
This is not your requirement, it's a Gump need. It's quite evident to all.
Your way of making Gump runs work is to have a deep knowledge aff all
Jakarta codebases and fix them yourself.
My view is that the Gump descriptors are the base of the daily builds of
a project, so that users will be *forced* to maintain most of it, or
else the project won't compile.
These are the two *eithers* that you are talking about.
What we need to discuss is how we can make the second case work and
still have the descriptors in Gump CVS. If you don't think that in this
case it's needed, case solved.
> My creating of a place where all ASF committers can update is one
> possible implementation.
Please take my view in account also, if you want.
And reply to my implementation proposal now that you made yourself heard.
Note: I had to rewrite this mail three times.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Ok, getting real, what you say and what I say are IMHO both notable
>> features that fill real needs. Needs are never in discord,
>> implemantations are. Let's see how we can fix implementations to make
>> all needs satisfied.
>
> +1
>
>> What about making Gump commit the latest descriptors in its CVS at
>> every run? With the possibility of not-synching for some projects in
>> case ASF developers want to try and fix the Gump version?
>
>
> Let express my root need or requirement, then we can discuss
> implementations.
> For projects I care about (and that's a *lot* of projects), I want the
> descriptors to *either* be actively maintained or someplace that
> bodewig, conor, Stephen, myself, and several others (hi leosimons and
> mpoeschl and mvdb and cmlenz!) can update.
This is not your requirement, it's a Gump need. It's quite evident to all.
Your way of making Gump runs work is to have a deep knowledge aff all
Jakarta codebases and fix them yourself.
My view is that the Gump descriptors are the base of the daily builds of
a project, so that users will be *forced* to maintain most of it, or
else the project won't compile.
These are the two *eithers* that you are talking about.
What we need to discuss is how we can make the second case work and
still have the descriptors in Gump CVS. If you don't think that in this
case it's needed, case solved.
> My creating of a place where all ASF committers can update is one
> possible implementation.
Please take my view in account also, if you want.
And reply to my implementation proposal now that you made yourself heard.
Note: I had to rewrite this mail three times.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Leo Simons <le...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>> What about making Gump commit the latest descriptors in its CVS at
>> every run? With the possibility of not-synching for some projects in
>> case ASF developers want to try and fix the Gump version?
>
> Let express my root need or requirement, then we can discuss
> implementations.
>
> My experience is that if descriptors are moved to Avalon, they rot.
yup. Also, I like having the descriptors that gump uses locally as it
makes 'ant gen' run faster, and one can do checking of edits without
having to commit (as it is now, I have to commit the project descriptor
in avalon in order to test it does as it should using gump).
OTOH, if a project descriptor were to actually replace an ant build
file, I really doubt the descriptor would still rot as badly.
> What's worse is that people who care are excluded from making changes.
Which is a thoughtline we could extend to levelling out cvs privs across
the ASF but that's a different argumen t;)
long thought process below (nothing better to do)...
----
I like Seperation of Concerns:
concern 1: building of a software project. You want a way to
automatically build software releases and related materials (website 'n
stuff)
concern 2: testing of a software project. I usually want to do this at
least every hour or so when I'm working on stuff. Avalon has very little
in the way of unittests but for projects at work I often run 'ant test'
using watch, re-running as much as every 5 mins or so.
concern 3: dependency verification for a set of related software
projects. You want to make sure a change in product X doesn't affect
product Y.
concern 4: providing "early access" downloads of development version of
a software project.
(did I get all of em?)
how do these concerns relate?
Well, the first step in testing a project is usually making sure it
builds, ie there's real close coupling between 1 & 2.
The coupling between (1+2) on the one hand and 3 on the other is more
loose: it can be acceptable for a project to work with version y of a
project and then not with version z because of backwards-incompatible
changes, as long as this is a design decision.
The coupling between 4 and 1 is again big: an early acess download
basically is an easily accessible build of the project.
---
The value of ant is that it provides a scripting language for handling
of tasks 1 & 2 (another benefit is that scripting languages are easily
'abused' for other tasks).
The value of gump is that it handles task 3. In doing so, it basically
defers responsibility for task 1 & 2 (which need to be accomplished in
order to do 3) back to ant.
The output of gump automatically results in early access downloads if a
gump run succeeds.
---
The annoying bit is that it is not possible to simply put the data that
gump needs in a form as simple as:
asfRepo="cvs.apache.org:/home/cvspublic";
sfRepo="cvs.sf.net:/home/cvspublic";
...
asfModules="$asfRepo:jakarta-ant $asfRepo:jakarta-avalon
$asfRepo:jakarta-tomcat ...";
...
modules="$asfModules $sfModules ...";
doyourmagicon $modules;
because not every project uses ant, every project that does uses it
slightly differently, it is not so easy to override something defined in
an ant buildfile, and it is not so easy to figure out relationships
between ant buildfiles. Hence the data that must be fed into gump is a
lot more elaborate.
---
So, what's the plan? We replace ant's buildfile by something from which
ant's buildfile is generated (heck, actual use of ant can become
optional!), *and* from which gumps descriptors are also generated. In
fact, it might be possible to generate the ant buildfile by adding just
a little bit of info into the gump descriptor. Tada: centipede!
---
You already knew all this. Now a concern in a different dimension: who
takes care of the various tasks, and how does this fit in with the
technology we use (cvs), and the access control required?
The people that develop the software want to be able to modify their
build script as they modify their software; otherwise testing becomes
problematic.
The people that develop the software apparantly don't care too much for
maintaining the dependency mapping, so you want the people that _do_
care about that to be able to maintain the dependency mappings for them.
When you merge the dependency mapping and the build scripts into a
single file, there's an access priviledge issue: two different groups of
people need access.
---
I see two main options:
1) give the people that develop the software access to the project that
maintains the descriptors (ie give all developers access to gump); give
the people that administer the dependencies access too.
2) give the people that administer the dependencies access to all
software projects.
neither is really satisfactory: giving "all developers" access to gump
would mean wiki-style access control which people are afraid of, whereas
giving the gump admins access to all software is going to affect the
'personal playground feeling and/or software security' of the software
projects.
For apache, the choice is rather easy to make: we generally trust all
asf committers to behave, and hence opening up the gump repo should not
present a problem. With the modest size of the new repo, it is also not
a big burden to keep a local copy of the gump repo updated. Once you
adjust to the idea "the project descriptor is in a different cvs",
there's virtually no difference.
Taking into account the rest of the world is more difficult. However,
for gump in its current form, keeping in sync with "the rest of the
world" appears to be manageable by the gump admins.
---
which leads me to believe that the current setup is the best -- we do both:
Put the ASF project descriptors in the gump repo, and put the non-ASF
project descriptors elsewhere, where those projects have the option to
give the dependency magicians (like sam) access to their project descriptor.
---
To solve the centipede problem @ apache: simply make the gump repo a
requirment for building the project! That might also help 'edjucate'
ignorant developers (like, until recently, me) about the wonders and
importance of gump.
If I have to do
cvs co jakarta-avalon jakarta-gump
centipede jakarta-gump/projects/jakarta-avalon.xml
instead of
cvs co jakarta-avalon
centipede jakarta-avalon/project-descriptor.xml
well, I can live with that. And if I can have the commands
cvs co jakarta-avalon
ant jakarta-avalon/build.xml
result in the same thing, what's left to complain about? :D
g'night!
- Leo
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Ok, getting real, what you say and what I say are IMHO both notable
> features that fill real needs. Needs are never in discord,
> implamantations are. Let's see how we can fix implementations to make
> all needs satisfied.
+1
> What about making Gump commit the latest descriptors in its CVS at every
> run? With the possibility of not-synching for some projects in case ASF
> developers want to try and fix the Gump version?
Let express my root need or requirement, then we can discuss
implementations.
My experience is that if descriptors are moved to Avalon, they rot.
What's worse is that people who care are excluded from making changes.
For projects I care about (and that's a *lot* of projects), I want the
descriptors to *either* be actively maintained or someplace that
bodewig, conor, Stephen, myself, and several others (hi leosimons and
mpoeschl and mvdb and cmlenz!) can update.
My creating of a place where all ASF committers can update is one
possible implementation.
- Sam Ruby
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Ok, getting real, what you say and what I say are IMHO both notable
> features that fill real needs. Needs are never in discord,
> implamantations are. Let's see how we can fix implementations to make
> all needs satisfied.
+1
> What about making Gump commit the latest descriptors in its CVS at every
> run? With the possibility of not-synching for some projects in case ASF
> developers want to try and fix the Gump version?
Let express my root need or requirement, then we can discuss
implementations.
My experience is that if descriptors are moved to Avalon, they rot.
What's worse is that people who care are excluded from making changes.
For projects I care about (and that's a *lot* of projects), I want the
descriptors to *either* be actively maintained or someplace that
bodewig, conor, Stephen, myself, and several others (hi leosimons and
mpoeschl and mvdb and cmlenz!) can update.
My creating of a place where all ASF committers can update is one
possible implementation.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Sam Ruby wrote:
>>
>>> Nicola Ken Barozzi wrote:
>>>
>>>> Centipede projects use the descriptor to run normal builds, so they
>>>> will not move.
>>>
>>> Gump can follow hrefs, why can't centipede?
>>
>> 1) I don't want my machine to be connnected to the internet
>> just to build my project. Gump downloads every run so it's not
>> an issue.
>
> What could be better than to have a single place which you can check out
> all descriptors? Imagine all the cross project information you could
> generate offline...
What could be better than have the descriptor in synch and close to the
actual codebase? Don't just assume that Gump is the center of the
universe. :-P
Ok, getting real, what you say and what I say are IMHO both notable
features that fill real needs. Needs are never in discord,
implamantations are. Let's see how we can fix implementations to make
all needs satisfied.
>> 2) Gump has a profile, Centipede just looks at the descriptor
>> in the project dir.
>
> Perhaps Centipede could have an option / profile / properties file that
> indicates where you have a locally checked out jakarta-gump/project
> directory, and will look in there if the descriptor is not found locally?
Yes, it's not a bad idea. I had started doing it but it was too early,
we needed to do other things first. We are now working on a Gump
integration that would make Centipede spit out a correct profile to
build local projects and use Gump for that.
But I do still strongly think that a descriptor of a project should
remain with the project. Or you want me to put all buildfiles in Gump
too? ;-P
Ok, getting real again: think about a Centipede user that wants to build
a project. Hmmm, let me try and see it from a Gump perspective. It
downloads Gump, and Gump has the descriptor. Then it tells Gump to
download the project from CVS. Ok, so far it's cool. Then it builds it
and Centipede looks in Gump to find the descriptor. Cool again.
Ok, I like this. But let's see the drawbacks:
- the project descriptor is not with the project itself. It's in
another dir. Imagine the buildfile be in another dir... hmmm, not nice IMHO.
- a project is on SF and needs to change the descriptor. They need to
ask Gump committers to do it. Your vision is ok till we talk about
Apache projects, but is not so nice (it seems) for others.
- Some projects don't want to Gump, so their descriptors are local in
the project dir, not Gump's. So we have some projects with the decriptor
near, some in Gump. Hmmm...
It seems we need some kind of synching here...
Suppose Gump keeps the descriptors. It's mandated by the fact that we
use Gump to bootstrap other projects by downloading them.
But then, I want the descriptor with the project. So the developers can
use them *near* the code, and change them as needed.
So...
What about making Gump commit the latest descriptors in its CVS at every
run? With the possibility of not-synching for some projects in case ASF
developers want to try and fix the Gump version?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Sam Ruby wrote:
>>
>>> Nicola Ken Barozzi wrote:
>>>
>>>> Centipede projects use the descriptor to run normal builds, so they
>>>> will not move.
>>>
>>> Gump can follow hrefs, why can't centipede?
>>
>> 1) I don't want my machine to be connnected to the internet
>> just to build my project. Gump downloads every run so it's not
>> an issue.
>
> What could be better than to have a single place which you can check out
> all descriptors? Imagine all the cross project information you could
> generate offline...
What could be better than have the descriptor in synch and close to the
actual codebase? Don't just assume that Gump is the center of the
universe. :-P
Ok, getting real, what you say and what I say are IMHO both notable
features that fill real needs. Needs are never in discord,
implamantations are. Let's see how we can fix implementations to make
all needs satisfied.
>> 2) Gump has a profile, Centipede just looks at the descriptor
>> in the project dir.
>
> Perhaps Centipede could have an option / profile / properties file that
> indicates where you have a locally checked out jakarta-gump/project
> directory, and will look in there if the descriptor is not found locally?
Yes, it's not a bad idea. I had started doing it but it was too early,
we needed to do other things first. We are now working on a Gump
integration that would make Centipede spit out a correct profile to
build local projects and use Gump for that.
But I do still strongly think that a descriptor of a project should
remain with the project. Or you want me to put all buildfiles in Gump
too? ;-P
Ok, getting real again: think about a Centipede user that wants to build
a project. Hmmm, let me try and see it from a Gump perspective. It
downloads Gump, and Gump has the descriptor. Then it tells Gump to
download the project from CVS. Ok, so far it's cool. Then it builds it
and Centipede looks in Gump to find the descriptor. Cool again.
Ok, I like this. But let's see the drawbacks:
- the project descriptor is not with the project itself. It's in
another dir. Imagine the buildfile be in another dir... hmmm, not nice IMHO.
- a project is on SF and needs to change the descriptor. They need to
ask Gump committers to do it. Your vision is ok till we talk about
Apache projects, but is not so nice (it seems) for others.
- Some projects don't want to Gump, so their descriptors are local in
the project dir, not Gump's. So we have some projects with the decriptor
near, some in Gump. Hmmm...
It seems we need some kind of synching here...
Suppose Gump keeps the descriptors. It's mandated by the fact that we
use Gump to bootstrap other projects by downloading them.
But then, I want the descriptor with the project. So the developers can
use them *near* the code, and change them as needed.
So...
What about making Gump commit the latest descriptors in its CVS at every
run? With the possibility of not-synching for some projects in case ASF
developers want to try and fix the Gump version?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Sam Ruby wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> Centipede projects use the descriptor to run normal builds, so they
>>> will not move.
>>
>> Gump can follow hrefs, why can't centipede?
>
> 1) I don't want my machine to be connnected to the internet
> just to build my project. Gump downloads every run so it's not
> an issue.
What could be better than to have a single place which you can check out
all descriptors? Imagine all the cross project information you could
generate offline...
> 2) Gump has a profile, Centipede just looks at the descriptor
> in the project dir.
Perhaps Centipede could have an option / profile / properties file that
indicates where you have a locally checked out jakarta-gump/project
directory, and will look in there if the descriptor is not found locally?
> 3) Do you really mean it? :-P
Yes.
>> - Sam Ruby
>>
>> P.S. krysalis-centipede/module.xml is not well formed XML
>>
>> http://cvs.apache.org/builds/gump/2003-01-05/gump.html
>
>
> Nick made a change yesterday, I've corrected it now.
Thanks!
- Sam Ruby
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Sam Ruby wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> Centipede projects use the descriptor to run normal builds, so they
>>> will not move.
>>
>> Gump can follow hrefs, why can't centipede?
>
> 1) I don't want my machine to be connnected to the internet
> just to build my project. Gump downloads every run so it's not
> an issue.
What could be better than to have a single place which you can check out
all descriptors? Imagine all the cross project information you could
generate offline...
> 2) Gump has a profile, Centipede just looks at the descriptor
> in the project dir.
Perhaps Centipede could have an option / profile / properties file that
indicates where you have a locally checked out jakarta-gump/project
directory, and will look in there if the descriptor is not found locally?
> 3) Do you really mean it? :-P
Yes.
>> - Sam Ruby
>>
>> P.S. krysalis-centipede/module.xml is not well formed XML
>>
>> http://cvs.apache.org/builds/gump/2003-01-05/gump.html
>
>
> Nick made a change yesterday, I've corrected it now.
Thanks!
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Centipede projects use the descriptor to run normal builds, so they
>> will not move.
>
> Gump can follow hrefs, why can't centipede?
1) I don't want my machine to be connnected to the internet
just to build my project. Gump downloads every run so it's not
an issue.
2) Gump has a profile, Centipede just looks at the descriptor
in the project dir.
3) Do you really mean it? :-P
> - Sam Ruby
>
> P.S. krysalis-centipede/module.xml is not well formed XML
>
> http://cvs.apache.org/builds/gump/2003-01-05/gump.html
Nick made a change yesterday, I've corrected it now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Centipede projects use the descriptor to run normal builds, so they
>> will not move.
>
> Gump can follow hrefs, why can't centipede?
1) I don't want my machine to be connnected to the internet
just to build my project. Gump downloads every run so it's not
an issue.
2) Gump has a profile, Centipede just looks at the descriptor
in the project dir.
3) Do you really mean it? :-P
> - Sam Ruby
>
> P.S. krysalis-centipede/module.xml is not well formed XML
>
> http://cvs.apache.org/builds/gump/2003-01-05/gump.html
Nick made a change yesterday, I've corrected it now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Centipede projects use the descriptor to run normal builds, so they will
> not move.
Gump can follow hrefs, why can't centipede?
- Sam Ruby
P.S. krysalis-centipede/module.xml is not well formed XML
http://cvs.apache.org/builds/gump/2003-01-05/gump.html
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Centipede projects use the descriptor to run normal builds, so they will
> not move.
Gump can follow hrefs, why can't centipede?
- Sam Ruby
P.S. krysalis-centipede/module.xml is not well formed XML
http://cvs.apache.org/builds/gump/2003-01-05/gump.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Christopher Lenz wrote:
>
>>
>>> BTW, no that the descriptors in the Gump module are accessible to all
>>
>>
>> s/no/now
>>
>>> Jakarta (Apache?) committers, would it be recommended to move
>>> descriptors that have been put in the project's CVS (Cactus or
>>> Tomcat, for example) back into jakarta-gump ?
>
>
> That would be my recommendation. Why not start with cactus?
Centipede projects use the descriptor to run normal builds, so they will
not move.
I think that having descriptors away from where they belong kinda sucks,
just like having documentation out of the project CVS repository.
If a project doesn't compile with Gump, IMHO it's correct to simply
overrule the remote version and work on a Gump version in the Gump repo.
No need to move, just use another one. But if the project is capable of
managing it, I repeat /if/, it's better that he keeps it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Christopher Lenz wrote:
>
>>
>>> BTW, no that the descriptors in the Gump module are accessible to all
>>
>>
>> s/no/now
>>
>>> Jakarta (Apache?) committers, would it be recommended to move
>>> descriptors that have been put in the project's CVS (Cactus or
>>> Tomcat, for example) back into jakarta-gump ?
>
>
> That would be my recommendation. Why not start with cactus?
Centipede projects use the descriptor to run normal builds, so they will
not move.
I think that having descriptors away from where they belong kinda sucks,
just like having documentation out of the project CVS repository.
If a project doesn't compile with Gump, IMHO it's correct to simply
overrule the remote version and work on a Gump version in the Gump repo.
No need to move, just use another one. But if the project is capable of
managing it, I repeat /if/, it's better that he keeps it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@intertwingly.net>.
Christopher Lenz wrote:
>
>> BTW, no that the descriptors in the Gump module are accessible to all
>
> s/no/now
>
>> Jakarta (Apache?) committers, would it be recommended to move
>> descriptors that have been put in the project's CVS (Cactus or Tomcat,
>> for example) back into jakarta-gump ?
That would be my recommendation. Why not start with cactus?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@intertwingly.net>.
Christopher Lenz wrote:
>
>> BTW, no that the descriptors in the Gump module are accessible to all
>
> s/no/now
>
>> Jakarta (Apache?) committers, would it be recommended to move
>> descriptors that have been put in the project's CVS (Cactus or Tomcat,
>> for example) back into jakarta-gump ?
That would be my recommendation. Why not start with cactus?
- Sam Ruby
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Christopher Lenz wrote:
> Conor MacNeill wrote:
>
>> conor@apache.org wrote:
>>
>>> conor 2003/01/05 05:33:07
>>>
>>> Modified: project jakarta-ant.xml jakarta-commons.xml
>>> jakarta-taglibs.xml uddi4j.xml xml-crimson.xml
>>> xml-xerces.xml
>>> Log:
>>> First pass at making jaxp and jsse optional so that packages are
>>> not required
>>> under jdk 1.4
>>>
>>
>>
>>
>> This is looking OK on my current run but I was unable to update the
>> tomcat descriptors? Anyone have access?
>
>
> BTW, no that the descriptors in the Gump module are accessible to all
s/no/now
> Jakarta (Apache?) committers, would it be recommended to move
> descriptors that have been put in the project's CVS (Cactus or Tomcat,
> for example) back into jakarta-gump ?
--
Christopher Lenz
/=/ cmlenz at gmx.de
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Christopher Lenz wrote:
> Conor MacNeill wrote:
>
>> conor@apache.org wrote:
>>
>>> conor 2003/01/05 05:33:07
>>>
>>> Modified: project jakarta-ant.xml jakarta-commons.xml
>>> jakarta-taglibs.xml uddi4j.xml xml-crimson.xml
>>> xml-xerces.xml
>>> Log:
>>> First pass at making jaxp and jsse optional so that packages are
>>> not required
>>> under jdk 1.4
>>>
>>
>>
>>
>> This is looking OK on my current run but I was unable to update the
>> tomcat descriptors? Anyone have access?
>
>
> BTW, no that the descriptors in the Gump module are accessible to all
s/no/now
> Jakarta (Apache?) committers, would it be recommended to move
> descriptors that have been put in the project's CVS (Cactus or Tomcat,
> for example) back into jakarta-gump ?
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Conor MacNeill wrote:
> conor@apache.org wrote:
>
>> conor 2003/01/05 05:33:07
>>
>> Modified: project jakarta-ant.xml jakarta-commons.xml
>> jakarta-taglibs.xml uddi4j.xml xml-crimson.xml
>> xml-xerces.xml
>> Log:
>> First pass at making jaxp and jsse optional so that packages are not
>> required
>> under jdk 1.4
>>
>
>
> This is looking OK on my current run but I was unable to update the
> tomcat descriptors? Anyone have access?
BTW, no that the descriptors in the Gump module are accessible to all
Jakarta (Apache?) committers, would it be recommended to move
descriptors that have been put in the project's CVS (Cactus or Tomcat,
for example) back into jakarta-gump ?
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Conor MacNeill wrote:
> conor@apache.org wrote:
>
>> conor 2003/01/05 05:33:07
>>
>> Modified: project jakarta-ant.xml jakarta-commons.xml
>> jakarta-taglibs.xml uddi4j.xml xml-crimson.xml
>> xml-xerces.xml
>> Log:
>> First pass at making jaxp and jsse optional so that packages are not
>> required
>> under jdk 1.4
>>
>
>
> This is looking OK on my current run but I was unable to update the
> tomcat descriptors? Anyone have access?
BTW, no that the descriptors in the Gump module are accessible to all
Jakarta (Apache?) committers, would it be recommended to move
descriptors that have been put in the project's CVS (Cactus or Tomcat,
for example) back into jakarta-gump ?
--
Christopher Lenz
/=/ cmlenz at gmx.de
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Conor MacNeill wrote:
>
> This is looking OK on my current run but I was unable to update the
> tomcat descriptors? Anyone have access?
Submit a patch, I'll commit it.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
conor@apache.org wrote:
> conor 2003/01/05 05:33:07
>
> Modified: project jakarta-ant.xml jakarta-commons.xml
> jakarta-taglibs.xml uddi4j.xml xml-crimson.xml
> xml-xerces.xml
> Log:
> First pass at making jaxp and jsse optional so that packages are not required
> under jdk 1.4
>
This is looking OK on my current run but I was unable to update the tomcat
descriptors? Anyone have access?
I'll document these changes after I look at the next official run.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
conor@apache.org wrote:
> conor 2003/01/05 05:33:07
>
> Modified: project jakarta-ant.xml jakarta-commons.xml
> jakarta-taglibs.xml uddi4j.xml xml-crimson.xml
> xml-xerces.xml
> Log:
> First pass at making jaxp and jsse optional so that packages are not required
> under jdk 1.4
>
This is looking OK on my current run but I was unable to update the tomcat
descriptors? Anyone have access?
I'll document these changes after I look at the next official run.
Conor