harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [build][federation] building snapshots and releases
Date Wed, 25 Oct 2006 15:28:44 GMT

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
$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


with some structure under there and tagging convention.


View raw message