You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Andrew C. Oliver" <ac...@apache.org> on 2003/01/10 18:22:49 UTC
gump issues under winblows and a suggestion...
So Getting gump to run under Windows is not particularly fun. (Don't
ask, my hands are tied).
Installing Cygwin helps. I had a lot of trouble figuring out what the
issues were with the batch files.
I've come to the conclusion that I don't much care for the approach with
the shell scripts (just because it seems to be a pain and gives horrible
feedback when somethings wrong).
I'm curious if it has been suggested before....
Ant files are XML and transforming to them seems to be more natural.
Ant isn't the most kind thing in the world for its "Hey this crap broke"
messages, but it is FAR better than cmd.exe or bash in this respect.
By creating what I imagine would be relatively few additional ant
tasks.. Could this not achieve the same effect while making
multiplatform support several degrees less painful?
I understand gump is striving to be language and language-platform
independant, but I don't see a problem with this, gump requires a VM as
it is, using Ant shouldn't be that big of a deal I wouldn't think.
Anyhow, I'm just curious what problems there are with this approach. As
my level of pain increases I'll probably experiment with this, but I'm
curious if others have thought of this and what the downsides are...
Thanks for your input,
-Me
Re: gump issues under winblows and a suggestion...
Posted by Sam Ruby <ru...@apache.org>.
Andrew C. Oliver wrote:
>
> 2. It is apparently possible/easy to supply unix commands in the gump
> descriptors... this is a bit of a problem..
The workspace synch attribute is optional - remove it on Windows. I do.
This was virtually required to get anything near tolerable on Slowaris.
It makes an improvement on Linux. I haven't figured out how to get it
to work on Windows - nor is it particularly necessary there.
> 3. I had to run under cygwin...but edit the batch files directly and fix
> the paths. . Not just because of an rsync being called in a descriptor
> for centipede, but I don't think I was getting that far.. .
If you remove the rsync stuff and still have a problem, let me know
where the problem is and I'll fix the stylesheet used to generate the
shell script.
- Sam Ruby
Re: gump issues under winblows and a suggestion...
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Thanks sam. I figured it was something like that (boot classpaths etc)
>
> All presented merely as food for thought. They reasons may or may not
> be applicable to you. But there is no reason why Gump can't support
> multiple targets - it already does so with bash and win2k.
>
> - Sam Ruby
Issues with Win2k:
1. I found it very difficult to set up... I'm there (I think) but I
don't know how I got here or how I could get back :-).. I had to run
under cygwin. I think a large part due to crummy error reporting (which
isn't in Gumps control) in the batch files. I'm not entirely sure why
everything that wasn't working -- wasn't working....but it definitely
wasn't.. ;-)
2. It is apparently possible/easy to supply unix commands in the gump
descriptors... this is a bit of a problem..
3. I had to run under cygwin...but edit the batch files directly and fix
the paths. . Not just because of an rsync being called in a descriptor
for centipede, but I don't think I was getting that far.. .
(I meant to upload my set up but Time Warner saw fit to disconnect my
cable modem service for the better part of the other day)
I think I'm there.. Just need to ask nick a few centipede questions...
then I'll see if I can't do something about the path translation under
cygwin which I imagine if I can get that to work would be more stable
anyhow.. (until someone sticks windows commands in their descriptors :-O
- hence the problem with more widespread use...increased likelyhood of
that happening)
-Andy
Re: gump issues under winblows and a suggestion...
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 10 Jan 2003, Sam Ruby <ru...@apache.org> wrote:
> * Leaky abstractions.
This and all your other concerns could be addresses by invoking the
individual builds via <java fork="true"/> instead of <ant>. You get
access to the bootclasspath, you can chose the VM executable and so
on.
At least so it seems.
Stefan
Re: gump issues under winblows and a suggestion...
Posted by "Andrew C. Oliver" <ac...@apache.org>.
I did that too. Turning off McAffee helped.
Unfortuantely all the logon scripts and everything is set up to
install/enable/etc it.. I'm going to have to get a lot more tricky!
-Andy
dion@multitask.com.au wrote:
> I did a defrag before my tests, so that's not it.
>
> I'm currently running a test to see that if it's AntiVirus software. In my
> preliminary tests, turning it off momentarily made the process a lot
> quicker.
>
> I'll report back when I've got some real evidence :)
> --
> dIon Gillard, Multitask Consulting
> Blog: http://www.freeroller.net/page/dion/Weblog
> Work: http://www.multitask.com.au
>
>
> news <ne...@main.gmane.org> wrote on 12/01/2003 09:52:28 AM:
>
>
>>One thing that improved performance for me was defragmenting.
>>Such is practically unheard of in the Linux world...but Microsoft
>>finally caved and admitted their favorite filesystem fragments like a
>>mutha. (Which seemed obvious to me from the technical info I saw on
>
> it)...
>
>>-Andy
>>
>>dion@multitask.com.au wrote:
>>
>>>Any ideas on my performance issues under Win2k?
>>>--
>>>dIon Gillard, Multitask Consulting
>>>Blog: http://www.freeroller.net/page/dion/Weblog
>>>Work: http://www.multitask.com.au
>>>
>>>
>>>Sam Ruby <ru...@apache.org> wrote on 11/01/2003 06:28:41 AM:
>>>
>>>
>>>
>>>>Andrew C. Oliver wrote:
>>>>
>>>>
>>>>>Ant files are XML and transforming to them seems to be more natural.
>>>>
>>>Ant
>>>
>>>
>>>>>isn't the most kind thing in the world for its "Hey this crap broke"
>>>>>messages, but it is FAR better than cmd.exe or bash in this respect.
>>>>
>>>>Costin already started something along these lines:
>>>>
>>>>http://cvs.apache.org/viewcvs/jakarta-gump/stylesheet/ant-build.xsl
>>>>
>>>>
>>>>
>>>>>Anyhow, I'm just curious what problems there are with this approach.
>>>>
>>>As
>>>
>>>
>>>>>my level of pain increases I'll probably experiment with this, but
>>>>
> I'm
>
>>>>>curious if others have thought of this and what the downsides are...
>>>>
>>>>That may be a value use case for a large portion of the portion of the
>>>
>
>>>>potential "marketplace" for gump.
>>>>
>>>>Issues:
>>>>
>>>>* I want to fully bootstrap. In my case, I want to build ant from
>>>>source and use that version later in the build.
>>>>
>>>>* I want to be able to easily reproduce problems outside of the
>>>>environment generated by Gump. Many times I've found it handy to be
>>>>able to send somebody a shell script or a batch file along with a set
>>>
> of
>
>>>
>>>>jars to reproduce a problem that they are *sure* must be Gump's fault.
>>>>
>>>>* Leaky abstractions. I've always found ant calling ant to be
>>>>confusing, particularly when it comes to what properties can be passed
>>>
>
>>>>and what can be modified. But that may just be me.
>>>>
>>>>* Modifying JDK levels and/or bootclasspath. A persistent requirement
>>>
>
>>>>(despite never having been implemented, so take it with a grain of
>>>
> salt)
>
>>>
>>>>is to do a build with different portions of the build at different JDK
>>>
>
>>>>levels. What is a real requirement, however, is the ability to modify
>>>
>
>>>>the bootclasspath between job steps.
>>>>
>>>>All presented merely as food for thought. They reasons may or may not
>>>
>
>>>>be applicable to you. But there is no reason why Gump can't support
>>>>multiple targets - it already does so with bash and win2k.
>>>>
>>>>- Sam Ruby
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>>
>>>>ForwardSourceID:NT000A1AE6
>>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>>ForwardSourceID:NT000A1EBE
>
Re: gump issues under winblows and a suggestion...
Posted by di...@multitask.com.au.
I did a defrag before my tests, so that's not it.
I'm currently running a test to see that if it's AntiVirus software. In my
preliminary tests, turning it off momentarily made the process a lot
quicker.
I'll report back when I've got some real evidence :)
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
news <ne...@main.gmane.org> wrote on 12/01/2003 09:52:28 AM:
> One thing that improved performance for me was defragmenting.
> Such is practically unheard of in the Linux world...but Microsoft
> finally caved and admitted their favorite filesystem fragments like a
> mutha. (Which seemed obvious to me from the technical info I saw on
it)...
>
> -Andy
>
> dion@multitask.com.au wrote:
> > Any ideas on my performance issues under Win2k?
> > --
> > dIon Gillard, Multitask Consulting
> > Blog: http://www.freeroller.net/page/dion/Weblog
> > Work: http://www.multitask.com.au
> >
> >
> > Sam Ruby <ru...@apache.org> wrote on 11/01/2003 06:28:41 AM:
> >
> >
> >>Andrew C. Oliver wrote:
> >>
> >>>Ant files are XML and transforming to them seems to be more natural.
> >>
> > Ant
> >
> >>>isn't the most kind thing in the world for its "Hey this crap broke"
> >>>messages, but it is FAR better than cmd.exe or bash in this respect.
> >>
> >>Costin already started something along these lines:
> >>
> >>http://cvs.apache.org/viewcvs/jakarta-gump/stylesheet/ant-build.xsl
> >>
> >>
> >>>Anyhow, I'm just curious what problems there are with this approach.
> >>
> > As
> >
> >>>my level of pain increases I'll probably experiment with this, but
I'm
> >>
> >
> >>>curious if others have thought of this and what the downsides are...
> >>
> >>That may be a value use case for a large portion of the portion of the
> >>potential "marketplace" for gump.
> >>
> >>Issues:
> >>
> >>* I want to fully bootstrap. In my case, I want to build ant from
> >>source and use that version later in the build.
> >>
> >>* I want to be able to easily reproduce problems outside of the
> >>environment generated by Gump. Many times I've found it handy to be
> >>able to send somebody a shell script or a batch file along with a set
of
> >
> >
> >>jars to reproduce a problem that they are *sure* must be Gump's fault.
> >>
> >>* Leaky abstractions. I've always found ant calling ant to be
> >>confusing, particularly when it comes to what properties can be passed
> >>and what can be modified. But that may just be me.
> >>
> >>* Modifying JDK levels and/or bootclasspath. A persistent requirement
> >>(despite never having been implemented, so take it with a grain of
salt)
> >
> >
> >>is to do a build with different portions of the build at different JDK
> >>levels. What is a real requirement, however, is the ability to modify
> >>the bootclasspath between job steps.
> >>
> >>All presented merely as food for thought. They reasons may or may not
> >>be applicable to you. But there is no reason why Gump can't support
> >>multiple targets - it already does so with bash and win2k.
> >>
> >>- Sam Ruby
> >>
> >>
> >>--
> >>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >
> >>ForwardSourceID:NT000A1AE6
> >
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> ForwardSourceID:NT000A1EBE
Re: gump issues under winblows and a suggestion...
Posted by "Andrew C. Oliver" <ac...@apache.org>.
One thing that improved performance for me was defragmenting.
Such is practically unheard of in the Linux world...but Microsoft
finally caved and admitted their favorite filesystem fragments like a
mutha. (Which seemed obvious to me from the technical info I saw on it)...
-Andy
dion@multitask.com.au wrote:
> Any ideas on my performance issues under Win2k?
> --
> dIon Gillard, Multitask Consulting
> Blog: http://www.freeroller.net/page/dion/Weblog
> Work: http://www.multitask.com.au
>
>
> Sam Ruby <ru...@apache.org> wrote on 11/01/2003 06:28:41 AM:
>
>
>>Andrew C. Oliver wrote:
>>
>>>Ant files are XML and transforming to them seems to be more natural.
>>
> Ant
>
>>>isn't the most kind thing in the world for its "Hey this crap broke"
>>>messages, but it is FAR better than cmd.exe or bash in this respect.
>>
>>Costin already started something along these lines:
>>
>>http://cvs.apache.org/viewcvs/jakarta-gump/stylesheet/ant-build.xsl
>>
>>
>>>Anyhow, I'm just curious what problems there are with this approach.
>>
> As
>
>>>my level of pain increases I'll probably experiment with this, but I'm
>>
>
>>>curious if others have thought of this and what the downsides are...
>>
>>That may be a value use case for a large portion of the portion of the
>>potential "marketplace" for gump.
>>
>>Issues:
>>
>>* I want to fully bootstrap. In my case, I want to build ant from
>>source and use that version later in the build.
>>
>>* I want to be able to easily reproduce problems outside of the
>>environment generated by Gump. Many times I've found it handy to be
>>able to send somebody a shell script or a batch file along with a set of
>
>
>>jars to reproduce a problem that they are *sure* must be Gump's fault.
>>
>>* Leaky abstractions. I've always found ant calling ant to be
>>confusing, particularly when it comes to what properties can be passed
>>and what can be modified. But that may just be me.
>>
>>* Modifying JDK levels and/or bootclasspath. A persistent requirement
>>(despite never having been implemented, so take it with a grain of salt)
>
>
>>is to do a build with different portions of the build at different JDK
>>levels. What is a real requirement, however, is the ability to modify
>>the bootclasspath between job steps.
>>
>>All presented merely as food for thought. They reasons may or may not
>>be applicable to you. But there is no reason why Gump can't support
>>multiple targets - it already does so with bash and win2k.
>>
>>- Sam Ruby
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>>ForwardSourceID:NT000A1AE6
>
Re: gump issues under winblows and a suggestion...
Posted by Sam Ruby <ru...@apache.org>.
Steven Noels wrote:
>
>>> Any ideas on my performance issues under Win2k?
>>
>> If the issue is that "echo" is too slow on your machine, then no, I
>> don't have any ideas or suggestions.
>>
>> Other than perhaps to try switching to bash/cygwin.
>
> ... unrelated to Gump specifically, but filesystem access appears to be
> much slower to me when running under cygwin. So switching to cygwin
> might not be panacea.
Unlikely to be a factor, as pretty much all of the time is supposed to
be spent in the native application - the same one in either case. Of
course, I can't explain why Perl runs nearly comparably on my machine
and dIon's, but the builtin "echo" statement seems to run nearly two
orders of magnitude slower on dIon's machine.
- Sam Ruby
Re: gump issues under winblows and a suggestion...
Posted by Steven Noels <st...@outerthought.org>.
Sam Ruby wrote:
>> Any ideas on my performance issues under Win2k?
>
>
> If the issue is that "echo" is too slow on your machine, then no, I
> don't have any ideas or suggestions.
>
> Other than perhaps to try switching to bash/cygwin.
... unrelated to Gump specifically, but filesystem access appears to be
much slower to me when running under cygwin. So switching to cygwin
might not be panacea.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: gump issues under winblows and a suggestion...
Posted by Sam Ruby <ru...@apache.org>.
dion@multitask.com.au wrote:
> Any ideas on my performance issues under Win2k?
If the issue is that "echo" is too slow on your machine, then no, I
don't have any ideas or suggestions.
Other than perhaps to try switching to bash/cygwin.
- Sam Ruby
Re: gump issues under winblows and a suggestion...
Posted by di...@multitask.com.au.
Any ideas on my performance issues under Win2k?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Sam Ruby <ru...@apache.org> wrote on 11/01/2003 06:28:41 AM:
> Andrew C. Oliver wrote:
> >
> > Ant files are XML and transforming to them seems to be more natural.
Ant
> > isn't the most kind thing in the world for its "Hey this crap broke"
> > messages, but it is FAR better than cmd.exe or bash in this respect.
>
> Costin already started something along these lines:
>
> http://cvs.apache.org/viewcvs/jakarta-gump/stylesheet/ant-build.xsl
>
> > Anyhow, I'm just curious what problems there are with this approach.
As
> > my level of pain increases I'll probably experiment with this, but I'm
> > curious if others have thought of this and what the downsides are...
>
> That may be a value use case for a large portion of the portion of the
> potential "marketplace" for gump.
>
> Issues:
>
> * I want to fully bootstrap. In my case, I want to build ant from
> source and use that version later in the build.
>
> * I want to be able to easily reproduce problems outside of the
> environment generated by Gump. Many times I've found it handy to be
> able to send somebody a shell script or a batch file along with a set of
> jars to reproduce a problem that they are *sure* must be Gump's fault.
>
> * Leaky abstractions. I've always found ant calling ant to be
> confusing, particularly when it comes to what properties can be passed
> and what can be modified. But that may just be me.
>
> * Modifying JDK levels and/or bootclasspath. A persistent requirement
> (despite never having been implemented, so take it with a grain of salt)
> is to do a build with different portions of the build at different JDK
> levels. What is a real requirement, however, is the ability to modify
> the bootclasspath between job steps.
>
> All presented merely as food for thought. They reasons may or may not
> be applicable to you. But there is no reason why Gump can't support
> multiple targets - it already does so with bash and win2k.
>
> - Sam Ruby
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> ForwardSourceID:NT000A1AE6
Re: gump issues under winblows and a suggestion...
Posted by Sam Ruby <ru...@apache.org>.
Andrew C. Oliver wrote:
>
> Ant files are XML and transforming to them seems to be more natural. Ant
> isn't the most kind thing in the world for its "Hey this crap broke"
> messages, but it is FAR better than cmd.exe or bash in this respect.
Costin already started something along these lines:
http://cvs.apache.org/viewcvs/jakarta-gump/stylesheet/ant-build.xsl
> Anyhow, I'm just curious what problems there are with this approach. As
> my level of pain increases I'll probably experiment with this, but I'm
> curious if others have thought of this and what the downsides are...
That may be a value use case for a large portion of the portion of the
potential "marketplace" for gump.
Issues:
* I want to fully bootstrap. In my case, I want to build ant from
source and use that version later in the build.
* I want to be able to easily reproduce problems outside of the
environment generated by Gump. Many times I've found it handy to be
able to send somebody a shell script or a batch file along with a set of
jars to reproduce a problem that they are *sure* must be Gump's fault.
* Leaky abstractions. I've always found ant calling ant to be
confusing, particularly when it comes to what properties can be passed
and what can be modified. But that may just be me.
* Modifying JDK levels and/or bootclasspath. A persistent requirement
(despite never having been implemented, so take it with a grain of salt)
is to do a build with different portions of the build at different JDK
levels. What is a real requirement, however, is the ability to modify
the bootclasspath between job steps.
All presented merely as food for thought. They reasons may or may not
be applicable to you. But there is no reason why Gump can't support
multiple targets - it already does so with bash and win2k.
- Sam Ruby
Re: gump issues under winblows and a suggestion...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> If you searchg in the alexandria-dev mailing list you will find some
>> interesting discussions about this. I'll try to summarize here the
>> results I came to.
>
> [snip]
>
>> I refactored the Gump CVS to split the various parts of Gump into
>> repository data, aggregation of data, script generation, site
>> generation. Result? No real gain and nobody folowing. Deleted effort
>
>
> ;-)
>
> I can't resist:
>
> verba manent, scripta volant?
>
Yeah :-)
Now you really know what my sig is about and for. Honest, I'm not kidding.
[...]
> What does this all mean? Don't be afraid that I'm going to -1 any
> alternative to XSLT generation of scripts.
> Go for it.
JustDoIt ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: gump issues under winblows and a suggestion...
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> If you searchg in the
> alexandria-dev mailing list you will find some interesting discussions
> about this. I'll try to summarize here the results I came to.
[snip]
> I refactored the Gump CVS to split the various parts of Gump into
> repository data, aggregation of data, script generation, site
> generation. Result? No real gain and nobody folowing. Deleted effort
;-)
I can't resist:
verba manent, scripta volant?
;-)
= = =
Brief history of Gump.
Once upon a time, long long ago, I was the Tomcat 3.1 release manager.
At that time, things were so wild and wooly, that in order to
successfully build Tomcat on a daily basis one needed to make fixes to
Ant.
Now, project had their own build scripts mostly based on Ant, so I
simply created a script which ran them in series.
...
Over time, two things happened. First, I got interested in more
projects. Second, changed the "echo" statements into my script that
told me where it was at any point in time to echo HTML so that I could
browse the results remotely.
The lovingly handcrafted script looked like this:
http://oss.software.ibm.com/developerworks/opensource/jakarta/buildall.html
and the output looked like this:
http://oss.software.ibm.com/developerworks/opensource/jakarta/buildlog.html
...
Still more time elapsed, and I found two problems. One was that every
time a project inserted a dependency, I had to figure out a correct
order. The second was that as the ASF grew, projects talked to each
other less, so cross project breakages grew more commonplace.
The solution to the former was to automate the generation of the script.
The solution to the latter was to simply publish the results -
ultimately augmeted by a nag script initially donated by Jon Stevens.
Why did I write it in XSLT? For starters, Velocity didn't exist yet.
And secondly, I wanted to learn XSLT.
...
Fast forward a bit more. Gump certainly tried to follow Stefano's
Mazzocchi's design pattern [1] of "good ideas and bad code build
communities, the other three combinations do not", but the community
never quite formed. Why is that? My theory is based Sunir's corrollary
4b [2] "As long as the project looks like one person's work, it is one
person's work.". So, for a while now, I have tried to hold back. Still
not much luck, but I am still hopeful.
...
What does this all mean? Don't be afraid that I'm going to -1 any
alternative to XSLT generation of scripts. Go for it.
...
Footnotes:
[1]
http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html
[2] http://www.advogato.org/article/395.html#5
- Sam Ruby
Re: gump issues under winblows and a suggestion...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew C. Oliver wrote:
> So Getting gump to run under Windows is not particularly fun. (Don't
> ask, my hands are tied).
[...]
> I'm curious if it has been suggested before....
>
> Ant files are XML and transforming to them seems to be more natural. Ant
> isn't the most kind thing in the world for its "Hey this crap broke"
> messages, but it is FAR better than cmd.exe or bash in this respect.
[...]
> Anyhow, I'm just curious what problems there are with this approach. As
> my level of pain increases I'll probably experiment with this, but I'm
> curious if others have thought of this and what the downsides are...
Andy, I've been through all this before, in the months you were waiting
for Centipede to build under Gump ;-) If you searchg in the
alexandria-dev mailing list you will find some interesting discussions
about this. I'll try to summarize here the results I came to. Scott
Sanders seemingly did the same thing before me, so I would like to spare
you this waste of time and get more productive right away.
_Gump sucks, why does it use scripts?_
Heck, Ant is in Java, cross-platform and can invoke scripts. Why don't
we XSLT the descriptors into an Ant buildfile and run that? Look in the
jakarta-alexandria CVS module and you'll find AntGump.
_These generated and buildfiles are messy, why don't we make a model?_
Heck, all done in XSLT gets messy. Let's parse the files and create an
Object Model of the build, and act on that. In the same CVS as usual,
look for Vindico, courtesy Scott Sanders (again).
_Wait, the problem is in the Gump installation, let's refactor?_
I refactored the Gump CVS to split the various parts of Gump into
repository data, aggregation of data, script generation, site
generation. Result? No real gain and nobody folowing. Deleted effort
(but understood a lot in the process).
_Now what?_
Form the above + other info I gathered while having the high levels of
frustration you envision ;-) :
- As for merging the descriptors, Jenny does just fine,it simply works.
I would not change that. So I came up with the concept of VIPROM,
that means Virtual Project Object Model. merge.xml is the current
physical way of making it, and we could access it programmatically
from jxpath (so in the future we don't need to change all code just
to change how the model is constructed)
- Then the projects must be run. Now we use script generation with
XSLT. HEck, there is a lot that can be done here. Imagine using
Velocity instead. Much faster and much cleaner writing. It
can be also quite easy to make ant buildfiles out of it.
- Another option to run is to use a Java frontend, that runs the
builds programmatically. This can be a base also for a daemon service
that can run projects remotely at request or at cvs commits.
On my side, I'll be using a VIPROM to access project descriptor info
from Ant buildfiles, and add a feature in Centipede that builds the
projects in the module (the single module) with dependencies et all.
Comments?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------