You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Leo Simons <le...@apache.org> on 2003/01/21 10:31:53 UTC
replacing a build dependency system with gump
Hi gang,
I've been experimenting with removing the Avalon-Excalibur ant-based
dependency mechanism, and instead relying on gump to track the
dependencies. This turns out to be pretty easy to do, but it leads to a
dilemma: while I want my nightly builds to be done using
the-latest-of-everything, I want my releases to be done using
the-latest-release-of-everything.
This is also easily solved. You need 2 project/profile definition sets,
where the new set is definitions where the-latest-release-of-everything
is defined just like all the other binary packages. Downloading and
installing the latest-release-of-everything prior to building can be
rather painful in the java world (it's not like there's .deb files for
each project), which is of course why the maven peeps are setting up
http://www.ibiblio.org/maven/.
I'm wondering where to go next. Would it be a good idea to copy some of
maven's auto-get-this-jar-from-repo functionality to gump, or should
gump remain purely focused on integration builds?
thoughts?
cheers,
- Leo
Re: replacing a build dependency system with gump
Posted by Sam Ruby <ru...@apache.org>.
Nick Chalko wrote:
>
> Normally gen.sh would say something like
> project foo dropped beacuse dependent project bar not found.
>
> gen.sh --downloadNotDrop
> would instead say
> project bar added to list of download jars.
>
> And then use reperDepend to get the latets jars for all "not found"
> projects.
I misunderstood the first time. Now I get it. If all downloads are at
gen time and only for projects which do not have build instructions in
the scope of the workspace, then +1 from me.
- Sam Ruby
Re: replacing a build dependency system with gump
Posted by Nick Chalko <ni...@chalko.com>.
Sam Ruby wrote:
> Nick Chalko wrote:
>
>>
>>> As to your specific proposal, I'm concerned about co-evolution.
>>> Suppose a new Jelly tag requires something to be added to the core
>>> of Jelly. Since this tag will either be released concurrently with,
>>> or after Jelly is, this is not a problem. However, suppose one day
>>> somebody forgets a semicolon in a commit to Jelly...
>>
>>
>> My proposal would be option say gen.sh --downloadNotDrop That way
>> people can use gump on whatever subset they want
>
>
> If I understand the proposal, the hypothetical tag would compile clean
> for a period of time, except when the jelly core failed to compile, at
> which point an old version of jelly would be downloaded and the taglib
> compile would fail.
>
> I don't object to the proposal, but in my mind there is a differnce
> between not having downloaded cryptix and jelly failing to compile.
>
> FYI: quite a ways back, Geir had a suggestion for the latter scenario.
> The suggesion was that gump save the jars from prior runs and use them
> instead. In many ways, this is mostly implemented... there is a
> jardir attribute on the workspace, and the dependency checking logic
> simply checks for existence of the jars, not their dates.
My idea was on downloading project not in the workspace.
For example
<project name="foo" />
<depend project="log4j" />
<depend project="bar" repository="maven"/>
</project>
Normally gen.sh would say something like
project foo dropped beacuse dependent project bar not found.
gen.sh --downloadNotDrop
would instead say
project bar added to list of download jars.
And then use reperDepend to get the latets jars for all "not found"
projects.
>
> - Sam Ruby
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
Re: replacing a build dependency system with gump
Posted by Sam Ruby <ru...@apache.org>.
Nick Chalko wrote:
>
>> As to your specific proposal, I'm concerned about co-evolution.
>> Suppose a new Jelly tag requires something to be added to the core of
>> Jelly. Since this tag will either be released concurrently with, or
>> after Jelly is, this is not a problem. However, suppose one day
>> somebody forgets a semicolon in a commit to Jelly...
>
> My proposal would be option say gen.sh --downloadNotDrop
> That way people can use gump on whatever subset they want
If I understand the proposal, the hypothetical tag would compile clean
for a period of time, except when the jelly core failed to compile, at
which point an old version of jelly would be downloaded and the taglib
compile would fail.
I don't object to the proposal, but in my mind there is a differnce
between not having downloaded cryptix and jelly failing to compile.
FYI: quite a ways back, Geir had a suggestion for the latter scenario.
The suggesion was that gump save the jars from prior runs and use them
instead. In many ways, this is mostly implemented... there is a jardir
attribute on the workspace, and the dependency checking logic simply
checks for existence of the jars, not their dates.
- Sam Ruby
Re: replacing a build dependency system with gump
Posted by Nick Chalko <ni...@chalko.com>.
Sam Ruby wrote:
> Nick Chalko wrote:
>
>>
>> The idea I was toying with was
>>
>> changing the "drop project becuse missing dependency foo" step of
>> gump to be "adding project foo, to the list of downloads" and then
>> have ruper grab all the files and place them in the "packages dir".
>>
>> see http://krysalis.org/cgi-bin/krywiki.pl?RuperDependTask
>
>
> Can Ruper be bootstrapped? Would the authors of Ruper consider
> donating this code to the ASF?
Ruper is a Krysalis project, David Bernard <dw...@java-fan.com> wrote
the code and Nicola and I extended.
Donating the ASF is fine with me, but I know it needs more work and
would like to be involved.
>
> Both of the above are simply questions - not prerequisites.
>
> As to your specific proposal, I'm concerned about co-evolution.
> Suppose a new Jelly tag requires something to be added to the core of
> Jelly. Since this tag will either be released concurrently with, or
> after Jelly is, this is not a problem. However, suppose one day
> somebody forgets a semicolon in a commit to Jelly...
My proposal would be option say gen.sh --downloadNotDrop
That way people can use gump on whatever subset they want
>
> - Sam Ruby
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
Re: replacing a build dependency system with gump
Posted by Sam Ruby <ru...@apache.org>.
Nick Chalko wrote:
>
> The idea I was toying with was
>
> changing the "drop project becuse missing dependency foo" step of
> gump to be "adding project foo, to the list of downloads" and then
> have ruper grab all the files and place them in the "packages dir".
>
> see http://krysalis.org/cgi-bin/krywiki.pl?RuperDependTask
Can Ruper be bootstrapped? Would the authors of Ruper consider donating
this code to the ASF?
Both of the above are simply questions - not prerequisites.
As to your specific proposal, I'm concerned about co-evolution. Suppose
a new Jelly tag requires something to be added to the core of Jelly.
Since this tag will either be released concurrently with, or after Jelly
is, this is not a problem. However, suppose one day somebody forgets a
semicolon in a commit to Jelly...
- Sam Ruby
Re: replacing a build dependency system with gump
Posted by Nick Chalko <ni...@chalko.com>.
Sam Ruby wrote:
> Leo Simons wrote:
>
>>
>> I'm wondering where to go next. Would it be a good idea to copy some
>> of maven's auto-get-this-jar-from-repo functionality to gump, or
>> should gump remain purely focused on integration builds?
>
>
> Being able to get a jar would be very helpful for retrieving the
> redistributable components of
> http://cvs.apache.org/builds/gump/latest/packages.html. My only
> concern is that I don't want the people who are creating a project to
> be able to dictate the versions of the dependencies used. They should
> get the first say, of course, but the person doing the integration
> should get the final say.
The idea I was toying with was
changing the "drop project becuse missing dependency foo" step of
gump to be "adding project foo, to the list of downloads" and then
have ruper grab all the files and place them in the "packages dir".
see http://krysalis.org/cgi-bin/krywiki.pl?RuperDependTask
<ruperDepend>
has gump <depend> tasks as nested elements, the only addition is a
"repository" element so ruper knows where to look for the jar at and a
optional "version" attribute..
Ruper is pretty good at handling different versions.
The ruperDepend code is working and tested
see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/krysalis/krysalis-ant-tasks/src/test/org/krysalis/ant/taskdefs/RuperDependTaskTest.java?rev=HEAD&content-type=text/vnd.viewcvs-markup
.
Although it still fails in centipede because the Ant Reference to the
generated path, is not available outside of the getcorelibs import.
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
Re: replacing a build dependency system with gump
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
>
> I'm wondering where to go next. Would it be a good idea to copy some of
> maven's auto-get-this-jar-from-repo functionality to gump, or should
> gump remain purely focused on integration builds?
Being able to get a jar would be very helpful for retrieving the
redistributable components of
http://cvs.apache.org/builds/gump/latest/packages.html. My only concern
is that I don't want the people who are creating a project to be able to
dictate the versions of the dependencies used. They should get the
first say, of course, but the person doing the integration should get
the final say.
- Sam Ruby
Re: replacing a build dependency system with gump
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> I browsed around my centipede beta4 install (which is just sitting on
> disk doing nothing atm) and the website, and I can't really figure out
> where to start. Where do I look?
In CVS ATM. We are finishing the "depchecker" now, so you may use it soon.
All other features work well.
> I have:
> - working and configured ant 1.5.1 install (C:\Progam Files\Apache
> Group\Ant\)
> - full, working, up2date and configured local gump install (C:\gump\)
> with checkouts of all projects it manages
> - working centipede beta4 install( C:\Progam Files\Krysalis\centipede\)
> - working forrest 0.2.1 install (C:\Progam Files\Apache Group\Forrest\)
> - working maven beta7 install (C:\Progam Files\Apache Group\Maven\)
> - working latest full cygwin (C:\cygwin\)
> - paths and variables all setup correctly
>
> What I want is to:
> - set up a neat alternative to the depchecker.xml script & friends in
> jakarta-avalon-excalibur using one or more of these tools, so I can
> a) do test integration builds (already there)
> b) do release builds (not there yet)
> - then make this as easy as possible and document the process so others
> can do the same thing (todo)
My suggestion (of course) is to wait for a couple of days for the
"depchecker" to be finished, and try a centipede build on the project.
I will send you a centipede buildfile to make you test.
> - reduce the buildfiles in the avalon project and my own software
> projects to the minimum size and number possible (todo)
> - automate (todo)
Yes.
> - reduce the number of bullets in the list above (ie the build prereqs)
> to none, allowing something like
>
> `links -source http://www.buildme.org/go.sh | bash; build-project`
>
> with minimal download time, minimal running time, and with minimal
> expenditure of energy on my part. (probably not happening soon)
It has been proposed, it's in the todo list.
> Nicola Ken Barozzi wrote:
>
>>> I've been experimenting with removing the Avalon-Excalibur ant-based
>>> dependency mechanism, and instead relying on gump to track the
>>> dependencies. This turns out to be pretty easy to do, but it leads to
>>> a dilemma: while I want my nightly builds to be done using
>>> the-latest-of-everything, I want my releases to be done using
>>> the-latest-release-of-everything.
>>
>> Centipede uses the Gump descriptors to do it.
>
> cool.
>
>> IMHO Gump should remain about integration builds, and Centipede used
>> to build a single module. But this is just MHO.
>
> In my even more humble, mostly uninformed, and moreover mostly pointless
> because not actually helping much opinion, ant2 should be based around
> jelly, then maven and centipede refactored and merged, then gump reduced
> to a GUI/CUI, a script or two, and some xml files layered on top of that.
Been there, done that, failed.
Ant2 is progressing nicely by itself, Maven and Centipede will not merge
soon given that my proposal about that has been rejected hard, and the
Gump xml file as a standard has been embraced only by Centipede.
Anyway, the above "MHO" is not about theory but practice. It's based on
my concrete experiments with Gump and simple Ant buildfiles about this.
It's all what Centipede is about.
> Disregarding MHO, I'm right now just looking for the simplest thing that
> will possibly work :D
Yup.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: replacing a build dependency system with gump
Posted by Leo Simons <le...@apache.org>.
I browsed around my centipede beta4 install (which is just sitting on
disk doing nothing atm) and the website, and I can't really figure out
where to start. Where do I look?
I have:
- working and configured ant 1.5.1 install (C:\Progam Files\Apache
Group\Ant\)
- full, working, up2date and configured local gump install (C:\gump\)
with checkouts of all projects it manages
- working centipede beta4 install( C:\Progam Files\Krysalis\centipede\)
- working forrest 0.2.1 install (C:\Progam Files\Apache Group\Forrest\)
- working maven beta7 install (C:\Progam Files\Apache Group\Maven\)
- working latest full cygwin (C:\cygwin\)
- paths and variables all setup correctly
What I want is to:
- set up a neat alternative to the depchecker.xml script & friends in
jakarta-avalon-excalibur using one or more of these tools, so I can
a) do test integration builds (already there)
b) do release builds (not there yet)
- then make this as easy as possible and document the process so others
can do the same thing (todo)
- reduce the buildfiles in the avalon project and my own software
projects to the minimum size and number possible (todo)
- automate (todo)
- reduce the number of bullets in the list above (ie the build prereqs)
to none, allowing something like
`links -source http://www.buildme.org/go.sh | bash; build-project`
with minimal download time, minimal running time, and with minimal
expenditure of energy on my part. (probably not happening soon)
Nicola Ken Barozzi wrote:
>> I've been experimenting with removing the Avalon-Excalibur ant-based
>> dependency mechanism, and instead relying on gump to track the
>> dependencies. This turns out to be pretty easy to do, but it leads to
>> a dilemma: while I want my nightly builds to be done using
>> the-latest-of-everything, I want my releases to be done using
>> the-latest-release-of-everything.
>
> Centipede uses the Gump descriptors to do it.
cool.
> IMHO Gump should remain about integration builds, and Centipede used to
> build a single module. But this is just MHO.
In my even more humble, mostly uninformed, and moreover mostly pointless
because not actually helping much opinion, ant2 should be based around
jelly, then maven and centipede refactored and merged, then gump reduced
to a GUI/CUI, a script or two, and some xml files layered on top of that.
Disregarding MHO, I'm right now just looking for the simplest thing that
will possibly work :D
cheers,
- Leo
Re: replacing a build dependency system with gump
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Hi gang,
>
> I've been experimenting with removing the Avalon-Excalibur ant-based
> dependency mechanism, and instead relying on gump to track the
> dependencies. This turns out to be pretty easy to do, but it leads to a
> dilemma: while I want my nightly builds to be done using
> the-latest-of-everything, I want my releases to be done using
> the-latest-release-of-everything.
Centipede uses the Gump descriptors to do it.
Centipede uses Krysalis Ruper, that's an Ant task that gets packages
from remote repositories. ATM we are using also the MAven repository on
ibiblio to minimize duplication.
Basically it checks the dependencies: if a version info is there, it
uses that jar; if there is no info it gets the latest jar, unless the
project is defined in the descriptor; in this case, it uses the compiled
version by resolving compilation dependencies.
Centipede was made with this idea in mind.
> This is also easily solved. You need 2 project/profile definition sets,
> where the new set is definitions where the-latest-release-of-everything
> is defined just like all the other binary packages. Downloading and
> installing the latest-release-of-everything prior to building can be
> rather painful in the java world (it's not like there's .deb files for
> each project), which is of course why the maven peeps are setting up
> http://www.ibiblio.org/maven/.
>
> I'm wondering where to go next. Would it be a good idea to copy some of
> maven's auto-get-this-jar-from-repo functionality to gump, or should
> gump remain purely focused on integration builds?
If you want to go the Gump-only way, you can use the RuperTask to
download that latest jars, set them in the classpath, and run Gump.
IMHO Gump should remain about integration builds, and Centipede used to
build a single module. But this is just MHO.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------