Mark Hindess wrote:
Currently, the federation build looks at the revision of the federation
tree that you have checked out and checks out the same revision of the
classlib and drlvm trees.
That was just for convenience if you don't care.
It doesn't work all that well in practice, because you want to do the
same SVN rev on multiple platforms, so I tend to formally specify it on
the command line :
$ ant -Dsvn.revision=X
Since we want releases to be reproducible (i.e. known tags of not only
classlib and drlvm but also of the federation code that was used to
combine them), then I think it make sense to use a similar mechanism
when building from an svn tag.
That is, if you check out the federation build from[0]:
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/tags/1.0
then the federation build.xml should ensure that it also checks out the
1.0 tag of classlib and drlvm. That is:
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tags/1.0
and:
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/drlvm/tags/1.0
This will need a little tweaking to the federation build.xml and I
wanted to be sure this made sense before I started. What do people
think?
Well... certainly I think we'll need it at some point in the future,
because it's clear we won't have the luxury of having the VM and
classlib right in the same svn revision number. This also will be true
when there are VM options, so you'll take VM_1234 and CLASSLIB_1292 and
JAVATOOLS_1.2.3 (whatever those numbers mean), and combine into a JDK
and test that with the TCK.
First, do no harm. Make it a choice. The current snapshot mechanism is
lightweight, and I do find the lack of tags and branches in SVN as first
class citizens to be a royal PITA.
So maybe I can either do :
$ant -Dsvn.revision=X
for a simple snapshot build or
$ant -Dclasslib.tag=X -Ddrlvm.tag=Y -Djavatools.tag=Z
?
I've started on the source archive for snapshots (though it doesn't
work yet[1]). My feeling is that although the federation build.xml
in the svn checkout can be used to produce the binary archives - as
it was used to produce the current snapshots - that in order to prove
the source snapshot works (and to make sure that what we test/release
is consistent) we should actually create the binary archives for a
"release" from the source archive. That is, the process should be:
1) check out federation build using https://.../tags/1.0
2) ant bundle_src
3) unpack the resulting source archive (or perhaps just cd target/src)
4) build binary archives using contents of the source archive
Lets clarify.
The "federation tree" is really just a build.xml file, and for
convenience, there is LICENSE, NOTICE, etc, but that's a maintenance
problem given we have info in multiple places. So lets assume we fix
that, and the "federation" is just the build.xml
Suppose we did this :
$ant -Dfed.version=W -Dsvn.revision=X
or
$ant -Dfed.version=W -Dclasslib.tag=X -Ddrlvm.tag=Y -Djavatools.tag=Z
leads to :
1) create directory under /trunk "snapshot-W-rX" or "dist-W-X-Y-Z"
2) checkout into that directory the build.xml rW
3) cd into that directory
4) run ant target to populate the source
5) (not sure?) Run the fetch targets to populate the deps
6) tar that directory to make the source tarball
7) run the build target
It seems like the only issue is that we need to stable down the version
of federation tree too (which is the build script)
In short, make the binaries using the source archive that you are
planning to "release" so that you know the source archive is really
complete and works.
Does the sequence above satisfy your requirements?
Does this seem reasonable?
Regards,
Mark.
[0] We don't have a tags directory yet and maybe we might make it under
harmony/enchanced/federation rather than in harmony/enchanced but
we can fix that later.
this is an orthogonal thread. We need to think about this carefully.
One idea that leaps to mind is
harmony/enhanced/branches_and_tags/
with some structure under there and tagging convention.
geir
