Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of stepan.mishura@gmail.com
 designates 64.233.166.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=kQzEcZbjfsiyLC/mGmbFW+cetm4J3Q4DYaHyNBGIPYto45Ql8Umx0Uk6HgS8dWsDokNY+ngZ20NsrGQoAiZ9XAMjyENjKIuWRk+GawiccGX45KKfj6P/tFgJjlpwWqIOQYT1zvu16dX/d9P3kQS1hrVfEnFRSFYSkW/35w7u7jg=
Message-ID: <6e47b64f0705040237g203f9451sb9aad20f8b0337b@mail.gmail.com>
Date: Fri, 4 May 2007 16:37:55 +0700
From: "Stepan Mishura" <stepan.mishura@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [tools][launcher] Where should the launcher code reside?
In-Reply-To: <4639CE2D.6070104@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4639CE2D.6070104@gmail.com>

On 5/3/07, Tim Ellison wrote:
> Up until yesterday we had two copies of the launcher code, one in
> classlib LUNI module, and one in jdktools.  Hopefully we all agree that
> we don't need two copies of the code.
>
> Yesterday I removed the launcher from classlib, and updated the one in
> jdktools; but that seems to break a number of people who rely on
> building classlib and dropping in a built VM to run a JRE.
>
> Arguably, the 'right' way to work is either to build an HDK from scratch
> (i.e. a full federated build), or download a pre-built HDK then
> build&test the classlib|vm|jdktools against that.  Then you will always
> have a full installation, and can update the bits you are working on.
>
> But if people want to keep working with just the classlib and VM then I
> have no objection to leaving the launcher in the classlib area.  It
> doesn't do anyone any harm in there.  The layout should suit our working
> patterns, not the other way around.
>

I see the next argument for moving the launcher to jdktools - this not
a java library code indeed, it's just utility code that launches java.
But moving it to jdktools will force everybody to work with HDK. If
everybody think that this is 'right' way then I'm OK with it (I mainly
work with separate classlib and DRLVM workspaces and I find it quite
convenient)

BWT, how many people use hdk build only?

Also if we move it to jdktools we need to adjust build-and-test infra
that it requires time and efforts. But I think this in turn should
unify (i.e. simplify) the infra logic - all testing suites will depend
on hdk build only (not on classlib + drlvm (+ hdk) as currently we
have)

Thanks,
Stepan.

> What do you think?
>
> Tim
>