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 Vincent Massol <vm...@octo.com> on 2002/05/15 16:10:49 UTC
Prereq check limitations and proposal for improvement
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).
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.
Comments ? Shall I go ahead and try to do this :-)
Thanks
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Prereq check limitations and proposal for improvement
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Vincent Massol" <vm...@octo.com>
> > -----Original Message-----
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > Sent: 15 May 2002 15:50
> > To: Alexandria Developers List
> > Subject: Re: Prereq check limitations and proposal for improvement
> >
> > From: "Vincent Massol" <vm...@octo.com>
> >
> > > 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 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: Prereq check limitations and proposal for improvement
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 15 May 2002, Vincent Massol <vm...@octo.com> wrote:
> - the current descriptors do already have quite a few actions : nag,
> deliver, ant (although this one could probably be considered data)
Well, if you call ant data, nag and deliver are data as well - they
only say whom to send mail or what to put where but don't cause the
corresponding actions to be taken.
I can't recall Nicola Ken's proposal - I may have quickly skimmed
through it, but don't really remember the details.
Having a way to define what a project produces and using this
information to determine whether a project has been built successfully
or not has both pros and cons. A benefit of the current system is
that a project that does more than just building jars can fail at a
later stage (checking source style, formatting documentation,
whatever) but such a failure doesn't affect the projects that depend
on them as long as the jar has been created.
Also not that the current <javadoc> does more then just say "oh, and
there are some docs" - you can attach the javadocs of one project to a
different project (see ant-contrib and cpptasks for example). This
reminds me that I probably should commit my revised <javadoc> section
of the Gump docs.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Prereq check limitations and proposal for improvement
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: 15 May 2002 15:50
> To: Alexandria Developers List
> Subject: Re: Prereq check limitations and proposal for improvement
>
> From: "Vincent Massol" <vm...@octo.com>
>
> > 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 ?
I'm fine with this but :
- then you need a way of telling Gump what to do with the data
- the current descriptors do already have quite a few actions : nag,
deliver, ant (although this one could probably be considered data)
>
> 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
-Vincent
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:alexandria-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:alexandria-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Prereq check limitations and proposal for improvement
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Vincent Massol" <vm...@octo.com>
> 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.
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.
--
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>