From: "Vincent Massol" <[EMAIL PROTECTED]>
> > -----Original Message-----
> > From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> > Sent: 15 May 2002 15:50
> > To: Alexandria Developers List
> > Subject: Re: Prereq check limitations and proposal for improvement
> >
> > From: "Vincent Massol" <[EMAIL PROTECTED]>
> >
> > > Hi,
> > >
> > > Several of my projects generate (as distributables) bunches of files
> > > (actually some generate a full directory structure, others some zip
> > > files, EAR, etc).
> > >
> > > The problem is that gump only knows about jars being delivered by a
> > > project (and javadoc but this is not used for pre-req checks).
> > >
> > > Thus, when I have a project that depends on this kind of project,
> gump
> > > does not recognize a prereq failure.
> > >
> > > I haven't found anything better than tricking gump by using a <jar>
> > > entry that points to a non jar files (but then it gets added to the
> > > classpath and although I can choose the file so that it won't do any
> > > harm, it is not a really good solution).
> > >
> > > Proposal : To extend the gump DTD to support the notion of
> deliverables
> > > (I seem to remember Nicola had proposed something along the same
> lines
> > > not long ago on this list).
> >
> > Yes, and AFAIK there is already an working <deliver/> tag...
> >
> > Any way of getting it working?
> >
> > > Something like :
> > >
> > > <deliverables setid="set1">
> > > <jar name="" id=""/>
> > > <directory location=""/>
> > > <file path=""/>
> > > </deliverables>
> > >
> > > <deliver fromdir="" [...] setid="set1"/>
> > >
> > > Prereq logic will check that all deliverables have been created.
> <jar>
> > > would work in the same way it is currently working. <deliver> would
> copy
> > > the said deliverables to some location.
> >
> > Hmmm... this basically breakes the fact that it's Gump that should
> decide
> > what to do with the module stuff.
>
> You mean not specify any action in the descriptor, just data ?
Yes.
> I'm fine with this but :
> - then you need a way of telling Gump what to do with the data
Yes. This should be described centrally in a workspace maybe.
I suppose that a Gump run would want uniformity in the way it delivers
stuff...
> - the current descriptors do already have quite a few actions : nag,
> deliver, ant (although this one could probably be considered data)
Yes, it breaks the fact that the control must come from Gump, not the
descriptors.
In fact they should only "describe" the project, not "act".
> > In my last proposal, I also proposed to eliminate the javadoc tag, in
> > favor
> > of a system that tells Gump what the build results are, without
> defining
> > explicit deliver systems.
>
> I really need to look at your proposal. I just sent this email because I
> have the need of a project at work that I'd like to resolve quickly
> (although it isn't high priority) and I wanted to see reactions/ideas
> from the community.
>
> I'll post back soon. I'm still eager to hear from others what they
> think.
> Thanks
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
