You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/03/18 20:40:33 UTC
[PATCH] Cocoon gump descriptor enhancement
Another patch, this time for Cocoon.
I've added this target to build.xml:
<!--
=================================================================== -->
<!-- Target called by
-->
<!--
=================================================================== -->
<target name="gump" depends="docs, javadocs, test, package"
description="Gump target"/>
and this diff contains changes to the gump descriptor to:
1. call gump target (generate docs, javadocs and test too)
1-b. package doesn't get updated by gump if tests fail
- <ant target="package">
+ <ant target="gump">
2. tell gump where the resulting javadocs are
+ <javadoc parent="build/cocoon/javadocs"/>
3. commented out location of where the Cocoon site is
+ <!-- for possible future site tag
+ <javadoc parent="build/cocoon/docs"/>-->
4. Added poi classes as optional
+ <option project="jakarta-poi"/>
+ <option project="commons-logging"/>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Crazy idea: update project jars if Gump build succedes
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Conor MacNeill" <co...@cortexebusiness.com.au>
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> > Then, when the project decides for a code-freeze for the release, the
> > jars are not updated anymore till release is done.
>
> Do you mean that the jars a project depends on should be "frozen" at the
> last successful build?
>
> I disagree. Whan a project proceeeds to a release it should, IMHO, only
> depend on the released versions of other projects. These are the only jars
> which those projects have agreed to release. These snapshots built by Gump
> may contain features that a project may later decide not to proceed with.
> If you depend on those features and they are never released, you may be
> in trouble. If users of your code upgrade that dependent library, you will
> break.
Ok.
> Gump, in its current incarnation, is an early warning system when using
> the latest of everything. It alerts you to the impacts your changes made
> in CVS may have on other projects. Gump will not, however, warn you
> if you rely on a feature that is not yet released.
Of course, yes.
> There may be a case for doing a separate Gump run where the dependencies
> are provided from the latest released versions of a library rather than
> the current CVS HEAD, although I have not looked into what would be
> required to do that.
What about this solution then:
10- The project uses always the latest jars from other projects if it flags
for it in its Gump descriptor.
20- When it's starting to think about release, the build starts being done
only with the latest _release builds_.
30- if it needs some features from a development jar, it can
a. lobby the other project to do a release
b. revert to latest release version of the other project
c. decide to bite the bullet and use a dev version by freezing it
40- release
50- goto 10
-0-
IMHO the Gump descriptor could be enhanced for example with:
<dev version="1" minor="1" bugfix="2" state="dev|freeze|release"/>
When in _dev_ state, it uses the dev jars.
Gump can automatically update the descriptor and add a version attribute to
the jar dependencies, to show what jars are really in use.
When in _freeze_ state, it uses the latest release jars.
Gump can automatically update the descriptor in a similar way, but only on
the first run in freeze state.
This means that the jar versions to use can be hand-modified to specify what
the project really wants to use.
When it's in _release_, Gump could actually do the release if they specify
what target to use for it and where the jars are. Forrest can also get the
site ready and add the news to the site automatically.
Of course, Gump will change the release attribute to dev just after a
succesfull release.
-0-
One thing is missing though:
how can Gump make a project use the latest jars? Change the versions that
are in CVS?
Scott, IIRC there was something called CJAN and
JJAR in commons sandbox. (hint hint, nudge nudge ;)
--
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: Crazy idea: update project jars if Gump build succedes
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Then, when the project decides for a code-freeze for the release, the jars
> are not updated anymore till release is done.
>
> What do you think? <ducking/> ;-)
>
Do you mean that the jars a project depends on should be "frozen" at the
last successful build?
I disagree. Whan a project proceeeds to a release it should, IMHO, only
depend on the released versions of other projects. These are the only jars
which those projects have agreed to release. These snapshots built by Gump
may contain features that a project may later decide not to proceed with. If
you depend on those features and they are never released, you may be in
trouble. If users of your code upgrade that dependent library, you will
break.
Gump, in its current incarnation, is an early warning system when using the
latest of everything. It alerts you to the impacts your changes made in CVS
may have on other projects. Gump will not, however, warn you if you rely on
a feature that is not yet released.
There may be a case for doing a separate Gump run where the dependencies are
provided from the latest released versions of a library rather than the
current CVS HEAD, although I have not looked into what would be required to
do that.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Crazy idea: update project jars if Gump build succedes
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Maybe it's just because I'm hungry, or because I'm shutting off my computer
and will not see your replies till tomorrow ;-) , but I just had this crazy
idea:
---------------------------------------------------------------------
What would you think of making Gump update the jars
of the projects with fresh ones if the build succedes?
---------------------------------------------------------------------
This would really be *cross-project integration*: catching build errors is
ok, but we this way we can also catch errors on program behaviour early.
Then, when the project decides for a code-freeze for the release, the jars
are not updated anymore till release is done.
What do you think? <ducking/> ;-)
--
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>