[tools][launcher] Where should the launcher code reside?

[Tim Ellison <t....@gmail.com>]

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.

What do you think?

Tim

Re: [tools][launcher] Where should the launcher code reside?

[Stepan Mishura <st...@gmail.com>]

On 5/4/07, Vladimir Ivanov wrote:
> OK, what I should do if I want to use CLASSLIB+IBMVM?

AFAIU it was proposed to build classlib with jdk_tools.

-Stepan.

> If I should build HDK and replace VM after that I vote to have
> launcher in CLASSLIB...
>
>  Thanks, Vladimir
>
>
> On 5/4/07, Stepan Mishura <st...@gmail.com> wrote:
> > 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

Re: [tools][launcher] Where should the launcher code reside?

[Vladimir Ivanov <iv...@gmail.com>]

OK, what I should do if I want to use CLASSLIB+IBMVM?
If I should build HDK and replace VM after that I vote to have
launcher in CLASSLIB...

 Thanks, Vladimir


On 5/4/07, Stepan Mishura <st...@gmail.com> wrote:
> 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
> >
>

Re: [tools][launcher] Where should the launcher code reside?

[Stepan Mishura <st...@gmail.com>]

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 <gs...@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

Re: [tools][launcher] Where should the launcher code reside?

[Gregory Shimansky <gs...@apache.org>]

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.

> On 5/14/07, Gregory Shimansky <gs...@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

Re: [tools][launcher] Where should the launcher code reside?

[Ivan Popov <iv...@gmail.com>]

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.
Ivan

On 5/14/07, Gregory Shimansky <gs...@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
>
>

Re: [tools][launcher] Where should the launcher code reside?

[Gregory Shimansky <gs...@apache.org>]

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

Re: [tools][launcher] Where should the launcher code reside?

[Alexei Zakharov <al...@gmail.com>]

IMHO this topic is more about changing people's habits. On the one
hand it's more logical to have the launcher in jdktools since it is
not a library, on the other hand people use to have  it in
classlib/luni. Personally I don't care. However, I have strong +1 for
last Tim's sentence

> There are more interesting problems to work on :-)

:-)

Regards,

2007/5/4, Tim Ellison <t....@gmail.com>:
> Stepan Mishura wrote:
> > 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)
>
> Unless Alexey feels strongly (in which we continue to discuss), I
> suggest we just leave it where it is, in classlib.  There are more
> interesting problems to work on :-)
>
> Regards,
> Tim



-- 
Alexei Zakharov,
Intel ESSD

Re: [tools][launcher] Where should the launcher code reside?

[Tim Ellison <t....@gmail.com>]

Stepan Mishura wrote:
> 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)

Unless Alexey feels strongly (in which we continue to discuss), I
suggest we just leave it where it is, in classlib.  There are more
interesting problems to work on :-)

Regards,
Tim

Re: [tools][launcher] Where should the launcher code reside?

[Stepan Mishura <st...@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
>

Re: [tools][launcher] Where should the launcher code reside?

[Ivan Popov <iv...@gmail.com>]

Ilya,

Currently, jdk/bin/java wrapper is generated by samsa module in
jdktools, not by launcher module. As long as launcher module which
creates jdk/jre/bin/java is located in classlib tree, the current
picture corresponds to your suggestion. I think this is a right
solution.

Thanks.
Ivan

On 5/3/07, Ilya Neverov <il...@gmail.com> wrote:
> Some people need JDK (with HDK); some need JRE, even a part of JRE -
> classlib only. So we need jre/bin launcher and jdk/bin launcher. I
> think first one should be built from sources in classlib tree. Second
> one can be copied from jre/bin or it can be built from specific
> sources located in jdktools tree.
>
> Regards
> -Ilya
>
> On 5/3/07, Alexey Petrenko <al...@gmail.com> wrote:
> > I think that luni module of class library is not the correct place for
> > launcher... jdktools looks much better.
> >
> > SY, Alexey
> >
> > 2007/5/3, Tim Ellison <t....@gmail.com>:
> > > 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.
> > >
> > > What do you think?
> > >
> > > Tim
> > >
> >
>
>
> --
> Thank you.
> Ilya Neverov
>

Re: [tools][launcher] Where should the launcher code reside?

[Ilya Neverov <il...@gmail.com>]

Some people need JDK (with HDK); some need JRE, even a part of JRE -
classlib only. So we need jre/bin launcher and jdk/bin launcher. I
think first one should be built from sources in classlib tree. Second
one can be copied from jre/bin or it can be built from specific
sources located in jdktools tree.

Regards
-Ilya

On 5/3/07, Alexey Petrenko <al...@gmail.com> wrote:
> I think that luni module of class library is not the correct place for
> launcher... jdktools looks much better.
>
> SY, Alexey
>
> 2007/5/3, Tim Ellison <t....@gmail.com>:
> > 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.
> >
> > What do you think?
> >
> > Tim
> >
>


-- 
Thank you.
Ilya Neverov

Re: [tools][launcher] Where should the launcher code reside?

[Tim Ellison <t....@gmail.com>]

Alexey Petrenko wrote:
> 2007/5/3, Mikhail Loenko <ml...@gmail.com>:
>> I agree. jdktools is something more natural for launcher.
>>
>> we may require something like working_tools dir next to classlib so
>> them classlib build takes it there
>
> There is working_jdktool dir already.

I'll leave you to discuss the pro's and con's -- I don't feel strongly
about it (other than not having > 1 copy of the code <g>)

Regards,
Tim

Re: [tools][launcher] Where should the launcher code reside?

[Alexey Petrenko <al...@gmail.com>]

2007/5/3, Mikhail Loenko <ml...@gmail.com>:
> I agree. jdktools is something more natural for launcher.
>
> we may require something like working_tools dir next to classlib so
> them classlib build takes it there
There is working_jdktool dir already.

SY, Alexey

>
> Thanks,
> Mikhail
>
> 2007/5/3, Alexey Petrenko <al...@gmail.com>:
> > I think that luni module of class library is not the correct place for
> > launcher... jdktools looks much better.
> >
> > SY, Alexey
> >
> > 2007/5/3, Tim Ellison <t....@gmail.com>:
> > > 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.
> > >
> > > What do you think?
> > >
> > > Tim
> > >
> >
>

Re: [tools][launcher] Where should the launcher code reside?

[Mikhail Loenko <ml...@gmail.com>]

I agree. jdktools is something more natural for launcher.

we may require something like working_tools dir next to classlib so
them classlib build takes it there

Thanks,
Mikhail

2007/5/3, Alexey Petrenko <al...@gmail.com>:
> I think that luni module of class library is not the correct place for
> launcher... jdktools looks much better.
>
> SY, Alexey
>
> 2007/5/3, Tim Ellison <t....@gmail.com>:
> > 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.
> >
> > What do you think?
> >
> > Tim
> >
>

Re: [tools][launcher] Where should the launcher code reside?

[Alexey Petrenko <al...@gmail.com>]

I think that luni module of class library is not the correct place for
launcher... jdktools looks much better.

SY, Alexey

2007/5/3, Tim Ellison <t....@gmail.com>:
> 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.
>
> What do you think?
>
> Tim
>