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.162.234 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=dDwq3LxW7ATH4zJOaiQ76RQBHlomumEc2H9nf5MKJ1uX6mK11PDssBDS04MMof7h6a1q2IsFIR40r7CI5GfDc4Hm8PRdU3H13fVDOIfHXp/+RVtpBZ0plxIFm1VhPj9s6vdw88rwora+sjutacSAMRs4Nn8aOS/z3kiF09W3nWw=
Message-ID: <6e47b64f0705142025x3628d588t360e699cffeeea77@mail.gmail.com>
Date: Tue, 15 May 2007 10:25:56 +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: <f29qrg$6qm$2@sea.gmane.org>
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>
	 <6e47b64f0705040237g203f9451sb9aad20f8b0337b@mail.gmail.com>
	 <f29iq8$b1n$1@sea.gmane.org>
	 <b6cb498e0705140510q1f2fc92pc86940e2984e909@mail.gmail.com>
	 <f29qrg$6qm$2@sea.gmane.org>

On 5/14/07, Gregory Shimansky wrote:
> Ivan Popov wrote:
> > Gregory,
> >
> > Today jdktools build depends on classlib and drlvm builds. Adding one
> > more dependency between jdktools and classlib builds will lead to a
> > cyclic dependency, which should be resolved somehow.
> >
> > I think the most simple way technically is to leave launcher code in
> > classlib component.
>
> Thanks for pointing this. I didn't know that jdktools depends on
> classlib and drlvm. To break the cycle perhaps we'll have to move some
> common stuff to common_resources.
>

As far as I remember common_resources 'subproject' was created for
dealing with external dependencies that common for classlib, drlvm,
jdktools. So from my POV it is not the right place for launcher.

-Stepan.

> > On 5/14/07, Gregory Shimansky <gshimansky@apache.org> wrote:
> >> Stepan Mishura wrote:
> >>   > 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)
> >>
> >> I am catching up with emails after vacations and just saw this thread. I
> >> am +0.5 to java launcher in jdktools and I think that the working
> >> process could be organized without having to build full HDK every time.
> >>
> >> Just look at how drlvm is built, it always requires to compile classlib
> >> first and no one complains about it. If someone works primary on drlvm,
> >> classlib may be compiled just once in a while and there is no big reason
> >> to rebuild it all the time when VM is built.
> >>
> >> The same could be done with jdktools. Then the sequence of building
> >> separate packages would be the following: jdktools -> classlib -> vm.
> >> Classlib build script would copy files from the deploy directory of
> >> jdktools and VM build script would copy compiled classlib to its deploy
> >> directory.
> >>
> >> Classlib developers would need to compile jdktools just once in a while
> >> (updates to the launcher are quire rare anyway) and then compile just
> >> classlib which would take java executable from jdktools.
> >>
> >> Anyway, I agree with Tim's comment that it is not the most important
> >> thing to do.
> >>
> >> > 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
> >>
> >> --
> >> Gregory
> --
> Gregory