Myrna van Lunteren wrote:
On 7/6/07, Daniel John Debrunner (JIRA) <[EMAIL PROTECTED]> wrote:
What's the ant target to build the release notes [...]
See:
http://wiki.apache.org/db-derby/ReleaseNoteProcess#head-1562c977bce7878313b51f6e55a9856bc2b09801
The step that's currently most troublesome is to generate the reports
out of JIRA.
part of it can be accomplished by:
java org.apache.derbyBuild.JiraConnector
(But this gives everything, and I've modified the release notes
generator to strip out test issues, for example.)
Theoretically, this could be one step...
I assume you are going to commit those changes back in. A release needs
to be in a state where someone else can build it using the same source
as is in the release. I hope there's no manual editing of the release notes.
[...](and the one to build a complete release)?
Assuming you've got the maintversion.properties(for the version
number) and release notes in order (or don't care about them):
- build the docs or get them from the apache derby site
- copy tools/ant/properties/packaging.tmpl to
tools/ant/properties/packaging.properties and set the location for the
docs; set your md5 executable preferences
- comment out any sane settings in your ant.properties
- follow the steps currently in the 2nd step 7 of :
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease
i.e.:
svn up
ant clobber
rm -rf jars javadoc snapshot # really clean
rm tools/release/*.zip tools/release/*.tar.gz # really,
rm tools/release/*.md5 tools/release/*.asc # really clean
One issue here is the number of different locations that the Derby ant
targets build into. I just set up a new project with ant and everything
becomes much easier if there is a single build folder. So this project
builds into
build/classes
build/lib
build/release.jar
etc.
Thus the clean operation is a simple remove on the build folder.
ant sane ; ant all ; ant buildjars # for lib-debug
ant clobber
ant insane
ant -Dsane=false snapshot
ant publishedapi
cd tools/release
ant release
(for actually creating a full release this needs to be followed by ant
sign and then one still needs to build the ui and doc plugins using
eclipse.)
What does building using 'eclipse' mean? I assume one can build plugins
from an ant target without launching the IDE.
Most of these except the ant sign and eclipse plugin generation can be
put in one ant target but as it should stop when any of the steps
fail, or when sane is set in ant.properties, or the docs are not set,
or md5 doesn't work, or...(?) and probably should be made to build the
docs if it can figure out the source location it needs a little more
work than I'm currently willing to put into it. This is DERBY-2573.
Just FYI that by using ant as intended (via dependencies) targets fail
if a dependency fails, so that's actually the easier mechanism. Derby's
build.xml files tend to not take this approach. For example the Derby
'snapshot' target uses ant call to build 'insane', 'all' 'buildjars'
etc., that's the wrong approach, a failure in those will not be pushed
to the top level. Instead is should just depend on those targets.
In this new project I have an ant target called 'release'. It builds a
release from scratch, including compiling java code, running junit
tests, running some java code, building jars and then running tests
again against the jars. If anything fails, then the ant fails and no
release is built.
It would be good for us to get this mindset for the release process, if
it can't be done through ant then it can't be part of the release
process. I see that the release managers seem to have to struggle to
build the release artifacts, that doesn't encourage others to be release
managers, enable release often or allow regular testing of the release
process. I'm envious when I see other open source projects build a
release quickly and move straight to a vote, even when a new committer
performs the release manager role.
I'd be willing to help out on some of these ant targets.
Dan.
