You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/10/02 17:00:59 UTC
[general] creation of "jdktools"
Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
like to organize these and add them to the next snapshot.
So I propose adding a new top-level directory called "jdktools" (and
rename "tools" to "project_tools") and create a build target that - with
a dependency on classlib for the launcher - creates the 'stuff' needed
to fill into the JDK.
Any comments?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by Tim Ellison <t....@gmail.com>.
Looks great Ilya, go for it.
Regards,
Tim
Ilya Neverov wrote:
> Hello,
>
> I want to gather opinions about structure of the "jdktools" component.
>
> I'm going to create scripts for moving tools' sources from classlib/
> to top-level directory jdktools/ and to prepare patches for build
> system for building tools from new place.
>
> I think the following structure will be appropriate for future
> evolution of the jdktools:
>
> jdktools/trunk/
> build.xml
> make/
> doc/
> modules/
> jre/ # keytool, tool launcher go here
> build.xml # classes go to jdk/jre/lib/tools.jar
> make/
> src/
> jdk/ # javac, jarsigner go here
> build.xml # classes go to jdk/lib/tools.jar
> make/
> src/
> jdwp/ # separate module for large component
> build.xml
> make/
> src/
>
> Assumptions which look reasonable for jdktool's build subsystem:
>
> 1) it works in presence of built classlib (as HDK binaries or as a
> result of classlib phase of overall build);
> 2) the 'jre' module is always built before building 'jdk' to provide
> generic tool launcher and the jre/lib/tools.jar. Probably it will be
> easy to obtain these items from HDK.
>
> I'm rather newbie in the Harmony build system so your thoughts will be
> very helpful.
>
> Thank you
> -Ilya
>
>
> On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
>> Hi Geir,
>>
>> Looks like that creating the "jdktools" source tree and build was
>> shaded by other tasks. I can help with preparing and checking updates
>> in the build system. Please let me know what needs to do in this area
>> (besides svn commits) to complete the task.
>>
>> I'm especially interested in completing the move to "jdktools"
>> structure since there will be a home for the JDWP code, which has beed
>> voted but still resides in JIRA. Working with SVN will be easier.
>>
>> Thanks.
>> -Ilya
>>
>> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > yep, that's the plan. And once we have that, we can simplify the
>> > launcher as well...
>> >
>> > Tim Ellison wrote:
>> > > +1 for creating a jdktools directory. The dependency on the classlib
>> > > launcher should be relatively light if we go with a simple tools
>> > > launcher that rewrites the tool invocation into a generic launcher
>> > > invocation. You may recall the idea was discussed a while ago.
>> > >
>> > > So, for example,
>> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
>> > > is rewritten to
>> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
>> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>> > >
>> > > and so on.
>> > >
>> > > Regards,
>> > > Tim
>> > >
>> > > Geir Magnusson Jr. wrote:
>> > >> Geir Magnusson Jr. wrote:
>> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
>> keytool, I'd
>> > >>> like to organize these and add them to the next snapshot.
>> > >> My bad - the javap isn't being voted on yet. I was thinking of
>> the jdwp
>> > >> vote... sorry
>> > >>
>> > >>> So I propose adding a new top-level directory called "jdktools"
>> (and
>> > >>> rename "tools" to "project_tools") and create a build target that -
>> > >>> with a dependency on classlib for the launcher - creates the
>> 'stuff'
>> > >>> needed to fill into the JDK.
>> > >>>
>> > >>> Any comments?
>> > >>>
>> > >>> geir
>> > >>>
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>> --
>> Thank you.
>> Ilya Neverov,
>> Intel Middleware Products Division
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Mark Hindess wrote:
> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>> Ilya Neverov wrote:
>>> Hello,
>>>
>>> I want to gather opinions about structure of the "jdktools" component.
>>>
>>> I'm going to create scripts for moving tools' sources from classlib/
>>> to top-level directory jdktools/ and to prepare patches for build
>>> system for building tools from new place.
>> Cool
>>
>>> I think the following structure will be appropriate for future
>>> evolution of the jdktools:
>>>
>>> jdktools/trunk/
>>> build.xml
>>> make/
>> Can we stop persisting this mistake? Please call it "build" :)
>
> And call 'build' something else like 'target'?
Yes please!
>
> I'm not actually sure calling it build is a good idea because a number
> of common projects use build to contain built artifacts.
And many use "target".
> What is your
> objection to 'make'?
Why not "ant"? (joking)
Because 'make' just appears really unconventional to me.
>
>>> doc/
>>> modules/
>>> jre/ # keytool, tool launcher go here
>>> build.xml # classes go to jdk/jre/lib/tools.jar
>>> make/
>>> src/
>>> jdk/ # javac, jarsigner go here
>>> build.xml # classes go to jdk/lib/tools.jar
>>> make/
>>> src/
>>> jdwp/ # separate module for large component
>>> build.xml
>>> make/
>>> src/
>> Only comment is that we might want to pull the launcher out to be a
>> peer. Otherwise, I like it.
>
> I'd be a little tempted by that idea too.
it works with your idea from your other post of just pulling out as-is now.
>
>>> Assumptions which look reasonable for jdktool's build subsystem:
>>>
>>> 1) it works in presence of built classlib (as HDK binaries or as a
>>> result of classlib phase of overall build);
>> yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
>> I'd imagine the federated build to then have :
>>
>> trunk/
>> working_classlib/
>> working_vm/
>> working_jdktools/
>>
>>> 2) the 'jre' module is always built before building 'jdk' to provide
>>> generic tool launcher and the jre/lib/tools.jar. Probably it will be
>>> easy to obtain these items from HDK.
>> That's one reason why I'd pull the launcher out to it's own module
>>
>>> I'm rather newbie in the Harmony build system so your thoughts will be
>>> very helpful.
>> Ant and make will be your friends here :) Note that you will have
>> native issues (because of the launcher), so please track the way that
>> classlib does this wrt platforms to start, and if you find things that
>> work better, suggest it. Mark and Ollie are wizards here.
>>
>> I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64)
>> if you grok what I mean, and do it in a way that it will be trivial to
>> add other OSs or processor architectures (IPF, for example).
>
>> This might be a good place to figure out how this should work going
>> forward for harmony, rather than experimenting in classlib.
>
> +1
>
>>> Thank you
>> No, thank you :)
>
> +1
>
> Regards,
> Mark.
>
>> geir
>>
>>> -Ilya
>>>
>>>
>>> On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
>>>> Hi Geir,
>>>>
>>>> Looks like that creating the "jdktools" source tree and build was
>>>> shaded by other tasks. I can help with preparing and checking updates
>>>> in the build system. Please let me know what needs to do in this area
>>>> (besides svn commits) to complete the task.
>>>>
>>>> I'm especially interested in completing the move to "jdktools"
>>>> structure since there will be a home for the JDWP code, which has beed
>>>> voted but still resides in JIRA. Working with SVN will be easier.
>>>>
>>>> Thanks.
>>>> -Ilya
>>>>
>>>> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>>>> yep, that's the plan. And once we have that, we can simplify the
>>>>> launcher as well...
>>>>>
>>>>> Tim Ellison wrote:
>>>>>> +1 for creating a jdktools directory. The dependency on the classlib
>>>>>> launcher should be relatively light if we go with a simple tools
>>>>>> launcher that rewrites the tool invocation into a generic launcher
>>>>>> invocation. You may recall the idea was discussed a while ago.
>>>>>>
>>>>>> So, for example,
>>>>>> jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
>>>>>> is rewritten to
>>>>>> jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
>>>>>> org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>>>>>>
>>>>>> and so on.
>>>>>>
>>>>>> Regards,
>>>>>> Tim
>>>>>>
>>>>>> Geir Magnusson Jr. wrote:
>>>>>>> Geir Magnusson Jr. wrote:
>>>>>>>> Now that we have javac, javah, javap (if Tim votes ;) and
>>>> keytool, I'd
>>>>>>>> like to organize these and add them to the next snapshot.
>>>>>>> My bad - the javap isn't being voted on yet. I was thinking of
>>>> the jdwp
>>>>>>> vote... sorry
>>>>>>>
>>>>>>>> So I propose adding a new top-level directory called "jdktools"
>>>> (and
>>>>>>>> rename "tools" to "project_tools") and create a build target that -
>>>>>>>> with a dependency on classlib for the launcher - creates the
>>>> 'stuff'
>>>>>>>> needed to fill into the JDK.
>>>>>>>>
>>>>>>>> Any comments?
>>>>>>>>
>>>>>>>> geir
>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>>
>>>>>
>>>> --
>>>> Thank you.
>>>> Ilya Neverov,
>>>> Intel Middleware Products Division
>>>>
>
>
>
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
it's "build" in DRLVM, and "make" (invoked by the build.xml) in classlib.
It wouldn't be inconsistent.
geir
Ilya Neverov wrote:
> My perception of 'make' and 'build' names is similar to what Alexei
> described. I believe that for most people 'make' is a thing related to
> making/building process while 'build' is more ambiguous.
>
> Currently we have build system with many 'make/' dirs so it probably
> bettre to postpone the move to new name to some moment of
> restructuring the whole build system. I think today it's better to
> keep consistency.
>
> Thanks
> -Ilya
>
> On 10/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> I see. I'm familiar with "target" as the place for stuff that's
>> created...
>>
>> Alexei Zakharov wrote:
>> > In other words: I just wanted to say that the big number of java
>> > projects I've been working with was using "build[.<something>]" as a
>> > place for storing generated stuff like .class and .jar files,
>> > generated docs and etc.
>> >
>> > Regards,
>> >
>> > 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
>> >>
>> >>
>> >> Alexei Zakharov wrote:
>> >> > Take me for example. I will be most likely misleaded with "build"
>> >> > since the majority of projects I've seen in my life were using
>> "build"
>> >> > or "build.<platform>" for storing build artifacts (as Mark said). I
>> >> > agree it is logically to call it "build". But "make" is logical too.
>> >> > "ant" or "ant.scripts" also sound not so bad. Why not to choose the
>> >> > less confusing name?
>> >>
>> >> (I believe you meant "make" or "make.<platform>")
>> >>
>> >> What projects? Java projects?
>> >>
>> >> >
>> >> > With best regards,
>> >> >
>> >> > 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
>> >> >> Why? I'm really curious about this. We "build" the project, using
>> >> the
>> >> >> "build.xml" file with Ant.
>> >> >>
>> >> >>
>> >> >> Ilya Neverov wrote:
>> >> >> > I would prefer to keep the current name "make" for directories
>> >> related
>> >> >> > to build system. For me it looks natural; at least it looks less
>> >> >> > misleading than "build" :)
>> >> >> >
>> >> >> > -Ilya
>> >> >> >
>> >> >> > On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>> >> >> >>
>> >> >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr."
>> <ge...@pobox.com>
>> >> >> wrote:
>> >> >> >> >
>> >> >> >> > Ilya Neverov wrote:
>> >> >> >> > > Hello,
>> >> >> >> > >
>> >> >> >> > > I want to gather opinions about structure of the "jdktools"
>> >> >> >> component.
>> >> >> >> > >
>> >> >> >> > > I'm going to create scripts for moving tools' sources from
>> >> >> classlib/
>> >> >> >> > > to top-level directory jdktools/ and to prepare patches for
>> >> build
>> >> >> >> > > system for building tools from new place.
>> >> >> >> >
>> >> >> >> > Cool
>> >> >> >> >
>> >> >> >> > >
>> >> >> >> > > I think the following structure will be appropriate for
>> future
>> >> >> >> > > evolution of the jdktools:
>> >> >> >> > >
>> >> >> >> > > jdktools/trunk/
>> >> >> >> > > build.xml
>> >> >> >> > > make/
>> >> >> >> >
>> >> >> >> > Can we stop persisting this mistake? Please call it
>> "build" :)
>> >> >> >>
>> >> >> >> And call 'build' something else like 'target'?
>> >> >> >>
>> >> >> >> I'm not actually sure calling it build is a good idea because a
>> >> number
>> >> >> >> of common projects use build to contain built artifacts. What
>> >> is your
>> >> >> >> objection to 'make'?
>> >> >> >>
>> >> >> >> > > doc/
>> >> >> >> > > modules/
>> >> >> >> > > jre/ # keytool, tool
>> launcher go
>> >> >> here
>> >> >> >> > > build.xml # classes go to
>> >> >> >> jdk/jre/lib/tools.jar
>> >> >> >> > > make/
>> >> >> >> > > src/
>> >> >> >> > > jdk/ # javac, jarsigner go
>> here
>> >> >> >> > > build.xml # classes go to
>> >> >> jdk/lib/tools.jar
>> >> >> >> > > make/
>> >> >> >> > > src/
>> >> >> >> > > jdwp/ # separate module for
>> large
>> >> >> >> component
>> >> >> >> > > build.xml
>> >> >> >> > > make/
>> >> >> >> > > src/
>> >> >> >> >
>> >> >> >> > Only comment is that we might want to pull the launcher out to
>> >> be a
>> >> >> >> > peer. Otherwise, I like it.
>> >> >> >>
>> >> >> >> I'd be a little tempted by that idea too.
>> >> >> >>
>> >> >> >> > >
>> >> >> >> > > Assumptions which look reasonable for jdktool's build
>> >> subsystem:
>> >> >> >> > >
>> >> >> >> > > 1) it works in presence of built classlib (as HDK binaries
>> >> or as a
>> >> >> >> > > result of classlib phase of overall build);
>> >> >> >> >
>> >> >> >> > yes - think of the same trick we do w/ DRLVM to "reach over"
>> >> to find
>> >> >> >> it.
>> >> >> >> > I'd imagine the federated build to then have :
>> >> >> >> >
>> >> >> >> > trunk/
>> >> >> >> > working_classlib/
>> >> >> >> > working_vm/
>> >> >> >> > working_jdktools/
>> >> >> >> >
>> >> >> >> > > 2) the 'jre' module is always built before building 'jdk' to
>> >> >> provide
>> >> >> >> > > generic tool launcher and the jre/lib/tools.jar. Probably it
>> >> >> will be
>> >> >> >> > > easy to obtain these items from HDK.
>> >> >> >> >
>> >> >> >> > That's one reason why I'd pull the launcher out to it's own
>> >> module
>> >> >> >> >
>> >> >> >> > >
>> >> >> >> > > I'm rather newbie in the Harmony build system so your
>> thoughts
>> >> >> >> will be
>> >> >> >> > > very helpful.
>> >> >> >> >
>> >> >> >> > Ant and make will be your friends here :) Note that you will
>> >> have
>> >> >> >> > native issues (because of the launcher), so please track
>> the way
>> >> >> that
>> >> >> >> > classlib does this wrt platforms to start, and if you find
>> things
>> >> >> that
>> >> >> >> > work better, suggest it. Mark and Ollie are wizards here.
>> >> >> >> >
>> >> >> >> > I'd suggest starting out to accommodate (windows,linux) X
>> (x86,
>> >> >> x86_64)
>> >> >> >> > if you grok what I mean, and do it in a way that it will be
>> >> >> trivial to
>> >> >> >> > add other OSs or processor architectures (IPF, for example).
>> >> >> >>
>> >> >> >> > This might be a good place to figure out how this should work
>> >> going
>> >> >> >> > forward for harmony, rather than experimenting in classlib.
>> >> >> >>
>> >> >> >> +1
>> >> >> >>
>> >> >> >> > >
>> >> >> >> > > Thank you
>> >> >> >> >
>> >> >> >> > No, thank you :)
>> >> >> >>
>> >> >> >> +1
>> >> >> >>
>> >> >> >> Regards,
>> >> >> >> Mark.
>> >> >> >>
>> >> >> >> > geir
>> >> >> >> >
>> >> >> >> > > -Ilya
>> >> >> >> > >
>> >> >> >> > >
>> >> >> >> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
>> >> >> >> > >> Hi Geir,
>> >> >> >> > >>
>> >> >> >> > >> Looks like that creating the "jdktools" source tree and
>> >> build was
>> >> >> >> > >> shaded by other tasks. I can help with preparing and
>> checking
>> >> >> >> updates
>> >> >> >> > >> in the build system. Please let me know what needs to do in
>> >> this
>> >> >> >> area
>> >> >> >> > >> (besides svn commits) to complete the task.
>> >> >> >> > >>
>> >> >> >> > >> I'm especially interested in completing the move to
>> "jdktools"
>> >> >> >> > >> structure since there will be a home for the JDWP code,
>> >> which has
>> >> >> >> beed
>> >> >> >> > >> voted but still resides in JIRA. Working with SVN will be
>> >> easier.
>> >> >> >> > >>
>> >> >> >> > >> Thanks.
>> >> >> >> > >> -Ilya
>> >> >> >> > >>
>> >> >> >> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> >> >> > >> > yep, that's the plan. And once we have that, we can
>> >> >> simplify the
>> >> >> >> > >> > launcher as well...
>> >> >> >> > >> >
>> >> >> >> > >> > Tim Ellison wrote:
>> >> >> >> > >> > > +1 for creating a jdktools directory. The dependency
>> >> on the
>> >> >> >> classlib
>> >> >> >> > >> > > launcher should be relatively light if we go with a
>> simple
>> >> >> tools
>> >> >> >> > >> > > launcher that rewrites the tool invocation into a
>> generic
>> >> >> >> launcher
>> >> >> >> > >> > > invocation. You may recall the idea was discussed a
>> while
>> >> >> ago.
>> >> >> >> > >> > >
>> >> >> >> > >> > > So, for example,
>> >> >> >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
>> >> >> >> > >> > > is rewritten to
>> >> >> >> > >> > > jdk/jre/bin/java -cp
>> jdk/lib/tools.jar;jdk/lib/ecj.jar
>> >> >> >> -Xmx200M
>> >> >> >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>> >> >> >> > >> > >
>> >> >> >> > >> > > and so on.
>> >> >> >> > >> > >
>> >> >> >> > >> > > Regards,
>> >> >> >> > >> > > Tim
>> >> >> >> > >> > >
>> >> >> >> > >> > > Geir Magnusson Jr. wrote:
>> >> >> >> > >> > >> Geir Magnusson Jr. wrote:
>> >> >> >> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;)
>> >> and
>> >> >> >> > >> keytool, I'd
>> >> >> >> > >> > >>> like to organize these and add them to the next
>> >> snapshot.
>> >> >> >> > >> > >> My bad - the javap isn't being voted on yet. I was
>> >> >> thinking of
>> >> >> >> > >> the jdwp
>> >> >> >> > >> > >> vote... sorry
>> >> >> >> > >> > >>
>> >> >> >> > >> > >>> So I propose adding a new top-level directory called
>> >> >> >> "jdktools"
>> >> >> >> > >> (and
>> >> >> >> > >> > >>> rename "tools" to "project_tools") and create a build
>> >> >> >> target that -
>> >> >> >> > >> > >>> with a dependency on classlib for the launcher -
>> >> >> creates the
>> >> >> >> > >> 'stuff'
>> >> >> >> > >> > >>> needed to fill into the JDK.
>> >> >> >> > >> > >>>
>> >> >> >> > >> > >>> Any comments?
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
Re: [general] creation of "jdktools"
Posted by Ilya Neverov <il...@gmail.com>.
My perception of 'make' and 'build' names is similar to what Alexei
described. I believe that for most people 'make' is a thing related to
making/building process while 'build' is more ambiguous.
Currently we have build system with many 'make/' dirs so it probably
bettre to postpone the move to new name to some moment of
restructuring the whole build system. I think today it's better to
keep consistency.
Thanks
-Ilya
On 10/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> I see. I'm familiar with "target" as the place for stuff that's created...
>
> Alexei Zakharov wrote:
> > In other words: I just wanted to say that the big number of java
> > projects I've been working with was using "build[.<something>]" as a
> > place for storing generated stuff like .class and .jar files,
> > generated docs and etc.
> >
> > Regards,
> >
> > 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
> >>
> >>
> >> Alexei Zakharov wrote:
> >> > Take me for example. I will be most likely misleaded with "build"
> >> > since the majority of projects I've seen in my life were using "build"
> >> > or "build.<platform>" for storing build artifacts (as Mark said). I
> >> > agree it is logically to call it "build". But "make" is logical too.
> >> > "ant" or "ant.scripts" also sound not so bad. Why not to choose the
> >> > less confusing name?
> >>
> >> (I believe you meant "make" or "make.<platform>")
> >>
> >> What projects? Java projects?
> >>
> >> >
> >> > With best regards,
> >> >
> >> > 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
> >> >> Why? I'm really curious about this. We "build" the project, using
> >> the
> >> >> "build.xml" file with Ant.
> >> >>
> >> >>
> >> >> Ilya Neverov wrote:
> >> >> > I would prefer to keep the current name "make" for directories
> >> related
> >> >> > to build system. For me it looks natural; at least it looks less
> >> >> > misleading than "build" :)
> >> >> >
> >> >> > -Ilya
> >> >> >
> >> >> > On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
> >> >> >>
> >> >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com>
> >> >> wrote:
> >> >> >> >
> >> >> >> > Ilya Neverov wrote:
> >> >> >> > > Hello,
> >> >> >> > >
> >> >> >> > > I want to gather opinions about structure of the "jdktools"
> >> >> >> component.
> >> >> >> > >
> >> >> >> > > I'm going to create scripts for moving tools' sources from
> >> >> classlib/
> >> >> >> > > to top-level directory jdktools/ and to prepare patches for
> >> build
> >> >> >> > > system for building tools from new place.
> >> >> >> >
> >> >> >> > Cool
> >> >> >> >
> >> >> >> > >
> >> >> >> > > I think the following structure will be appropriate for future
> >> >> >> > > evolution of the jdktools:
> >> >> >> > >
> >> >> >> > > jdktools/trunk/
> >> >> >> > > build.xml
> >> >> >> > > make/
> >> >> >> >
> >> >> >> > Can we stop persisting this mistake? Please call it "build" :)
> >> >> >>
> >> >> >> And call 'build' something else like 'target'?
> >> >> >>
> >> >> >> I'm not actually sure calling it build is a good idea because a
> >> number
> >> >> >> of common projects use build to contain built artifacts. What
> >> is your
> >> >> >> objection to 'make'?
> >> >> >>
> >> >> >> > > doc/
> >> >> >> > > modules/
> >> >> >> > > jre/ # keytool, tool launcher go
> >> >> here
> >> >> >> > > build.xml # classes go to
> >> >> >> jdk/jre/lib/tools.jar
> >> >> >> > > make/
> >> >> >> > > src/
> >> >> >> > > jdk/ # javac, jarsigner go here
> >> >> >> > > build.xml # classes go to
> >> >> jdk/lib/tools.jar
> >> >> >> > > make/
> >> >> >> > > src/
> >> >> >> > > jdwp/ # separate module for large
> >> >> >> component
> >> >> >> > > build.xml
> >> >> >> > > make/
> >> >> >> > > src/
> >> >> >> >
> >> >> >> > Only comment is that we might want to pull the launcher out to
> >> be a
> >> >> >> > peer. Otherwise, I like it.
> >> >> >>
> >> >> >> I'd be a little tempted by that idea too.
> >> >> >>
> >> >> >> > >
> >> >> >> > > Assumptions which look reasonable for jdktool's build
> >> subsystem:
> >> >> >> > >
> >> >> >> > > 1) it works in presence of built classlib (as HDK binaries
> >> or as a
> >> >> >> > > result of classlib phase of overall build);
> >> >> >> >
> >> >> >> > yes - think of the same trick we do w/ DRLVM to "reach over"
> >> to find
> >> >> >> it.
> >> >> >> > I'd imagine the federated build to then have :
> >> >> >> >
> >> >> >> > trunk/
> >> >> >> > working_classlib/
> >> >> >> > working_vm/
> >> >> >> > working_jdktools/
> >> >> >> >
> >> >> >> > > 2) the 'jre' module is always built before building 'jdk' to
> >> >> provide
> >> >> >> > > generic tool launcher and the jre/lib/tools.jar. Probably it
> >> >> will be
> >> >> >> > > easy to obtain these items from HDK.
> >> >> >> >
> >> >> >> > That's one reason why I'd pull the launcher out to it's own
> >> module
> >> >> >> >
> >> >> >> > >
> >> >> >> > > I'm rather newbie in the Harmony build system so your thoughts
> >> >> >> will be
> >> >> >> > > very helpful.
> >> >> >> >
> >> >> >> > Ant and make will be your friends here :) Note that you will
> >> have
> >> >> >> > native issues (because of the launcher), so please track the way
> >> >> that
> >> >> >> > classlib does this wrt platforms to start, and if you find things
> >> >> that
> >> >> >> > work better, suggest it. Mark and Ollie are wizards here.
> >> >> >> >
> >> >> >> > I'd suggest starting out to accommodate (windows,linux) X (x86,
> >> >> x86_64)
> >> >> >> > if you grok what I mean, and do it in a way that it will be
> >> >> trivial to
> >> >> >> > add other OSs or processor architectures (IPF, for example).
> >> >> >>
> >> >> >> > This might be a good place to figure out how this should work
> >> going
> >> >> >> > forward for harmony, rather than experimenting in classlib.
> >> >> >>
> >> >> >> +1
> >> >> >>
> >> >> >> > >
> >> >> >> > > Thank you
> >> >> >> >
> >> >> >> > No, thank you :)
> >> >> >>
> >> >> >> +1
> >> >> >>
> >> >> >> Regards,
> >> >> >> Mark.
> >> >> >>
> >> >> >> > geir
> >> >> >> >
> >> >> >> > > -Ilya
> >> >> >> > >
> >> >> >> > >
> >> >> >> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
> >> >> >> > >> Hi Geir,
> >> >> >> > >>
> >> >> >> > >> Looks like that creating the "jdktools" source tree and
> >> build was
> >> >> >> > >> shaded by other tasks. I can help with preparing and checking
> >> >> >> updates
> >> >> >> > >> in the build system. Please let me know what needs to do in
> >> this
> >> >> >> area
> >> >> >> > >> (besides svn commits) to complete the task.
> >> >> >> > >>
> >> >> >> > >> I'm especially interested in completing the move to "jdktools"
> >> >> >> > >> structure since there will be a home for the JDWP code,
> >> which has
> >> >> >> beed
> >> >> >> > >> voted but still resides in JIRA. Working with SVN will be
> >> easier.
> >> >> >> > >>
> >> >> >> > >> Thanks.
> >> >> >> > >> -Ilya
> >> >> >> > >>
> >> >> >> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> >> >> > >> > yep, that's the plan. And once we have that, we can
> >> >> simplify the
> >> >> >> > >> > launcher as well...
> >> >> >> > >> >
> >> >> >> > >> > Tim Ellison wrote:
> >> >> >> > >> > > +1 for creating a jdktools directory. The dependency
> >> on the
> >> >> >> classlib
> >> >> >> > >> > > launcher should be relatively light if we go with a simple
> >> >> tools
> >> >> >> > >> > > launcher that rewrites the tool invocation into a generic
> >> >> >> launcher
> >> >> >> > >> > > invocation. You may recall the idea was discussed a while
> >> >> ago.
> >> >> >> > >> > >
> >> >> >> > >> > > So, for example,
> >> >> >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> >> >> >> > >> > > is rewritten to
> >> >> >> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar
> >> >> >> -Xmx200M
> >> >> >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> >> >> >> > >> > >
> >> >> >> > >> > > and so on.
> >> >> >> > >> > >
> >> >> >> > >> > > Regards,
> >> >> >> > >> > > Tim
> >> >> >> > >> > >
> >> >> >> > >> > > Geir Magnusson Jr. wrote:
> >> >> >> > >> > >> Geir Magnusson Jr. wrote:
> >> >> >> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;)
> >> and
> >> >> >> > >> keytool, I'd
> >> >> >> > >> > >>> like to organize these and add them to the next
> >> snapshot.
> >> >> >> > >> > >> My bad - the javap isn't being voted on yet. I was
> >> >> thinking of
> >> >> >> > >> the jdwp
> >> >> >> > >> > >> vote... sorry
> >> >> >> > >> > >>
> >> >> >> > >> > >>> So I propose adding a new top-level directory called
> >> >> >> "jdktools"
> >> >> >> > >> (and
> >> >> >> > >> > >>> rename "tools" to "project_tools") and create a build
> >> >> >> target that -
> >> >> >> > >> > >>> with a dependency on classlib for the launcher -
> >> >> creates the
> >> >> >> > >> 'stuff'
> >> >> >> > >> > >>> needed to fill into the JDK.
> >> >> >> > >> > >>>
> >> >> >> > >> > >>> Any comments?
> >> >
> >> >
> >>
> >
> >
>
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I see. I'm familiar with "target" as the place for stuff that's created...
Alexei Zakharov wrote:
> In other words: I just wanted to say that the big number of java
> projects I've been working with was using "build[.<something>]" as a
> place for storing generated stuff like .class and .jar files,
> generated docs and etc.
>
> Regards,
>
> 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> Alexei Zakharov wrote:
>> > Take me for example. I will be most likely misleaded with "build"
>> > since the majority of projects I've seen in my life were using "build"
>> > or "build.<platform>" for storing build artifacts (as Mark said). I
>> > agree it is logically to call it "build". But "make" is logical too.
>> > "ant" or "ant.scripts" also sound not so bad. Why not to choose the
>> > less confusing name?
>>
>> (I believe you meant "make" or "make.<platform>")
>>
>> What projects? Java projects?
>>
>> >
>> > With best regards,
>> >
>> > 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
>> >> Why? I'm really curious about this. We "build" the project, using
>> the
>> >> "build.xml" file with Ant.
>> >>
>> >>
>> >> Ilya Neverov wrote:
>> >> > I would prefer to keep the current name "make" for directories
>> related
>> >> > to build system. For me it looks natural; at least it looks less
>> >> > misleading than "build" :)
>> >> >
>> >> > -Ilya
>> >> >
>> >> > On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>> >> >>
>> >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com>
>> >> wrote:
>> >> >> >
>> >> >> > Ilya Neverov wrote:
>> >> >> > > Hello,
>> >> >> > >
>> >> >> > > I want to gather opinions about structure of the "jdktools"
>> >> >> component.
>> >> >> > >
>> >> >> > > I'm going to create scripts for moving tools' sources from
>> >> classlib/
>> >> >> > > to top-level directory jdktools/ and to prepare patches for
>> build
>> >> >> > > system for building tools from new place.
>> >> >> >
>> >> >> > Cool
>> >> >> >
>> >> >> > >
>> >> >> > > I think the following structure will be appropriate for future
>> >> >> > > evolution of the jdktools:
>> >> >> > >
>> >> >> > > jdktools/trunk/
>> >> >> > > build.xml
>> >> >> > > make/
>> >> >> >
>> >> >> > Can we stop persisting this mistake? Please call it "build" :)
>> >> >>
>> >> >> And call 'build' something else like 'target'?
>> >> >>
>> >> >> I'm not actually sure calling it build is a good idea because a
>> number
>> >> >> of common projects use build to contain built artifacts. What
>> is your
>> >> >> objection to 'make'?
>> >> >>
>> >> >> > > doc/
>> >> >> > > modules/
>> >> >> > > jre/ # keytool, tool launcher go
>> >> here
>> >> >> > > build.xml # classes go to
>> >> >> jdk/jre/lib/tools.jar
>> >> >> > > make/
>> >> >> > > src/
>> >> >> > > jdk/ # javac, jarsigner go here
>> >> >> > > build.xml # classes go to
>> >> jdk/lib/tools.jar
>> >> >> > > make/
>> >> >> > > src/
>> >> >> > > jdwp/ # separate module for large
>> >> >> component
>> >> >> > > build.xml
>> >> >> > > make/
>> >> >> > > src/
>> >> >> >
>> >> >> > Only comment is that we might want to pull the launcher out to
>> be a
>> >> >> > peer. Otherwise, I like it.
>> >> >>
>> >> >> I'd be a little tempted by that idea too.
>> >> >>
>> >> >> > >
>> >> >> > > Assumptions which look reasonable for jdktool's build
>> subsystem:
>> >> >> > >
>> >> >> > > 1) it works in presence of built classlib (as HDK binaries
>> or as a
>> >> >> > > result of classlib phase of overall build);
>> >> >> >
>> >> >> > yes - think of the same trick we do w/ DRLVM to "reach over"
>> to find
>> >> >> it.
>> >> >> > I'd imagine the federated build to then have :
>> >> >> >
>> >> >> > trunk/
>> >> >> > working_classlib/
>> >> >> > working_vm/
>> >> >> > working_jdktools/
>> >> >> >
>> >> >> > > 2) the 'jre' module is always built before building 'jdk' to
>> >> provide
>> >> >> > > generic tool launcher and the jre/lib/tools.jar. Probably it
>> >> will be
>> >> >> > > easy to obtain these items from HDK.
>> >> >> >
>> >> >> > That's one reason why I'd pull the launcher out to it's own
>> module
>> >> >> >
>> >> >> > >
>> >> >> > > I'm rather newbie in the Harmony build system so your thoughts
>> >> >> will be
>> >> >> > > very helpful.
>> >> >> >
>> >> >> > Ant and make will be your friends here :) Note that you will
>> have
>> >> >> > native issues (because of the launcher), so please track the way
>> >> that
>> >> >> > classlib does this wrt platforms to start, and if you find things
>> >> that
>> >> >> > work better, suggest it. Mark and Ollie are wizards here.
>> >> >> >
>> >> >> > I'd suggest starting out to accommodate (windows,linux) X (x86,
>> >> x86_64)
>> >> >> > if you grok what I mean, and do it in a way that it will be
>> >> trivial to
>> >> >> > add other OSs or processor architectures (IPF, for example).
>> >> >>
>> >> >> > This might be a good place to figure out how this should work
>> going
>> >> >> > forward for harmony, rather than experimenting in classlib.
>> >> >>
>> >> >> +1
>> >> >>
>> >> >> > >
>> >> >> > > Thank you
>> >> >> >
>> >> >> > No, thank you :)
>> >> >>
>> >> >> +1
>> >> >>
>> >> >> Regards,
>> >> >> Mark.
>> >> >>
>> >> >> > geir
>> >> >> >
>> >> >> > > -Ilya
>> >> >> > >
>> >> >> > >
>> >> >> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
>> >> >> > >> Hi Geir,
>> >> >> > >>
>> >> >> > >> Looks like that creating the "jdktools" source tree and
>> build was
>> >> >> > >> shaded by other tasks. I can help with preparing and checking
>> >> >> updates
>> >> >> > >> in the build system. Please let me know what needs to do in
>> this
>> >> >> area
>> >> >> > >> (besides svn commits) to complete the task.
>> >> >> > >>
>> >> >> > >> I'm especially interested in completing the move to "jdktools"
>> >> >> > >> structure since there will be a home for the JDWP code,
>> which has
>> >> >> beed
>> >> >> > >> voted but still resides in JIRA. Working with SVN will be
>> easier.
>> >> >> > >>
>> >> >> > >> Thanks.
>> >> >> > >> -Ilya
>> >> >> > >>
>> >> >> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> >> > >> > yep, that's the plan. And once we have that, we can
>> >> simplify the
>> >> >> > >> > launcher as well...
>> >> >> > >> >
>> >> >> > >> > Tim Ellison wrote:
>> >> >> > >> > > +1 for creating a jdktools directory. The dependency
>> on the
>> >> >> classlib
>> >> >> > >> > > launcher should be relatively light if we go with a simple
>> >> tools
>> >> >> > >> > > launcher that rewrites the tool invocation into a generic
>> >> >> launcher
>> >> >> > >> > > invocation. You may recall the idea was discussed a while
>> >> ago.
>> >> >> > >> > >
>> >> >> > >> > > So, for example,
>> >> >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
>> >> >> > >> > > is rewritten to
>> >> >> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar
>> >> >> -Xmx200M
>> >> >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>> >> >> > >> > >
>> >> >> > >> > > and so on.
>> >> >> > >> > >
>> >> >> > >> > > Regards,
>> >> >> > >> > > Tim
>> >> >> > >> > >
>> >> >> > >> > > Geir Magnusson Jr. wrote:
>> >> >> > >> > >> Geir Magnusson Jr. wrote:
>> >> >> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;)
>> and
>> >> >> > >> keytool, I'd
>> >> >> > >> > >>> like to organize these and add them to the next
>> snapshot.
>> >> >> > >> > >> My bad - the javap isn't being voted on yet. I was
>> >> thinking of
>> >> >> > >> the jdwp
>> >> >> > >> > >> vote... sorry
>> >> >> > >> > >>
>> >> >> > >> > >>> So I propose adding a new top-level directory called
>> >> >> "jdktools"
>> >> >> > >> (and
>> >> >> > >> > >>> rename "tools" to "project_tools") and create a build
>> >> >> target that -
>> >> >> > >> > >>> with a dependency on classlib for the launcher -
>> >> creates the
>> >> >> > >> 'stuff'
>> >> >> > >> > >>> needed to fill into the JDK.
>> >> >> > >> > >>>
>> >> >> > >> > >>> Any comments?
>> >
>> >
>>
>
>
Re: [general] creation of "jdktools"
Posted by Alexei Zakharov <al...@gmail.com>.
In other words: I just wanted to say that the big number of java
projects I've been working with was using "build[.<something>]" as a
place for storing generated stuff like .class and .jar files,
generated docs and etc.
Regards,
2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Alexei Zakharov wrote:
> > Take me for example. I will be most likely misleaded with "build"
> > since the majority of projects I've seen in my life were using "build"
> > or "build.<platform>" for storing build artifacts (as Mark said). I
> > agree it is logically to call it "build". But "make" is logical too.
> > "ant" or "ant.scripts" also sound not so bad. Why not to choose the
> > less confusing name?
>
> (I believe you meant "make" or "make.<platform>")
>
> What projects? Java projects?
>
> >
> > With best regards,
> >
> > 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
> >> Why? I'm really curious about this. We "build" the project, using the
> >> "build.xml" file with Ant.
> >>
> >>
> >> Ilya Neverov wrote:
> >> > I would prefer to keep the current name "make" for directories related
> >> > to build system. For me it looks natural; at least it looks less
> >> > misleading than "build" :)
> >> >
> >> > -Ilya
> >> >
> >> > On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
> >> >>
> >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com>
> >> wrote:
> >> >> >
> >> >> > Ilya Neverov wrote:
> >> >> > > Hello,
> >> >> > >
> >> >> > > I want to gather opinions about structure of the "jdktools"
> >> >> component.
> >> >> > >
> >> >> > > I'm going to create scripts for moving tools' sources from
> >> classlib/
> >> >> > > to top-level directory jdktools/ and to prepare patches for build
> >> >> > > system for building tools from new place.
> >> >> >
> >> >> > Cool
> >> >> >
> >> >> > >
> >> >> > > I think the following structure will be appropriate for future
> >> >> > > evolution of the jdktools:
> >> >> > >
> >> >> > > jdktools/trunk/
> >> >> > > build.xml
> >> >> > > make/
> >> >> >
> >> >> > Can we stop persisting this mistake? Please call it "build" :)
> >> >>
> >> >> And call 'build' something else like 'target'?
> >> >>
> >> >> I'm not actually sure calling it build is a good idea because a number
> >> >> of common projects use build to contain built artifacts. What is your
> >> >> objection to 'make'?
> >> >>
> >> >> > > doc/
> >> >> > > modules/
> >> >> > > jre/ # keytool, tool launcher go
> >> here
> >> >> > > build.xml # classes go to
> >> >> jdk/jre/lib/tools.jar
> >> >> > > make/
> >> >> > > src/
> >> >> > > jdk/ # javac, jarsigner go here
> >> >> > > build.xml # classes go to
> >> jdk/lib/tools.jar
> >> >> > > make/
> >> >> > > src/
> >> >> > > jdwp/ # separate module for large
> >> >> component
> >> >> > > build.xml
> >> >> > > make/
> >> >> > > src/
> >> >> >
> >> >> > Only comment is that we might want to pull the launcher out to be a
> >> >> > peer. Otherwise, I like it.
> >> >>
> >> >> I'd be a little tempted by that idea too.
> >> >>
> >> >> > >
> >> >> > > Assumptions which look reasonable for jdktool's build subsystem:
> >> >> > >
> >> >> > > 1) it works in presence of built classlib (as HDK binaries or as a
> >> >> > > result of classlib phase of overall build);
> >> >> >
> >> >> > yes - think of the same trick we do w/ DRLVM to "reach over" to find
> >> >> it.
> >> >> > I'd imagine the federated build to then have :
> >> >> >
> >> >> > trunk/
> >> >> > working_classlib/
> >> >> > working_vm/
> >> >> > working_jdktools/
> >> >> >
> >> >> > > 2) the 'jre' module is always built before building 'jdk' to
> >> provide
> >> >> > > generic tool launcher and the jre/lib/tools.jar. Probably it
> >> will be
> >> >> > > easy to obtain these items from HDK.
> >> >> >
> >> >> > That's one reason why I'd pull the launcher out to it's own module
> >> >> >
> >> >> > >
> >> >> > > I'm rather newbie in the Harmony build system so your thoughts
> >> >> will be
> >> >> > > very helpful.
> >> >> >
> >> >> > Ant and make will be your friends here :) Note that you will have
> >> >> > native issues (because of the launcher), so please track the way
> >> that
> >> >> > classlib does this wrt platforms to start, and if you find things
> >> that
> >> >> > work better, suggest it. Mark and Ollie are wizards here.
> >> >> >
> >> >> > I'd suggest starting out to accommodate (windows,linux) X (x86,
> >> x86_64)
> >> >> > if you grok what I mean, and do it in a way that it will be
> >> trivial to
> >> >> > add other OSs or processor architectures (IPF, for example).
> >> >>
> >> >> > This might be a good place to figure out how this should work going
> >> >> > forward for harmony, rather than experimenting in classlib.
> >> >>
> >> >> +1
> >> >>
> >> >> > >
> >> >> > > Thank you
> >> >> >
> >> >> > No, thank you :)
> >> >>
> >> >> +1
> >> >>
> >> >> Regards,
> >> >> Mark.
> >> >>
> >> >> > geir
> >> >> >
> >> >> > > -Ilya
> >> >> > >
> >> >> > >
> >> >> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
> >> >> > >> Hi Geir,
> >> >> > >>
> >> >> > >> Looks like that creating the "jdktools" source tree and build was
> >> >> > >> shaded by other tasks. I can help with preparing and checking
> >> >> updates
> >> >> > >> in the build system. Please let me know what needs to do in this
> >> >> area
> >> >> > >> (besides svn commits) to complete the task.
> >> >> > >>
> >> >> > >> I'm especially interested in completing the move to "jdktools"
> >> >> > >> structure since there will be a home for the JDWP code, which has
> >> >> beed
> >> >> > >> voted but still resides in JIRA. Working with SVN will be easier.
> >> >> > >>
> >> >> > >> Thanks.
> >> >> > >> -Ilya
> >> >> > >>
> >> >> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> >> > >> > yep, that's the plan. And once we have that, we can
> >> simplify the
> >> >> > >> > launcher as well...
> >> >> > >> >
> >> >> > >> > Tim Ellison wrote:
> >> >> > >> > > +1 for creating a jdktools directory. The dependency on the
> >> >> classlib
> >> >> > >> > > launcher should be relatively light if we go with a simple
> >> tools
> >> >> > >> > > launcher that rewrites the tool invocation into a generic
> >> >> launcher
> >> >> > >> > > invocation. You may recall the idea was discussed a while
> >> ago.
> >> >> > >> > >
> >> >> > >> > > So, for example,
> >> >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> >> >> > >> > > is rewritten to
> >> >> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar
> >> >> -Xmx200M
> >> >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> >> >> > >> > >
> >> >> > >> > > and so on.
> >> >> > >> > >
> >> >> > >> > > Regards,
> >> >> > >> > > Tim
> >> >> > >> > >
> >> >> > >> > > Geir Magnusson Jr. wrote:
> >> >> > >> > >> Geir Magnusson Jr. wrote:
> >> >> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
> >> >> > >> keytool, I'd
> >> >> > >> > >>> like to organize these and add them to the next snapshot.
> >> >> > >> > >> My bad - the javap isn't being voted on yet. I was
> >> thinking of
> >> >> > >> the jdwp
> >> >> > >> > >> vote... sorry
> >> >> > >> > >>
> >> >> > >> > >>> So I propose adding a new top-level directory called
> >> >> "jdktools"
> >> >> > >> (and
> >> >> > >> > >>> rename "tools" to "project_tools") and create a build
> >> >> target that -
> >> >> > >> > >>> with a dependency on classlib for the launcher -
> >> creates the
> >> >> > >> 'stuff'
> >> >> > >> > >>> needed to fill into the JDK.
> >> >> > >> > >>>
> >> >> > >> > >>> Any comments?
> >
> >
>
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Nathan Beyer wrote:
> On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>>
>> On 31 October 2006 at 7:24, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>> >
>> >
>> > Alexei Zakharov wrote:
>> > > Take me for example. I will be most likely misleaded with "build"
>> > > since the majority of projects I've seen in my life were using
>> "build"
>> > > or "build.<platform>" for storing build artifacts (as Mark said). I
>> > > agree it is logically to call it "build". But "make" is logical too.
>> > > "ant" or "ant.scripts" also sound not so bad. Why not to choose the
>> > > less confusing name?
>> >
>> > (I believe you meant "make" or "make.<platform>")
>> >
>> > What projects? Java projects?
>>
>> ?
>>
>> Apache Jakarta Commons Collections uses build/classes and build/tests
>> for artifacts... just like classlib does.
>>
>> -Mark.
>
> Every project that uses Maven 2 (including the Maven projects
> themselves) use "target" as the general output directory,
> "target/classes" as the compiled output (class files and resources)
> and "target/test-classes" as the compiled test output (class files and
> resources). The build instructions (script) is just placed in the root
> of the project.
>
> This is the default behavior of an minimally configured Maven 2
> project, which is supposedly based on the ASF best practices. If we're
> trying to converge on a common structure, I'd suggest following the
> conventions of the Maven 2 system.
As you noted, the maven 2 approach came from best practices, not the
other way around.
I felt that needed to be restated ;)
geir
>
> -Nathan
>
>
>>
>> > >
>> > > With best regards,
>> > >
>> > > 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
>> > >> Why? I'm really curious about this. We "build" the project,
>> using the
>> > >> "build.xml" file with Ant.
>> > >>
>> > >>
>> > >> Ilya Neverov wrote:
>> > >> > I would prefer to keep the current name "make" for directories
>> related
>> > >> > to build system. For me it looks natural; at least it looks less
>> > >> > misleading than "build" :)
>> > >> >
>> > >> > -Ilya
>> > >> >
>> > >> > On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>> > >> >>
>> > >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr."
>> <ge...@pobox.com>
>> > >> wrote:
>> > >> >> >
>> > >> >> > Ilya Neverov wrote:
>> > >> >> > > Hello,
>> > >> >> > >
>> > >> >> > > I want to gather opinions about structure of the "jdktools"
>> > >> >> component.
>> > >> >> > >
>> > >> >> > > I'm going to create scripts for moving tools' sources from
>> > >> classlib/
>> > >> >> > > to top-level directory jdktools/ and to prepare patches
>> for build
>> > >> >> > > system for building tools from new place.
>> > >> >> >
>> > >> >> > Cool
>> > >> >> >
>> > >> >> > >
>> > >> >> > > I think the following structure will be appropriate for
>> future
>> > >> >> > > evolution of the jdktools:
>> > >> >> > >
>> > >> >> > > jdktools/trunk/
>> > >> >> > > build.xml
>> > >> >> > > make/
>> > >> >> >
>> > >> >> > Can we stop persisting this mistake? Please call it "build" :)
>> > >> >>
>> > >> >> And call 'build' something else like 'target'?
>> > >> >>
>> > >> >> I'm not actually sure calling it build is a good idea because
>> a number
>> > >> >> of common projects use build to contain built artifacts. What
>> is your
>> > >> >> objection to 'make'?
>> > >> >>
>> > >> >> > > doc/
>> > >> >> > > modules/
>> > >> >> > > jre/ # keytool, tool
>> launcher go
>> > >> here
>> > >> >> > > build.xml # classes go to
>> > >> >> jdk/jre/lib/tools.jar
>> > >> >> > > make/
>> > >> >> > > src/
>> > >> >> > > jdk/ # javac, jarsigner go
>> here
>> > >> >> > > build.xml # classes go to
>> > >> jdk/lib/tools.jar
>> > >> >> > > make/
>> > >> >> > > src/
>> > >> >> > > jdwp/ # separate module for
>> large
>> > >> >> component
>> > >> >> > > build.xml
>> > >> >> > > make/
>> > >> >> > > src/
>> > >> >> >
>> > >> >> > Only comment is that we might want to pull the launcher out
>> to be a
>> > >> >> > peer. Otherwise, I like it.
>> > >> >>
>> > >> >> I'd be a little tempted by that idea too.
>> > >> >>
>> > >> >> > >
>> > >> >> > > Assumptions which look reasonable for jdktool's build
>> subsystem:
>> > >> >> > >
>> > >> >> > > 1) it works in presence of built classlib (as HDK binaries
>> or as a
>> > >> >> > > result of classlib phase of overall build);
>> > >> >> >
>> > >> >> > yes - think of the same trick we do w/ DRLVM to "reach over"
>> to find
>> > >> >> it.
>> > >> >> > I'd imagine the federated build to then have :
>> > >> >> >
>> > >> >> > trunk/
>> > >> >> > working_classlib/
>> > >> >> > working_vm/
>> > >> >> > working_jdktools/
>> > >> >> >
>> > >> >> > > 2) the 'jre' module is always built before building 'jdk' to
>> > >> provide
>> > >> >> > > generic tool launcher and the jre/lib/tools.jar. Probably it
>> > >> will be
>> > >> >> > > easy to obtain these items from HDK.
>> > >> >> >
>> > >> >> > That's one reason why I'd pull the launcher out to it's own
>> module
>> > >> >> >
>> > >> >> > >
>> > >> >> > > I'm rather newbie in the Harmony build system so your
>> thoughts
>> > >> >> will be
>> > >> >> > > very helpful.
>> > >> >> >
>> > >> >> > Ant and make will be your friends here :) Note that you
>> will have
>> > >> >> > native issues (because of the launcher), so please track the
>> way
>> > >> that
>> > >> >> > classlib does this wrt platforms to start, and if you find
>> things
>> > >> that
>> > >> >> > work better, suggest it. Mark and Ollie are wizards here.
>> > >> >> >
>> > >> >> > I'd suggest starting out to accommodate (windows,linux) X (x86,
>> > >> x86_64)
>> > >> >> > if you grok what I mean, and do it in a way that it will be
>> > >> trivial to
>> > >> >> > add other OSs or processor architectures (IPF, for example).
>> > >> >>
>> > >> >> > This might be a good place to figure out how this should
>> work going
>> > >> >> > forward for harmony, rather than experimenting in classlib.
>> > >> >>
>> > >> >> +1
>> > >> >>
>> > >> >> > >
>> > >> >> > > Thank you
>> > >> >> >
>> > >> >> > No, thank you :)
>> > >> >>
>> > >> >> +1
>> > >> >>
>> > >> >> Regards,
>> > >> >> Mark.
>> > >> >>
>> > >> >> > geir
>> > >> >> >
>> > >> >> > > -Ilya
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
>> > >> >> > >> Hi Geir,
>> > >> >> > >>
>> > >> >> > >> Looks like that creating the "jdktools" source tree and
>> build was
>> > >> >> > >> shaded by other tasks. I can help with preparing and
>> checking
>> > >> >> updates
>> > >> >> > >> in the build system. Please let me know what needs to do
>> in this
>> > >> >> area
>> > >> >> > >> (besides svn commits) to complete the task.
>> > >> >> > >>
>> > >> >> > >> I'm especially interested in completing the move to
>> "jdktools"
>> > >> >> > >> structure since there will be a home for the JDWP code,
>> which has
>> > >> >> beed
>> > >> >> > >> voted but still resides in JIRA. Working with SVN will be
>> easier.
>> > >> >> > >>
>> > >> >> > >> Thanks.
>> > >> >> > >> -Ilya
>> > >> >> > >>
>> > >> >> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >> >> > >> > yep, that's the plan. And once we have that, we can
>> > >> simplify the
>> > >> >> > >> > launcher as well...
>> > >> >> > >> >
>> > >> >> > >> > Tim Ellison wrote:
>> > >> >> > >> > > +1 for creating a jdktools directory. The dependency
>> on the
>> > >> >> classlib
>> > >> >> > >> > > launcher should be relatively light if we go with a
>> simple
>> > >> tools
>> > >> >> > >> > > launcher that rewrites the tool invocation into a
>> generic
>> > >> >> launcher
>> > >> >> > >> > > invocation. You may recall the idea was discussed a
>> while
>> > >> ago.
>> > >> >> > >> > >
>> > >> >> > >> > > So, for example,
>> > >> >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
>> > >> >> > >> > > is rewritten to
>> > >> >> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar
>> > >> >> -Xmx200M
>> > >> >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>> > >> >> > >> > >
>> > >> >> > >> > > and so on.
>> > >> >> > >> > >
>> > >> >> > >> > > Regards,
>> > >> >> > >> > > Tim
>> > >> >> > >> > >
>> > >> >> > >> > > Geir Magnusson Jr. wrote:
>> > >> >> > >> > >> Geir Magnusson Jr. wrote:
>> > >> >> > >> > >>> Now that we have javac, javah, javap (if Tim votes
>> ;) and
>> > >> >> > >> keytool, I'd
>> > >> >> > >> > >>> like to organize these and add them to the next
>> snapshot.
>> > >> >> > >> > >> My bad - the javap isn't being voted on yet. I was
>> > >> thinking of
>> > >> >> > >> the jdwp
>> > >> >> > >> > >> vote... sorry
>> > >> >> > >> > >>
>> > >> >> > >> > >>> So I propose adding a new top-level directory called
>> > >> >> "jdktools"
>> > >> >> > >> (and
>> > >> >> > >> > >>> rename "tools" to "project_tools") and create a build
>> > >> >> target that -
>> > >> >> > >> > >>> with a dependency on classlib for the launcher -
>> > >> creates the
>> > >> >> > >> 'stuff'
>> > >> >> > >> > >>> needed to fill into the JDK.
>> > >> >> > >> > >>>
>> > >> >> > >> > >>> Any comments?
>> > >
>> > >
>> >
>>
>>
>>
>
Re: [general] creation of "jdktools"
Posted by Nathan Beyer <nb...@gmail.com>.
On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 31 October 2006 at 7:24, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
> >
> >
> > Alexei Zakharov wrote:
> > > Take me for example. I will be most likely misleaded with "build"
> > > since the majority of projects I've seen in my life were using "build"
> > > or "build.<platform>" for storing build artifacts (as Mark said). I
> > > agree it is logically to call it "build". But "make" is logical too.
> > > "ant" or "ant.scripts" also sound not so bad. Why not to choose the
> > > less confusing name?
> >
> > (I believe you meant "make" or "make.<platform>")
> >
> > What projects? Java projects?
>
> ?
>
> Apache Jakarta Commons Collections uses build/classes and build/tests
> for artifacts... just like classlib does.
>
> -Mark.
Every project that uses Maven 2 (including the Maven projects
themselves) use "target" as the general output directory,
"target/classes" as the compiled output (class files and resources)
and "target/test-classes" as the compiled test output (class files and
resources). The build instructions (script) is just placed in the root
of the project.
This is the default behavior of an minimally configured Maven 2
project, which is supposedly based on the ASF best practices. If we're
trying to converge on a common structure, I'd suggest following the
conventions of the Maven 2 system.
-Nathan
>
> > >
> > > With best regards,
> > >
> > > 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
> > >> Why? I'm really curious about this. We "build" the project, using the
> > >> "build.xml" file with Ant.
> > >>
> > >>
> > >> Ilya Neverov wrote:
> > >> > I would prefer to keep the current name "make" for directories related
> > >> > to build system. For me it looks natural; at least it looks less
> > >> > misleading than "build" :)
> > >> >
> > >> > -Ilya
> > >> >
> > >> > On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
> > >> >>
> > >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com>
> > >> wrote:
> > >> >> >
> > >> >> > Ilya Neverov wrote:
> > >> >> > > Hello,
> > >> >> > >
> > >> >> > > I want to gather opinions about structure of the "jdktools"
> > >> >> component.
> > >> >> > >
> > >> >> > > I'm going to create scripts for moving tools' sources from
> > >> classlib/
> > >> >> > > to top-level directory jdktools/ and to prepare patches for build
> > >> >> > > system for building tools from new place.
> > >> >> >
> > >> >> > Cool
> > >> >> >
> > >> >> > >
> > >> >> > > I think the following structure will be appropriate for future
> > >> >> > > evolution of the jdktools:
> > >> >> > >
> > >> >> > > jdktools/trunk/
> > >> >> > > build.xml
> > >> >> > > make/
> > >> >> >
> > >> >> > Can we stop persisting this mistake? Please call it "build" :)
> > >> >>
> > >> >> And call 'build' something else like 'target'?
> > >> >>
> > >> >> I'm not actually sure calling it build is a good idea because a number
> > >> >> of common projects use build to contain built artifacts. What is your
> > >> >> objection to 'make'?
> > >> >>
> > >> >> > > doc/
> > >> >> > > modules/
> > >> >> > > jre/ # keytool, tool launcher go
> > >> here
> > >> >> > > build.xml # classes go to
> > >> >> jdk/jre/lib/tools.jar
> > >> >> > > make/
> > >> >> > > src/
> > >> >> > > jdk/ # javac, jarsigner go here
> > >> >> > > build.xml # classes go to
> > >> jdk/lib/tools.jar
> > >> >> > > make/
> > >> >> > > src/
> > >> >> > > jdwp/ # separate module for large
> > >> >> component
> > >> >> > > build.xml
> > >> >> > > make/
> > >> >> > > src/
> > >> >> >
> > >> >> > Only comment is that we might want to pull the launcher out to be a
> > >> >> > peer. Otherwise, I like it.
> > >> >>
> > >> >> I'd be a little tempted by that idea too.
> > >> >>
> > >> >> > >
> > >> >> > > Assumptions which look reasonable for jdktool's build subsystem:
> > >> >> > >
> > >> >> > > 1) it works in presence of built classlib (as HDK binaries or as a
> > >> >> > > result of classlib phase of overall build);
> > >> >> >
> > >> >> > yes - think of the same trick we do w/ DRLVM to "reach over" to find
> > >> >> it.
> > >> >> > I'd imagine the federated build to then have :
> > >> >> >
> > >> >> > trunk/
> > >> >> > working_classlib/
> > >> >> > working_vm/
> > >> >> > working_jdktools/
> > >> >> >
> > >> >> > > 2) the 'jre' module is always built before building 'jdk' to
> > >> provide
> > >> >> > > generic tool launcher and the jre/lib/tools.jar. Probably it
> > >> will be
> > >> >> > > easy to obtain these items from HDK.
> > >> >> >
> > >> >> > That's one reason why I'd pull the launcher out to it's own module
> > >> >> >
> > >> >> > >
> > >> >> > > I'm rather newbie in the Harmony build system so your thoughts
> > >> >> will be
> > >> >> > > very helpful.
> > >> >> >
> > >> >> > Ant and make will be your friends here :) Note that you will have
> > >> >> > native issues (because of the launcher), so please track the way
> > >> that
> > >> >> > classlib does this wrt platforms to start, and if you find things
> > >> that
> > >> >> > work better, suggest it. Mark and Ollie are wizards here.
> > >> >> >
> > >> >> > I'd suggest starting out to accommodate (windows,linux) X (x86,
> > >> x86_64)
> > >> >> > if you grok what I mean, and do it in a way that it will be
> > >> trivial to
> > >> >> > add other OSs or processor architectures (IPF, for example).
> > >> >>
> > >> >> > This might be a good place to figure out how this should work going
> > >> >> > forward for harmony, rather than experimenting in classlib.
> > >> >>
> > >> >> +1
> > >> >>
> > >> >> > >
> > >> >> > > Thank you
> > >> >> >
> > >> >> > No, thank you :)
> > >> >>
> > >> >> +1
> > >> >>
> > >> >> Regards,
> > >> >> Mark.
> > >> >>
> > >> >> > geir
> > >> >> >
> > >> >> > > -Ilya
> > >> >> > >
> > >> >> > >
> > >> >> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
> > >> >> > >> Hi Geir,
> > >> >> > >>
> > >> >> > >> Looks like that creating the "jdktools" source tree and build was
> > >> >> > >> shaded by other tasks. I can help with preparing and checking
> > >> >> updates
> > >> >> > >> in the build system. Please let me know what needs to do in this
> > >> >> area
> > >> >> > >> (besides svn commits) to complete the task.
> > >> >> > >>
> > >> >> > >> I'm especially interested in completing the move to "jdktools"
> > >> >> > >> structure since there will be a home for the JDWP code, which has
> > >> >> beed
> > >> >> > >> voted but still resides in JIRA. Working with SVN will be easier.
> > >> >> > >>
> > >> >> > >> Thanks.
> > >> >> > >> -Ilya
> > >> >> > >>
> > >> >> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> >> > >> > yep, that's the plan. And once we have that, we can
> > >> simplify the
> > >> >> > >> > launcher as well...
> > >> >> > >> >
> > >> >> > >> > Tim Ellison wrote:
> > >> >> > >> > > +1 for creating a jdktools directory. The dependency on the
> > >> >> classlib
> > >> >> > >> > > launcher should be relatively light if we go with a simple
> > >> tools
> > >> >> > >> > > launcher that rewrites the tool invocation into a generic
> > >> >> launcher
> > >> >> > >> > > invocation. You may recall the idea was discussed a while
> > >> ago.
> > >> >> > >> > >
> > >> >> > >> > > So, for example,
> > >> >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> > >> >> > >> > > is rewritten to
> > >> >> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar
> > >> >> -Xmx200M
> > >> >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> > >> >> > >> > >
> > >> >> > >> > > and so on.
> > >> >> > >> > >
> > >> >> > >> > > Regards,
> > >> >> > >> > > Tim
> > >> >> > >> > >
> > >> >> > >> > > Geir Magnusson Jr. wrote:
> > >> >> > >> > >> Geir Magnusson Jr. wrote:
> > >> >> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
> > >> >> > >> keytool, I'd
> > >> >> > >> > >>> like to organize these and add them to the next snapshot.
> > >> >> > >> > >> My bad - the javap isn't being voted on yet. I was
> > >> thinking of
> > >> >> > >> the jdwp
> > >> >> > >> > >> vote... sorry
> > >> >> > >> > >>
> > >> >> > >> > >>> So I propose adding a new top-level directory called
> > >> >> "jdktools"
> > >> >> > >> (and
> > >> >> > >> > >>> rename "tools" to "project_tools") and create a build
> > >> >> target that -
> > >> >> > >> > >>> with a dependency on classlib for the launcher -
> > >> creates the
> > >> >> > >> 'stuff'
> > >> >> > >> > >>> needed to fill into the JDK.
> > >> >> > >> > >>>
> > >> >> > >> > >>> Any comments?
> > >
> > >
> >
>
>
>
Re: [general] creation of "jdktools"
Posted by Mark Hindess <ma...@googlemail.com>.
On 31 October 2006 at 7:24, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>
>
> Alexei Zakharov wrote:
> > Take me for example. I will be most likely misleaded with "build"
> > since the majority of projects I've seen in my life were using "build"
> > or "build.<platform>" for storing build artifacts (as Mark said). I
> > agree it is logically to call it "build". But "make" is logical too.
> > "ant" or "ant.scripts" also sound not so bad. Why not to choose the
> > less confusing name?
>
> (I believe you meant "make" or "make.<platform>")
>
> What projects? Java projects?
?
Apache Jakarta Commons Collections uses build/classes and build/tests
for artifacts... just like classlib does.
-Mark.
> >
> > With best regards,
> >
> > 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
> >> Why? I'm really curious about this. We "build" the project, using the
> >> "build.xml" file with Ant.
> >>
> >>
> >> Ilya Neverov wrote:
> >> > I would prefer to keep the current name "make" for directories related
> >> > to build system. For me it looks natural; at least it looks less
> >> > misleading than "build" :)
> >> >
> >> > -Ilya
> >> >
> >> > On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
> >> >>
> >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com>
> >> wrote:
> >> >> >
> >> >> > Ilya Neverov wrote:
> >> >> > > Hello,
> >> >> > >
> >> >> > > I want to gather opinions about structure of the "jdktools"
> >> >> component.
> >> >> > >
> >> >> > > I'm going to create scripts for moving tools' sources from
> >> classlib/
> >> >> > > to top-level directory jdktools/ and to prepare patches for build
> >> >> > > system for building tools from new place.
> >> >> >
> >> >> > Cool
> >> >> >
> >> >> > >
> >> >> > > I think the following structure will be appropriate for future
> >> >> > > evolution of the jdktools:
> >> >> > >
> >> >> > > jdktools/trunk/
> >> >> > > build.xml
> >> >> > > make/
> >> >> >
> >> >> > Can we stop persisting this mistake? Please call it "build" :)
> >> >>
> >> >> And call 'build' something else like 'target'?
> >> >>
> >> >> I'm not actually sure calling it build is a good idea because a number
> >> >> of common projects use build to contain built artifacts. What is your
> >> >> objection to 'make'?
> >> >>
> >> >> > > doc/
> >> >> > > modules/
> >> >> > > jre/ # keytool, tool launcher go
> >> here
> >> >> > > build.xml # classes go to
> >> >> jdk/jre/lib/tools.jar
> >> >> > > make/
> >> >> > > src/
> >> >> > > jdk/ # javac, jarsigner go here
> >> >> > > build.xml # classes go to
> >> jdk/lib/tools.jar
> >> >> > > make/
> >> >> > > src/
> >> >> > > jdwp/ # separate module for large
> >> >> component
> >> >> > > build.xml
> >> >> > > make/
> >> >> > > src/
> >> >> >
> >> >> > Only comment is that we might want to pull the launcher out to be a
> >> >> > peer. Otherwise, I like it.
> >> >>
> >> >> I'd be a little tempted by that idea too.
> >> >>
> >> >> > >
> >> >> > > Assumptions which look reasonable for jdktool's build subsystem:
> >> >> > >
> >> >> > > 1) it works in presence of built classlib (as HDK binaries or as a
> >> >> > > result of classlib phase of overall build);
> >> >> >
> >> >> > yes - think of the same trick we do w/ DRLVM to "reach over" to find
> >> >> it.
> >> >> > I'd imagine the federated build to then have :
> >> >> >
> >> >> > trunk/
> >> >> > working_classlib/
> >> >> > working_vm/
> >> >> > working_jdktools/
> >> >> >
> >> >> > > 2) the 'jre' module is always built before building 'jdk' to
> >> provide
> >> >> > > generic tool launcher and the jre/lib/tools.jar. Probably it
> >> will be
> >> >> > > easy to obtain these items from HDK.
> >> >> >
> >> >> > That's one reason why I'd pull the launcher out to it's own module
> >> >> >
> >> >> > >
> >> >> > > I'm rather newbie in the Harmony build system so your thoughts
> >> >> will be
> >> >> > > very helpful.
> >> >> >
> >> >> > Ant and make will be your friends here :) Note that you will have
> >> >> > native issues (because of the launcher), so please track the way
> >> that
> >> >> > classlib does this wrt platforms to start, and if you find things
> >> that
> >> >> > work better, suggest it. Mark and Ollie are wizards here.
> >> >> >
> >> >> > I'd suggest starting out to accommodate (windows,linux) X (x86,
> >> x86_64)
> >> >> > if you grok what I mean, and do it in a way that it will be
> >> trivial to
> >> >> > add other OSs or processor architectures (IPF, for example).
> >> >>
> >> >> > This might be a good place to figure out how this should work going
> >> >> > forward for harmony, rather than experimenting in classlib.
> >> >>
> >> >> +1
> >> >>
> >> >> > >
> >> >> > > Thank you
> >> >> >
> >> >> > No, thank you :)
> >> >>
> >> >> +1
> >> >>
> >> >> Regards,
> >> >> Mark.
> >> >>
> >> >> > geir
> >> >> >
> >> >> > > -Ilya
> >> >> > >
> >> >> > >
> >> >> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
> >> >> > >> Hi Geir,
> >> >> > >>
> >> >> > >> Looks like that creating the "jdktools" source tree and build was
> >> >> > >> shaded by other tasks. I can help with preparing and checking
> >> >> updates
> >> >> > >> in the build system. Please let me know what needs to do in this
> >> >> area
> >> >> > >> (besides svn commits) to complete the task.
> >> >> > >>
> >> >> > >> I'm especially interested in completing the move to "jdktools"
> >> >> > >> structure since there will be a home for the JDWP code, which has
> >> >> beed
> >> >> > >> voted but still resides in JIRA. Working with SVN will be easier.
> >> >> > >>
> >> >> > >> Thanks.
> >> >> > >> -Ilya
> >> >> > >>
> >> >> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> >> > >> > yep, that's the plan. And once we have that, we can
> >> simplify the
> >> >> > >> > launcher as well...
> >> >> > >> >
> >> >> > >> > Tim Ellison wrote:
> >> >> > >> > > +1 for creating a jdktools directory. The dependency on the
> >> >> classlib
> >> >> > >> > > launcher should be relatively light if we go with a simple
> >> tools
> >> >> > >> > > launcher that rewrites the tool invocation into a generic
> >> >> launcher
> >> >> > >> > > invocation. You may recall the idea was discussed a while
> >> ago.
> >> >> > >> > >
> >> >> > >> > > So, for example,
> >> >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> >> >> > >> > > is rewritten to
> >> >> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar
> >> >> -Xmx200M
> >> >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> >> >> > >> > >
> >> >> > >> > > and so on.
> >> >> > >> > >
> >> >> > >> > > Regards,
> >> >> > >> > > Tim
> >> >> > >> > >
> >> >> > >> > > Geir Magnusson Jr. wrote:
> >> >> > >> > >> Geir Magnusson Jr. wrote:
> >> >> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
> >> >> > >> keytool, I'd
> >> >> > >> > >>> like to organize these and add them to the next snapshot.
> >> >> > >> > >> My bad - the javap isn't being voted on yet. I was
> >> thinking of
> >> >> > >> the jdwp
> >> >> > >> > >> vote... sorry
> >> >> > >> > >>
> >> >> > >> > >>> So I propose adding a new top-level directory called
> >> >> "jdktools"
> >> >> > >> (and
> >> >> > >> > >>> rename "tools" to "project_tools") and create a build
> >> >> target that -
> >> >> > >> > >>> with a dependency on classlib for the launcher -
> >> creates the
> >> >> > >> 'stuff'
> >> >> > >> > >>> needed to fill into the JDK.
> >> >> > >> > >>>
> >> >> > >> > >>> Any comments?
> >
> >
>
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexei Zakharov wrote:
> Take me for example. I will be most likely misleaded with "build"
> since the majority of projects I've seen in my life were using "build"
> or "build.<platform>" for storing build artifacts (as Mark said). I
> agree it is logically to call it "build". But "make" is logical too.
> "ant" or "ant.scripts" also sound not so bad. Why not to choose the
> less confusing name?
(I believe you meant "make" or "make.<platform>")
What projects? Java projects?
>
> With best regards,
>
> 2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
>> Why? I'm really curious about this. We "build" the project, using the
>> "build.xml" file with Ant.
>>
>>
>> Ilya Neverov wrote:
>> > I would prefer to keep the current name "make" for directories related
>> > to build system. For me it looks natural; at least it looks less
>> > misleading than "build" :)
>> >
>> > -Ilya
>> >
>> > On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>> >>
>> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com>
>> wrote:
>> >> >
>> >> > Ilya Neverov wrote:
>> >> > > Hello,
>> >> > >
>> >> > > I want to gather opinions about structure of the "jdktools"
>> >> component.
>> >> > >
>> >> > > I'm going to create scripts for moving tools' sources from
>> classlib/
>> >> > > to top-level directory jdktools/ and to prepare patches for build
>> >> > > system for building tools from new place.
>> >> >
>> >> > Cool
>> >> >
>> >> > >
>> >> > > I think the following structure will be appropriate for future
>> >> > > evolution of the jdktools:
>> >> > >
>> >> > > jdktools/trunk/
>> >> > > build.xml
>> >> > > make/
>> >> >
>> >> > Can we stop persisting this mistake? Please call it "build" :)
>> >>
>> >> And call 'build' something else like 'target'?
>> >>
>> >> I'm not actually sure calling it build is a good idea because a number
>> >> of common projects use build to contain built artifacts. What is your
>> >> objection to 'make'?
>> >>
>> >> > > doc/
>> >> > > modules/
>> >> > > jre/ # keytool, tool launcher go
>> here
>> >> > > build.xml # classes go to
>> >> jdk/jre/lib/tools.jar
>> >> > > make/
>> >> > > src/
>> >> > > jdk/ # javac, jarsigner go here
>> >> > > build.xml # classes go to
>> jdk/lib/tools.jar
>> >> > > make/
>> >> > > src/
>> >> > > jdwp/ # separate module for large
>> >> component
>> >> > > build.xml
>> >> > > make/
>> >> > > src/
>> >> >
>> >> > Only comment is that we might want to pull the launcher out to be a
>> >> > peer. Otherwise, I like it.
>> >>
>> >> I'd be a little tempted by that idea too.
>> >>
>> >> > >
>> >> > > Assumptions which look reasonable for jdktool's build subsystem:
>> >> > >
>> >> > > 1) it works in presence of built classlib (as HDK binaries or as a
>> >> > > result of classlib phase of overall build);
>> >> >
>> >> > yes - think of the same trick we do w/ DRLVM to "reach over" to find
>> >> it.
>> >> > I'd imagine the federated build to then have :
>> >> >
>> >> > trunk/
>> >> > working_classlib/
>> >> > working_vm/
>> >> > working_jdktools/
>> >> >
>> >> > > 2) the 'jre' module is always built before building 'jdk' to
>> provide
>> >> > > generic tool launcher and the jre/lib/tools.jar. Probably it
>> will be
>> >> > > easy to obtain these items from HDK.
>> >> >
>> >> > That's one reason why I'd pull the launcher out to it's own module
>> >> >
>> >> > >
>> >> > > I'm rather newbie in the Harmony build system so your thoughts
>> >> will be
>> >> > > very helpful.
>> >> >
>> >> > Ant and make will be your friends here :) Note that you will have
>> >> > native issues (because of the launcher), so please track the way
>> that
>> >> > classlib does this wrt platforms to start, and if you find things
>> that
>> >> > work better, suggest it. Mark and Ollie are wizards here.
>> >> >
>> >> > I'd suggest starting out to accommodate (windows,linux) X (x86,
>> x86_64)
>> >> > if you grok what I mean, and do it in a way that it will be
>> trivial to
>> >> > add other OSs or processor architectures (IPF, for example).
>> >>
>> >> > This might be a good place to figure out how this should work going
>> >> > forward for harmony, rather than experimenting in classlib.
>> >>
>> >> +1
>> >>
>> >> > >
>> >> > > Thank you
>> >> >
>> >> > No, thank you :)
>> >>
>> >> +1
>> >>
>> >> Regards,
>> >> Mark.
>> >>
>> >> > geir
>> >> >
>> >> > > -Ilya
>> >> > >
>> >> > >
>> >> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
>> >> > >> Hi Geir,
>> >> > >>
>> >> > >> Looks like that creating the "jdktools" source tree and build was
>> >> > >> shaded by other tasks. I can help with preparing and checking
>> >> updates
>> >> > >> in the build system. Please let me know what needs to do in this
>> >> area
>> >> > >> (besides svn commits) to complete the task.
>> >> > >>
>> >> > >> I'm especially interested in completing the move to "jdktools"
>> >> > >> structure since there will be a home for the JDWP code, which has
>> >> beed
>> >> > >> voted but still resides in JIRA. Working with SVN will be easier.
>> >> > >>
>> >> > >> Thanks.
>> >> > >> -Ilya
>> >> > >>
>> >> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> > >> > yep, that's the plan. And once we have that, we can
>> simplify the
>> >> > >> > launcher as well...
>> >> > >> >
>> >> > >> > Tim Ellison wrote:
>> >> > >> > > +1 for creating a jdktools directory. The dependency on the
>> >> classlib
>> >> > >> > > launcher should be relatively light if we go with a simple
>> tools
>> >> > >> > > launcher that rewrites the tool invocation into a generic
>> >> launcher
>> >> > >> > > invocation. You may recall the idea was discussed a while
>> ago.
>> >> > >> > >
>> >> > >> > > So, for example,
>> >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
>> >> > >> > > is rewritten to
>> >> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar
>> >> -Xmx200M
>> >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>> >> > >> > >
>> >> > >> > > and so on.
>> >> > >> > >
>> >> > >> > > Regards,
>> >> > >> > > Tim
>> >> > >> > >
>> >> > >> > > Geir Magnusson Jr. wrote:
>> >> > >> > >> Geir Magnusson Jr. wrote:
>> >> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
>> >> > >> keytool, I'd
>> >> > >> > >>> like to organize these and add them to the next snapshot.
>> >> > >> > >> My bad - the javap isn't being voted on yet. I was
>> thinking of
>> >> > >> the jdwp
>> >> > >> > >> vote... sorry
>> >> > >> > >>
>> >> > >> > >>> So I propose adding a new top-level directory called
>> >> "jdktools"
>> >> > >> (and
>> >> > >> > >>> rename "tools" to "project_tools") and create a build
>> >> target that -
>> >> > >> > >>> with a dependency on classlib for the launcher -
>> creates the
>> >> > >> 'stuff'
>> >> > >> > >>> needed to fill into the JDK.
>> >> > >> > >>>
>> >> > >> > >>> Any comments?
>
>
Re: [general] creation of "jdktools"
Posted by Alexei Zakharov <al...@gmail.com>.
Take me for example. I will be most likely misleaded with "build"
since the majority of projects I've seen in my life were using "build"
or "build.<platform>" for storing build artifacts (as Mark said). I
agree it is logically to call it "build". But "make" is logical too.
"ant" or "ant.scripts" also sound not so bad. Why not to choose the
less confusing name?
With best regards,
2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
> Why? I'm really curious about this. We "build" the project, using the
> "build.xml" file with Ant.
>
>
> Ilya Neverov wrote:
> > I would prefer to keep the current name "make" for directories related
> > to build system. For me it looks natural; at least it looks less
> > misleading than "build" :)
> >
> > -Ilya
> >
> > On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
> >>
> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
> >> >
> >> > Ilya Neverov wrote:
> >> > > Hello,
> >> > >
> >> > > I want to gather opinions about structure of the "jdktools"
> >> component.
> >> > >
> >> > > I'm going to create scripts for moving tools' sources from classlib/
> >> > > to top-level directory jdktools/ and to prepare patches for build
> >> > > system for building tools from new place.
> >> >
> >> > Cool
> >> >
> >> > >
> >> > > I think the following structure will be appropriate for future
> >> > > evolution of the jdktools:
> >> > >
> >> > > jdktools/trunk/
> >> > > build.xml
> >> > > make/
> >> >
> >> > Can we stop persisting this mistake? Please call it "build" :)
> >>
> >> And call 'build' something else like 'target'?
> >>
> >> I'm not actually sure calling it build is a good idea because a number
> >> of common projects use build to contain built artifacts. What is your
> >> objection to 'make'?
> >>
> >> > > doc/
> >> > > modules/
> >> > > jre/ # keytool, tool launcher go here
> >> > > build.xml # classes go to
> >> jdk/jre/lib/tools.jar
> >> > > make/
> >> > > src/
> >> > > jdk/ # javac, jarsigner go here
> >> > > build.xml # classes go to jdk/lib/tools.jar
> >> > > make/
> >> > > src/
> >> > > jdwp/ # separate module for large
> >> component
> >> > > build.xml
> >> > > make/
> >> > > src/
> >> >
> >> > Only comment is that we might want to pull the launcher out to be a
> >> > peer. Otherwise, I like it.
> >>
> >> I'd be a little tempted by that idea too.
> >>
> >> > >
> >> > > Assumptions which look reasonable for jdktool's build subsystem:
> >> > >
> >> > > 1) it works in presence of built classlib (as HDK binaries or as a
> >> > > result of classlib phase of overall build);
> >> >
> >> > yes - think of the same trick we do w/ DRLVM to "reach over" to find
> >> it.
> >> > I'd imagine the federated build to then have :
> >> >
> >> > trunk/
> >> > working_classlib/
> >> > working_vm/
> >> > working_jdktools/
> >> >
> >> > > 2) the 'jre' module is always built before building 'jdk' to provide
> >> > > generic tool launcher and the jre/lib/tools.jar. Probably it will be
> >> > > easy to obtain these items from HDK.
> >> >
> >> > That's one reason why I'd pull the launcher out to it's own module
> >> >
> >> > >
> >> > > I'm rather newbie in the Harmony build system so your thoughts
> >> will be
> >> > > very helpful.
> >> >
> >> > Ant and make will be your friends here :) Note that you will have
> >> > native issues (because of the launcher), so please track the way that
> >> > classlib does this wrt platforms to start, and if you find things that
> >> > work better, suggest it. Mark and Ollie are wizards here.
> >> >
> >> > I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64)
> >> > if you grok what I mean, and do it in a way that it will be trivial to
> >> > add other OSs or processor architectures (IPF, for example).
> >>
> >> > This might be a good place to figure out how this should work going
> >> > forward for harmony, rather than experimenting in classlib.
> >>
> >> +1
> >>
> >> > >
> >> > > Thank you
> >> >
> >> > No, thank you :)
> >>
> >> +1
> >>
> >> Regards,
> >> Mark.
> >>
> >> > geir
> >> >
> >> > > -Ilya
> >> > >
> >> > >
> >> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
> >> > >> Hi Geir,
> >> > >>
> >> > >> Looks like that creating the "jdktools" source tree and build was
> >> > >> shaded by other tasks. I can help with preparing and checking
> >> updates
> >> > >> in the build system. Please let me know what needs to do in this
> >> area
> >> > >> (besides svn commits) to complete the task.
> >> > >>
> >> > >> I'm especially interested in completing the move to "jdktools"
> >> > >> structure since there will be a home for the JDWP code, which has
> >> beed
> >> > >> voted but still resides in JIRA. Working with SVN will be easier.
> >> > >>
> >> > >> Thanks.
> >> > >> -Ilya
> >> > >>
> >> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > >> > yep, that's the plan. And once we have that, we can simplify the
> >> > >> > launcher as well...
> >> > >> >
> >> > >> > Tim Ellison wrote:
> >> > >> > > +1 for creating a jdktools directory. The dependency on the
> >> classlib
> >> > >> > > launcher should be relatively light if we go with a simple tools
> >> > >> > > launcher that rewrites the tool invocation into a generic
> >> launcher
> >> > >> > > invocation. You may recall the idea was discussed a while ago.
> >> > >> > >
> >> > >> > > So, for example,
> >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> >> > >> > > is rewritten to
> >> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar
> >> -Xmx200M
> >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> >> > >> > >
> >> > >> > > and so on.
> >> > >> > >
> >> > >> > > Regards,
> >> > >> > > Tim
> >> > >> > >
> >> > >> > > Geir Magnusson Jr. wrote:
> >> > >> > >> Geir Magnusson Jr. wrote:
> >> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
> >> > >> keytool, I'd
> >> > >> > >>> like to organize these and add them to the next snapshot.
> >> > >> > >> My bad - the javap isn't being voted on yet. I was thinking of
> >> > >> the jdwp
> >> > >> > >> vote... sorry
> >> > >> > >>
> >> > >> > >>> So I propose adding a new top-level directory called
> >> "jdktools"
> >> > >> (and
> >> > >> > >>> rename "tools" to "project_tools") and create a build
> >> target that -
> >> > >> > >>> with a dependency on classlib for the launcher - creates the
> >> > >> 'stuff'
> >> > >> > >>> needed to fill into the JDK.
> >> > >> > >>>
> >> > >> > >>> Any comments?
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Why? I'm really curious about this. We "build" the project, using the
"build.xml" file with Ant.
Ilya Neverov wrote:
> I would prefer to keep the current name "make" for directories related
> to build system. For me it looks natural; at least it looks less
> misleading than "build" :)
>
> -Ilya
>
> On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>>
>> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>> >
>> > Ilya Neverov wrote:
>> > > Hello,
>> > >
>> > > I want to gather opinions about structure of the "jdktools"
>> component.
>> > >
>> > > I'm going to create scripts for moving tools' sources from classlib/
>> > > to top-level directory jdktools/ and to prepare patches for build
>> > > system for building tools from new place.
>> >
>> > Cool
>> >
>> > >
>> > > I think the following structure will be appropriate for future
>> > > evolution of the jdktools:
>> > >
>> > > jdktools/trunk/
>> > > build.xml
>> > > make/
>> >
>> > Can we stop persisting this mistake? Please call it "build" :)
>>
>> And call 'build' something else like 'target'?
>>
>> I'm not actually sure calling it build is a good idea because a number
>> of common projects use build to contain built artifacts. What is your
>> objection to 'make'?
>>
>> > > doc/
>> > > modules/
>> > > jre/ # keytool, tool launcher go here
>> > > build.xml # classes go to
>> jdk/jre/lib/tools.jar
>> > > make/
>> > > src/
>> > > jdk/ # javac, jarsigner go here
>> > > build.xml # classes go to jdk/lib/tools.jar
>> > > make/
>> > > src/
>> > > jdwp/ # separate module for large
>> component
>> > > build.xml
>> > > make/
>> > > src/
>> >
>> > Only comment is that we might want to pull the launcher out to be a
>> > peer. Otherwise, I like it.
>>
>> I'd be a little tempted by that idea too.
>>
>> > >
>> > > Assumptions which look reasonable for jdktool's build subsystem:
>> > >
>> > > 1) it works in presence of built classlib (as HDK binaries or as a
>> > > result of classlib phase of overall build);
>> >
>> > yes - think of the same trick we do w/ DRLVM to "reach over" to find
>> it.
>> > I'd imagine the federated build to then have :
>> >
>> > trunk/
>> > working_classlib/
>> > working_vm/
>> > working_jdktools/
>> >
>> > > 2) the 'jre' module is always built before building 'jdk' to provide
>> > > generic tool launcher and the jre/lib/tools.jar. Probably it will be
>> > > easy to obtain these items from HDK.
>> >
>> > That's one reason why I'd pull the launcher out to it's own module
>> >
>> > >
>> > > I'm rather newbie in the Harmony build system so your thoughts
>> will be
>> > > very helpful.
>> >
>> > Ant and make will be your friends here :) Note that you will have
>> > native issues (because of the launcher), so please track the way that
>> > classlib does this wrt platforms to start, and if you find things that
>> > work better, suggest it. Mark and Ollie are wizards here.
>> >
>> > I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64)
>> > if you grok what I mean, and do it in a way that it will be trivial to
>> > add other OSs or processor architectures (IPF, for example).
>>
>> > This might be a good place to figure out how this should work going
>> > forward for harmony, rather than experimenting in classlib.
>>
>> +1
>>
>> > >
>> > > Thank you
>> >
>> > No, thank you :)
>>
>> +1
>>
>> Regards,
>> Mark.
>>
>> > geir
>> >
>> > > -Ilya
>> > >
>> > >
>> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
>> > >> Hi Geir,
>> > >>
>> > >> Looks like that creating the "jdktools" source tree and build was
>> > >> shaded by other tasks. I can help with preparing and checking
>> updates
>> > >> in the build system. Please let me know what needs to do in this
>> area
>> > >> (besides svn commits) to complete the task.
>> > >>
>> > >> I'm especially interested in completing the move to "jdktools"
>> > >> structure since there will be a home for the JDWP code, which has
>> beed
>> > >> voted but still resides in JIRA. Working with SVN will be easier.
>> > >>
>> > >> Thanks.
>> > >> -Ilya
>> > >>
>> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >> > yep, that's the plan. And once we have that, we can simplify the
>> > >> > launcher as well...
>> > >> >
>> > >> > Tim Ellison wrote:
>> > >> > > +1 for creating a jdktools directory. The dependency on the
>> classlib
>> > >> > > launcher should be relatively light if we go with a simple tools
>> > >> > > launcher that rewrites the tool invocation into a generic
>> launcher
>> > >> > > invocation. You may recall the idea was discussed a while ago.
>> > >> > >
>> > >> > > So, for example,
>> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
>> > >> > > is rewritten to
>> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar
>> -Xmx200M
>> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>> > >> > >
>> > >> > > and so on.
>> > >> > >
>> > >> > > Regards,
>> > >> > > Tim
>> > >> > >
>> > >> > > Geir Magnusson Jr. wrote:
>> > >> > >> Geir Magnusson Jr. wrote:
>> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
>> > >> keytool, I'd
>> > >> > >>> like to organize these and add them to the next snapshot.
>> > >> > >> My bad - the javap isn't being voted on yet. I was thinking of
>> > >> the jdwp
>> > >> > >> vote... sorry
>> > >> > >>
>> > >> > >>> So I propose adding a new top-level directory called
>> "jdktools"
>> > >> (and
>> > >> > >>> rename "tools" to "project_tools") and create a build
>> target that -
>> > >> > >>> with a dependency on classlib for the launcher - creates the
>> > >> 'stuff'
>> > >> > >>> needed to fill into the JDK.
>> > >> > >>>
>> > >> > >>> Any comments?
>> > >> > >>>
>> > >> > >>> geir
>> > >> > >>>
>> > >> >
>> ---------------------------------------------------------------------
>> > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > >> > To unsubscribe, e-mail:
>> harmony-dev-unsubscribe@incubator.apache.org
>> > >> > For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> > >> >
>> > >> >
>> > >>
>> > >> --
>> > >> Thank you.
>> > >> Ilya Neverov,
>> > >> Intel Middleware Products Division
>> > >>
>> > >
>> >
>>
>>
>>
>
>
Re: [general] creation of "jdktools"
Posted by Alexei Zakharov <al...@gmail.com>.
+1
IMHO "make" is still much better than "build"
Regards,
2006/10/31, Ilya Neverov <il...@gmail.com>:
> I would prefer to keep the current name "make" for directories related
> to build system. For me it looks natural; at least it looks less
> misleading than "build" :)
>
> -Ilya
>
> On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
> > >
> > > Ilya Neverov wrote:
> > > > Hello,
> > > >
> > > > I want to gather opinions about structure of the "jdktools" component.
> > > >
> > > > I'm going to create scripts for moving tools' sources from classlib/
> > > > to top-level directory jdktools/ and to prepare patches for build
> > > > system for building tools from new place.
> > >
> > > Cool
> > >
> > > >
> > > > I think the following structure will be appropriate for future
> > > > evolution of the jdktools:
> > > >
> > > > jdktools/trunk/
> > > > build.xml
> > > > make/
> > >
> > > Can we stop persisting this mistake? Please call it "build" :)
> >
> > And call 'build' something else like 'target'?
> >
> > I'm not actually sure calling it build is a good idea because a number
> > of common projects use build to contain built artifacts. What is your
> > objection to 'make'?
> >
> > > > doc/
> > > > modules/
> > > > jre/ # keytool, tool launcher go here
> > > > build.xml # classes go to jdk/jre/lib/tools.jar
> > > > make/
> > > > src/
> > > > jdk/ # javac, jarsigner go here
> > > > build.xml # classes go to jdk/lib/tools.jar
> > > > make/
> > > > src/
> > > > jdwp/ # separate module for large component
> > > > build.xml
> > > > make/
> > > > src/
> > >
> > > Only comment is that we might want to pull the launcher out to be a
> > > peer. Otherwise, I like it.
> >
> > I'd be a little tempted by that idea too.
> >
> > > >
> > > > Assumptions which look reasonable for jdktool's build subsystem:
> > > >
> > > > 1) it works in presence of built classlib (as HDK binaries or as a
> > > > result of classlib phase of overall build);
> > >
> > > yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
> > > I'd imagine the federated build to then have :
> > >
> > > trunk/
> > > working_classlib/
> > > working_vm/
> > > working_jdktools/
> > >
> > > > 2) the 'jre' module is always built before building 'jdk' to provide
> > > > generic tool launcher and the jre/lib/tools.jar. Probably it will be
> > > > easy to obtain these items from HDK.
> > >
> > > That's one reason why I'd pull the launcher out to it's own module
> > >
> > > >
> > > > I'm rather newbie in the Harmony build system so your thoughts will be
> > > > very helpful.
> > >
> > > Ant and make will be your friends here :) Note that you will have
> > > native issues (because of the launcher), so please track the way that
> > > classlib does this wrt platforms to start, and if you find things that
> > > work better, suggest it. Mark and Ollie are wizards here.
> > >
> > > I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64)
> > > if you grok what I mean, and do it in a way that it will be trivial to
> > > add other OSs or processor architectures (IPF, for example).
> >
> > > This might be a good place to figure out how this should work going
> > > forward for harmony, rather than experimenting in classlib.
> >
> > +1
> >
> > > >
> > > > Thank you
> > >
> > > No, thank you :)
> >
> > +1
> >
> > Regards,
> > Mark.
> >
> > > geir
> > >
> > > > -Ilya
> > > >
> > > >
> > > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
> > > >> Hi Geir,
> > > >>
> > > >> Looks like that creating the "jdktools" source tree and build was
> > > >> shaded by other tasks. I can help with preparing and checking updates
> > > >> in the build system. Please let me know what needs to do in this area
> > > >> (besides svn commits) to complete the task.
> > > >>
> > > >> I'm especially interested in completing the move to "jdktools"
> > > >> structure since there will be a home for the JDWP code, which has beed
> > > >> voted but still resides in JIRA. Working with SVN will be easier.
> > > >>
> > > >> Thanks.
> > > >> -Ilya
> > > >>
> > > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >> > yep, that's the plan. And once we have that, we can simplify the
> > > >> > launcher as well...
> > > >> >
> > > >> > Tim Ellison wrote:
> > > >> > > +1 for creating a jdktools directory. The dependency on the classlib
> > > >> > > launcher should be relatively light if we go with a simple tools
> > > >> > > launcher that rewrites the tool invocation into a generic launcher
> > > >> > > invocation. You may recall the idea was discussed a while ago.
> > > >> > >
> > > >> > > So, for example,
> > > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> > > >> > > is rewritten to
> > > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
> > > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> > > >> > >
> > > >> > > and so on.
> > > >> > >
> > > >> > > Regards,
> > > >> > > Tim
> > > >> > >
> > > >> > > Geir Magnusson Jr. wrote:
> > > >> > >> Geir Magnusson Jr. wrote:
> > > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
> > > >> keytool, I'd
> > > >> > >>> like to organize these and add them to the next snapshot.
> > > >> > >> My bad - the javap isn't being voted on yet. I was thinking of
> > > >> the jdwp
> > > >> > >> vote... sorry
> > > >> > >>
> > > >> > >>> So I propose adding a new top-level directory called "jdktools"
> > > >> (and
> > > >> > >>> rename "tools" to "project_tools") and create a build target that -
> > > >> > >>> with a dependency on classlib for the launcher - creates the
> > > >> 'stuff'
> > > >> > >>> needed to fill into the JDK.
> > > >> > >>>
> > > >> > >>> Any comments?
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [general] creation of "jdktools"
Posted by Ilya Neverov <il...@gmail.com>.
I would prefer to keep the current name "make" for directories related
to build system. For me it looks natural; at least it looks less
misleading than "build" :)
-Ilya
On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
> >
> > Ilya Neverov wrote:
> > > Hello,
> > >
> > > I want to gather opinions about structure of the "jdktools" component.
> > >
> > > I'm going to create scripts for moving tools' sources from classlib/
> > > to top-level directory jdktools/ and to prepare patches for build
> > > system for building tools from new place.
> >
> > Cool
> >
> > >
> > > I think the following structure will be appropriate for future
> > > evolution of the jdktools:
> > >
> > > jdktools/trunk/
> > > build.xml
> > > make/
> >
> > Can we stop persisting this mistake? Please call it "build" :)
>
> And call 'build' something else like 'target'?
>
> I'm not actually sure calling it build is a good idea because a number
> of common projects use build to contain built artifacts. What is your
> objection to 'make'?
>
> > > doc/
> > > modules/
> > > jre/ # keytool, tool launcher go here
> > > build.xml # classes go to jdk/jre/lib/tools.jar
> > > make/
> > > src/
> > > jdk/ # javac, jarsigner go here
> > > build.xml # classes go to jdk/lib/tools.jar
> > > make/
> > > src/
> > > jdwp/ # separate module for large component
> > > build.xml
> > > make/
> > > src/
> >
> > Only comment is that we might want to pull the launcher out to be a
> > peer. Otherwise, I like it.
>
> I'd be a little tempted by that idea too.
>
> > >
> > > Assumptions which look reasonable for jdktool's build subsystem:
> > >
> > > 1) it works in presence of built classlib (as HDK binaries or as a
> > > result of classlib phase of overall build);
> >
> > yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
> > I'd imagine the federated build to then have :
> >
> > trunk/
> > working_classlib/
> > working_vm/
> > working_jdktools/
> >
> > > 2) the 'jre' module is always built before building 'jdk' to provide
> > > generic tool launcher and the jre/lib/tools.jar. Probably it will be
> > > easy to obtain these items from HDK.
> >
> > That's one reason why I'd pull the launcher out to it's own module
> >
> > >
> > > I'm rather newbie in the Harmony build system so your thoughts will be
> > > very helpful.
> >
> > Ant and make will be your friends here :) Note that you will have
> > native issues (because of the launcher), so please track the way that
> > classlib does this wrt platforms to start, and if you find things that
> > work better, suggest it. Mark and Ollie are wizards here.
> >
> > I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64)
> > if you grok what I mean, and do it in a way that it will be trivial to
> > add other OSs or processor architectures (IPF, for example).
>
> > This might be a good place to figure out how this should work going
> > forward for harmony, rather than experimenting in classlib.
>
> +1
>
> > >
> > > Thank you
> >
> > No, thank you :)
>
> +1
>
> Regards,
> Mark.
>
> > geir
> >
> > > -Ilya
> > >
> > >
> > > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
> > >> Hi Geir,
> > >>
> > >> Looks like that creating the "jdktools" source tree and build was
> > >> shaded by other tasks. I can help with preparing and checking updates
> > >> in the build system. Please let me know what needs to do in this area
> > >> (besides svn commits) to complete the task.
> > >>
> > >> I'm especially interested in completing the move to "jdktools"
> > >> structure since there will be a home for the JDWP code, which has beed
> > >> voted but still resides in JIRA. Working with SVN will be easier.
> > >>
> > >> Thanks.
> > >> -Ilya
> > >>
> > >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> > yep, that's the plan. And once we have that, we can simplify the
> > >> > launcher as well...
> > >> >
> > >> > Tim Ellison wrote:
> > >> > > +1 for creating a jdktools directory. The dependency on the classlib
> > >> > > launcher should be relatively light if we go with a simple tools
> > >> > > launcher that rewrites the tool invocation into a generic launcher
> > >> > > invocation. You may recall the idea was discussed a while ago.
> > >> > >
> > >> > > So, for example,
> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> > >> > > is rewritten to
> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> > >> > >
> > >> > > and so on.
> > >> > >
> > >> > > Regards,
> > >> > > Tim
> > >> > >
> > >> > > Geir Magnusson Jr. wrote:
> > >> > >> Geir Magnusson Jr. wrote:
> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
> > >> keytool, I'd
> > >> > >>> like to organize these and add them to the next snapshot.
> > >> > >> My bad - the javap isn't being voted on yet. I was thinking of
> > >> the jdwp
> > >> > >> vote... sorry
> > >> > >>
> > >> > >>> So I propose adding a new top-level directory called "jdktools"
> > >> (and
> > >> > >>> rename "tools" to "project_tools") and create a build target that -
> > >> > >>> with a dependency on classlib for the launcher - creates the
> > >> 'stuff'
> > >> > >>> needed to fill into the JDK.
> > >> > >>>
> > >> > >>> Any comments?
> > >> > >>>
> > >> > >>> geir
> > >> > >>>
> > >> > ---------------------------------------------------------------------
> > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > >> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >> >
> > >> >
> > >>
> > >> --
> > >> Thank you.
> > >> Ilya Neverov,
> > >> Intel Middleware Products Division
> > >>
> > >
> >
>
>
>
--
Thank you.
Ilya Neverov,
Intel Middleware Products Division
Re: [general] creation of "jdktools"
Posted by Mark Hindess <ma...@googlemail.com>.
On 30 October 2006 at 18:38, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>
> Ilya Neverov wrote:
> > Hello,
> >
> > I want to gather opinions about structure of the "jdktools" component.
> >
> > I'm going to create scripts for moving tools' sources from classlib/
> > to top-level directory jdktools/ and to prepare patches for build
> > system for building tools from new place.
>
> Cool
>
> >
> > I think the following structure will be appropriate for future
> > evolution of the jdktools:
> >
> > jdktools/trunk/
> > build.xml
> > make/
>
> Can we stop persisting this mistake? Please call it "build" :)
And call 'build' something else like 'target'?
I'm not actually sure calling it build is a good idea because a number
of common projects use build to contain built artifacts. What is your
objection to 'make'?
> > doc/
> > modules/
> > jre/ # keytool, tool launcher go here
> > build.xml # classes go to jdk/jre/lib/tools.jar
> > make/
> > src/
> > jdk/ # javac, jarsigner go here
> > build.xml # classes go to jdk/lib/tools.jar
> > make/
> > src/
> > jdwp/ # separate module for large component
> > build.xml
> > make/
> > src/
>
> Only comment is that we might want to pull the launcher out to be a
> peer. Otherwise, I like it.
I'd be a little tempted by that idea too.
> >
> > Assumptions which look reasonable for jdktool's build subsystem:
> >
> > 1) it works in presence of built classlib (as HDK binaries or as a
> > result of classlib phase of overall build);
>
> yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
> I'd imagine the federated build to then have :
>
> trunk/
> working_classlib/
> working_vm/
> working_jdktools/
>
> > 2) the 'jre' module is always built before building 'jdk' to provide
> > generic tool launcher and the jre/lib/tools.jar. Probably it will be
> > easy to obtain these items from HDK.
>
> That's one reason why I'd pull the launcher out to it's own module
>
> >
> > I'm rather newbie in the Harmony build system so your thoughts will be
> > very helpful.
>
> Ant and make will be your friends here :) Note that you will have
> native issues (because of the launcher), so please track the way that
> classlib does this wrt platforms to start, and if you find things that
> work better, suggest it. Mark and Ollie are wizards here.
>
> I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64)
> if you grok what I mean, and do it in a way that it will be trivial to
> add other OSs or processor architectures (IPF, for example).
> This might be a good place to figure out how this should work going
> forward for harmony, rather than experimenting in classlib.
+1
> >
> > Thank you
>
> No, thank you :)
+1
Regards,
Mark.
> geir
>
> > -Ilya
> >
> >
> > On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
> >> Hi Geir,
> >>
> >> Looks like that creating the "jdktools" source tree and build was
> >> shaded by other tasks. I can help with preparing and checking updates
> >> in the build system. Please let me know what needs to do in this area
> >> (besides svn commits) to complete the task.
> >>
> >> I'm especially interested in completing the move to "jdktools"
> >> structure since there will be a home for the JDWP code, which has beed
> >> voted but still resides in JIRA. Working with SVN will be easier.
> >>
> >> Thanks.
> >> -Ilya
> >>
> >> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > yep, that's the plan. And once we have that, we can simplify the
> >> > launcher as well...
> >> >
> >> > Tim Ellison wrote:
> >> > > +1 for creating a jdktools directory. The dependency on the classlib
> >> > > launcher should be relatively light if we go with a simple tools
> >> > > launcher that rewrites the tool invocation into a generic launcher
> >> > > invocation. You may recall the idea was discussed a while ago.
> >> > >
> >> > > So, for example,
> >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> >> > > is rewritten to
> >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
> >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> >> > >
> >> > > and so on.
> >> > >
> >> > > Regards,
> >> > > Tim
> >> > >
> >> > > Geir Magnusson Jr. wrote:
> >> > >> Geir Magnusson Jr. wrote:
> >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
> >> keytool, I'd
> >> > >>> like to organize these and add them to the next snapshot.
> >> > >> My bad - the javap isn't being voted on yet. I was thinking of
> >> the jdwp
> >> > >> vote... sorry
> >> > >>
> >> > >>> So I propose adding a new top-level directory called "jdktools"
> >> (and
> >> > >>> rename "tools" to "project_tools") and create a build target that -
> >> > >>> with a dependency on classlib for the launcher - creates the
> >> 'stuff'
> >> > >>> needed to fill into the JDK.
> >> > >>>
> >> > >>> Any comments?
> >> > >>>
> >> > >>> geir
> >> > >>>
> >> > ---------------------------------------------------------------------
> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >> >
> >> >
> >>
> >> --
> >> Thank you.
> >> Ilya Neverov,
> >> Intel Middleware Products Division
> >>
> >
>
Re: [general] creation of "jdktools"
Posted by Ilya Neverov <il...@gmail.com>.
Nathan,
thank you for creation of the trunk/working_jdktools.
Geir,
Please look at comment and scripts attached to the HARMONY-2180. I
tried to make them trivial so that reviewing doesn't take much time.
Proposed build system has two levels of enrties:
- working_jdktools/build.xml which can be used for processing all or
selected modules. To be used in federated build;
- working_jdktools/modules/$M/build.xml used for processing the $M
module. These module-level build.xml files can be used while working
with single module.
The working_jdktools/make/ dir contains definitions imported by
modules' build.xml files so few simple buildfiles are required in each
module directory.
I'm going to complete the HARMONY-2180 sub-task in few days to provide
final script set.
Thank you
-Ilya
On 11/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Can you please give us an idea of what you have right now? There's no
> way we can participate with you if we don't have an idea of current
> status...
>
> geir
>
>
> Ilya Neverov wrote:
> > On 10/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > [skip]
> >> > Assumptions which look reasonable for jdktool's build subsystem:
> >> >
> >> > 1) it works in presence of built classlib (as HDK binaries or as a
> >> > result of classlib phase of overall build);
> >>
> >> yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
> >> I'd imagine the federated build to then have :
> >>
> >> trunk/
> >> working_classlib/
> >> working_vm/
> >> working_jdktools/
> >>
> >
> > Commiters,
> >
> > Could you please create empty directory "trunk/working_jdktools".
> >
> > I need it to check building jdktools as part of the federated build.
> > Without having the "working_jdktools/" in the repository the moving
> > sources and patching buiild files would require additional manual
> > steps.
> >
> > Thank you.
> > -Ilya
> >
>
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Can you please give us an idea of what you have right now? There's no
way we can participate with you if we don't have an idea of current
status...
geir
Ilya Neverov wrote:
> On 10/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> [skip]
>> > Assumptions which look reasonable for jdktool's build subsystem:
>> >
>> > 1) it works in presence of built classlib (as HDK binaries or as a
>> > result of classlib phase of overall build);
>>
>> yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
>> I'd imagine the federated build to then have :
>>
>> trunk/
>> working_classlib/
>> working_vm/
>> working_jdktools/
>>
>
> Commiters,
>
> Could you please create empty directory "trunk/working_jdktools".
>
> I need it to check building jdktools as part of the federated build.
> Without having the "working_jdktools/" in the repository the moving
> sources and patching buiild files would require additional manual
> steps.
>
> Thank you.
> -Ilya
>
Re: [general] creation of "jdktools"
Posted by Nathan Beyer <nb...@gmail.com>.
Thanks for trying. I've created the folder. It's at revision 474016.
-Nathan
On 11/12/06, Ilya Neverov <il...@gmail.com> wrote:
> Hi, see below.
>
> On 11/12/06, Nathan Beyer <nb...@gmail.com> wrote:
> > On 11/11/06, Ilya Neverov <il...@gmail.com> wrote:
> > > On 10/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > [skip]
> > > > > Assumptions which look reasonable for jdktool's build subsystem:
> > > > >
> > > > > 1) it works in presence of built classlib (as HDK binaries or as a
> > > > > result of classlib phase of overall build);
> > > >
> > > > yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
> > > > I'd imagine the federated build to then have :
> > > >
> > > > trunk/
> > > > working_classlib/
> > > > working_vm/
> > > > working_jdktools/
> > > >
> > >
> > > Commiters,
> > >
> > > Could you please create empty directory "trunk/working_jdktools".
> > >
> > > I need it to check building jdktools as part of the federated build.
> > > Without having the "working_jdktools/" in the repository the moving
> > > sources and patching buiild files would require additional manual
> > > steps.
> > >
> > > Thank you.
> > > -Ilya
> > >
> >
> > Are you sure? Assuming you checkout the "trunk" folder, can't you just
> > create the "working_jdktools" folder in your working copy and "svn
> > add" it and then perform all of the moves, etc and then create the
> > diff from that. I may be wrong, but I think I've done this before with
> > SVN.
>
> I tried that way but got the svn error on Windows 2003:
> ...
> A trunk\sandbox\geir\build.xml
> Checked out revision 473980.
> > mkdir trunk\working_jdktools
> > svn add trunk\working_jdktools
> A trunk\working_jdktools
> > svn switch -r HEAD "https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jdktools/trunk" trunk\working_jdktools
> svn: Failed to add directory 'trunk\working_jdktools': object of the
> same name already exists
>
> Looks like that 'svn switch' can be done for committed dir only;
> probably the ' schedule="add" ' attribute is erased during the switch
> operation.
>
> I'm trying to prepare modifications which can be committed at once to
> create single revision for the jdktools source move. Currently I use
> simple
> 'svn co "..../jdktools/trunk" trunk\working_jdktools'
> for build checks and such workspace structure would require separate
> commits for trunk/working_jdktools and for jdktools/trunk. So I have
> to ask for this preparation step.
>
> >
> > If not, we can certainly whip it up quick. Would you mind posting the
> > full URL of the folder to create, so we don't screw it up (meaning, so
> > I don't screw it up).
>
> Empty dir
>
> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk/working_jdktools
>
> is asked to be created.
> >
> > -Nathan
> >
>
> Thank you
> -Ilya
>
Re: [general] creation of "jdktools"
Posted by Ilya Neverov <il...@gmail.com>.
Hi, see below.
On 11/12/06, Nathan Beyer <nb...@gmail.com> wrote:
> On 11/11/06, Ilya Neverov <il...@gmail.com> wrote:
> > On 10/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > [skip]
> > > > Assumptions which look reasonable for jdktool's build subsystem:
> > > >
> > > > 1) it works in presence of built classlib (as HDK binaries or as a
> > > > result of classlib phase of overall build);
> > >
> > > yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
> > > I'd imagine the federated build to then have :
> > >
> > > trunk/
> > > working_classlib/
> > > working_vm/
> > > working_jdktools/
> > >
> >
> > Commiters,
> >
> > Could you please create empty directory "trunk/working_jdktools".
> >
> > I need it to check building jdktools as part of the federated build.
> > Without having the "working_jdktools/" in the repository the moving
> > sources and patching buiild files would require additional manual
> > steps.
> >
> > Thank you.
> > -Ilya
> >
>
> Are you sure? Assuming you checkout the "trunk" folder, can't you just
> create the "working_jdktools" folder in your working copy and "svn
> add" it and then perform all of the moves, etc and then create the
> diff from that. I may be wrong, but I think I've done this before with
> SVN.
I tried that way but got the svn error on Windows 2003:
...
A trunk\sandbox\geir\build.xml
Checked out revision 473980.
> mkdir trunk\working_jdktools
> svn add trunk\working_jdktools
A trunk\working_jdktools
> svn switch -r HEAD "https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jdktools/trunk" trunk\working_jdktools
svn: Failed to add directory 'trunk\working_jdktools': object of the
same name already exists
Looks like that 'svn switch' can be done for committed dir only;
probably the ' schedule="add" ' attribute is erased during the switch
operation.
I'm trying to prepare modifications which can be committed at once to
create single revision for the jdktools source move. Currently I use
simple
'svn co "..../jdktools/trunk" trunk\working_jdktools'
for build checks and such workspace structure would require separate
commits for trunk/working_jdktools and for jdktools/trunk. So I have
to ask for this preparation step.
>
> If not, we can certainly whip it up quick. Would you mind posting the
> full URL of the folder to create, so we don't screw it up (meaning, so
> I don't screw it up).
Empty dir
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk/working_jdktools
is asked to be created.
>
> -Nathan
>
Thank you
-Ilya
Re: [general] creation of "jdktools"
Posted by Nathan Beyer <nb...@gmail.com>.
On 11/11/06, Ilya Neverov <il...@gmail.com> wrote:
> On 10/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> [skip]
> > > Assumptions which look reasonable for jdktool's build subsystem:
> > >
> > > 1) it works in presence of built classlib (as HDK binaries or as a
> > > result of classlib phase of overall build);
> >
> > yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
> > I'd imagine the federated build to then have :
> >
> > trunk/
> > working_classlib/
> > working_vm/
> > working_jdktools/
> >
>
> Commiters,
>
> Could you please create empty directory "trunk/working_jdktools".
>
> I need it to check building jdktools as part of the federated build.
> Without having the "working_jdktools/" in the repository the moving
> sources and patching buiild files would require additional manual
> steps.
>
> Thank you.
> -Ilya
>
Are you sure? Assuming you checkout the "trunk" folder, can't you just
create the "working_jdktools" folder in your working copy and "svn
add" it and then perform all of the moves, etc and then create the
diff from that. I may be wrong, but I think I've done this before with
SVN.
If not, we can certainly whip it up quick. Would you mind posting the
full URL of the folder to create, so we don't screw it up (meaning, so
I don't screw it up).
-Nathan
Re: [general] creation of "jdktools"
Posted by Ilya Neverov <il...@gmail.com>.
On 10/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
[skip]
> > Assumptions which look reasonable for jdktool's build subsystem:
> >
> > 1) it works in presence of built classlib (as HDK binaries or as a
> > result of classlib phase of overall build);
>
> yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
> I'd imagine the federated build to then have :
>
> trunk/
> working_classlib/
> working_vm/
> working_jdktools/
>
Commiters,
Could you please create empty directory "trunk/working_jdktools".
I need it to check building jdktools as part of the federated build.
Without having the "working_jdktools/" in the repository the moving
sources and patching buiild files would require additional manual
steps.
Thank you.
-Ilya
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Ilya Neverov wrote:
> Hello,
>
> I want to gather opinions about structure of the "jdktools" component.
>
> I'm going to create scripts for moving tools' sources from classlib/
> to top-level directory jdktools/ and to prepare patches for build
> system for building tools from new place.
Cool
>
> I think the following structure will be appropriate for future
> evolution of the jdktools:
>
> jdktools/trunk/
> build.xml
> make/
Can we stop persisting this mistake? Please call it "build" :)
> doc/
> modules/
> jre/ # keytool, tool launcher go here
> build.xml # classes go to jdk/jre/lib/tools.jar
> make/
> src/
> jdk/ # javac, jarsigner go here
> build.xml # classes go to jdk/lib/tools.jar
> make/
> src/
> jdwp/ # separate module for large component
> build.xml
> make/
> src/
Only comment is that we might want to pull the launcher out to be a
peer. Otherwise, I like it.
>
> Assumptions which look reasonable for jdktool's build subsystem:
>
> 1) it works in presence of built classlib (as HDK binaries or as a
> result of classlib phase of overall build);
yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
I'd imagine the federated build to then have :
trunk/
working_classlib/
working_vm/
working_jdktools/
> 2) the 'jre' module is always built before building 'jdk' to provide
> generic tool launcher and the jre/lib/tools.jar. Probably it will be
> easy to obtain these items from HDK.
That's one reason why I'd pull the launcher out to it's own module
>
> I'm rather newbie in the Harmony build system so your thoughts will be
> very helpful.
Ant and make will be your friends here :) Note that you will have
native issues (because of the launcher), so please track the way that
classlib does this wrt platforms to start, and if you find things that
work better, suggest it. Mark and Ollie are wizards here.
I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64)
if you grok what I mean, and do it in a way that it will be trivial to
add other OSs or processor architectures (IPF, for example). This might
be a good place to figure out how this should work going forward for
harmony, rather than experimenting in classlib.
>
> Thank you
No, thank you :)
geir
> -Ilya
>
>
> On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
>> Hi Geir,
>>
>> Looks like that creating the "jdktools" source tree and build was
>> shaded by other tasks. I can help with preparing and checking updates
>> in the build system. Please let me know what needs to do in this area
>> (besides svn commits) to complete the task.
>>
>> I'm especially interested in completing the move to "jdktools"
>> structure since there will be a home for the JDWP code, which has beed
>> voted but still resides in JIRA. Working with SVN will be easier.
>>
>> Thanks.
>> -Ilya
>>
>> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > yep, that's the plan. And once we have that, we can simplify the
>> > launcher as well...
>> >
>> > Tim Ellison wrote:
>> > > +1 for creating a jdktools directory. The dependency on the classlib
>> > > launcher should be relatively light if we go with a simple tools
>> > > launcher that rewrites the tool invocation into a generic launcher
>> > > invocation. You may recall the idea was discussed a while ago.
>> > >
>> > > So, for example,
>> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
>> > > is rewritten to
>> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
>> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>> > >
>> > > and so on.
>> > >
>> > > Regards,
>> > > Tim
>> > >
>> > > Geir Magnusson Jr. wrote:
>> > >> Geir Magnusson Jr. wrote:
>> > >>> Now that we have javac, javah, javap (if Tim votes ;) and
>> keytool, I'd
>> > >>> like to organize these and add them to the next snapshot.
>> > >> My bad - the javap isn't being voted on yet. I was thinking of
>> the jdwp
>> > >> vote... sorry
>> > >>
>> > >>> So I propose adding a new top-level directory called "jdktools"
>> (and
>> > >>> rename "tools" to "project_tools") and create a build target that -
>> > >>> with a dependency on classlib for the launcher - creates the
>> 'stuff'
>> > >>> needed to fill into the JDK.
>> > >>>
>> > >>> Any comments?
>> > >>>
>> > >>> geir
>> > >>>
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>> --
>> Thank you.
>> Ilya Neverov,
>> Intel Middleware Products Division
>>
>
Re: [general] creation of "jdktools"
Posted by Alexey Petrenko <al...@gmail.com>.
2006/10/31, Ivan Popov <iv...@gmail.com>:
> Ilya,
>
> I'd like this idea. But I think having two tools.jar libraries
> (jdk/jre/lib/tools.jar and jdk/lib/tools.jar) may be quite confusing.
> It's convenient for JDK to have jdk/lib/tools.jar and many programs
> explicitly include it into CLASSPATH. I suggest renaming second
> tools.jar (going to JRE) to jretools.jar or something ike this, so
> we'll have
>
> jdk/jre/lib/jretools.jar
> jdk/lib/tools.jar
+1
>
> which should be less confusing.
>
> Thanks.
> Ivan
>
> On 10/30/06, Ilya Neverov <il...@gmail.com> wrote:
> > Hello,
> >
> > I want to gather opinions about structure of the "jdktools" component.
> >
> > I'm going to create scripts for moving tools' sources from classlib/
> > to top-level directory jdktools/ and to prepare patches for build
> > system for building tools from new place.
> >
> > I think the following structure will be appropriate for future
> > evolution of the jdktools:
> >
> > jdktools/trunk/
> > build.xml
> > make/
> > doc/
> > modules/
> > jre/ # keytool, tool launcher go here
> > build.xml # classes go to jdk/jre/lib/tools.jar
> > make/
> > src/
> > jdk/ # javac, jarsigner go here
> > build.xml # classes go to jdk/lib/tools.jar
> > make/
> > src/
> > jdwp/ # separate module for large component
> > build.xml
> > make/
> > src/
> >
> > Assumptions which look reasonable for jdktool's build subsystem:
> >
> > 1) it works in presence of built classlib (as HDK binaries or as a
> > result of classlib phase of overall build);
> > 2) the 'jre' module is always built before building 'jdk' to provide
> > generic tool launcher and the jre/lib/tools.jar. Probably it will be
> > easy to obtain these items from HDK.
> >
> > I'm rather newbie in the Harmony build system so your thoughts will be
> > very helpful.
> >
> > Thank you
> > -Ilya
>
--
Alexey A. Petrenko
Intel Middleware Products Division
Re: [general] creation of "jdktools"
Posted by Ilya Neverov <il...@gmail.com>.
On 10/31/06, Ivan Popov <iv...@gmail.com> wrote:
> Ilya,
>
> I'd like this idea. But I think having two tools.jar libraries
> (jdk/jre/lib/tools.jar and jdk/lib/tools.jar) may be quite confusing.
> It's convenient for JDK to have jdk/lib/tools.jar and many programs
> explicitly include it into CLASSPATH. I suggest renaming second
> tools.jar (going to JRE) to jretools.jar or something ike this, so
> we'll have
>
> jdk/jre/lib/jretools.jar
> jdk/lib/tools.jar
>
> which should be less confusing.
I agree - it looks better.
I just notice that module names jdk/ and jre/ are misleading also.
These modules are good places for tools implemented thru
org.apache.harmony.tools.<tool>.Main classes. But these modules will
not include all tools which go to JRE or JDK.
Would jdk-java/ and jre-java/ be better names?
-Ilya
>
> Thanks.
> Ivan
>
> On 10/30/06, Ilya Neverov <il...@gmail.com> wrote:
> > Hello,
> >
> > I want to gather opinions about structure of the "jdktools" component.
> >
> > I'm going to create scripts for moving tools' sources from classlib/
> > to top-level directory jdktools/ and to prepare patches for build
> > system for building tools from new place.
> >
> > I think the following structure will be appropriate for future
> > evolution of the jdktools:
> >
> > jdktools/trunk/
> > build.xml
> > make/
> > doc/
> > modules/
> > jre/ # keytool, tool launcher go here
> > build.xml # classes go to jdk/jre/lib/tools.jar
> > make/
> > src/
> > jdk/ # javac, jarsigner go here
> > build.xml # classes go to jdk/lib/tools.jar
> > make/
> > src/
> > jdwp/ # separate module for large component
> > build.xml
> > make/
> > src/
> >
> > Assumptions which look reasonable for jdktool's build subsystem:
> >
> > 1) it works in presence of built classlib (as HDK binaries or as a
> > result of classlib phase of overall build);
> > 2) the 'jre' module is always built before building 'jdk' to provide
> > generic tool launcher and the jre/lib/tools.jar. Probably it will be
> > easy to obtain these items from HDK.
> >
> > I'm rather newbie in the Harmony build system so your thoughts will be
> > very helpful.
> >
> > Thank you
> > -Ilya
>
Re: [general] creation of "jdktools"
Posted by Ivan Popov <iv...@gmail.com>.
Ilya,
I'd like this idea. But I think having two tools.jar libraries
(jdk/jre/lib/tools.jar and jdk/lib/tools.jar) may be quite confusing.
It's convenient for JDK to have jdk/lib/tools.jar and many programs
explicitly include it into CLASSPATH. I suggest renaming second
tools.jar (going to JRE) to jretools.jar or something ike this, so
we'll have
jdk/jre/lib/jretools.jar
jdk/lib/tools.jar
which should be less confusing.
Thanks.
Ivan
On 10/30/06, Ilya Neverov <il...@gmail.com> wrote:
> Hello,
>
> I want to gather opinions about structure of the "jdktools" component.
>
> I'm going to create scripts for moving tools' sources from classlib/
> to top-level directory jdktools/ and to prepare patches for build
> system for building tools from new place.
>
> I think the following structure will be appropriate for future
> evolution of the jdktools:
>
> jdktools/trunk/
> build.xml
> make/
> doc/
> modules/
> jre/ # keytool, tool launcher go here
> build.xml # classes go to jdk/jre/lib/tools.jar
> make/
> src/
> jdk/ # javac, jarsigner go here
> build.xml # classes go to jdk/lib/tools.jar
> make/
> src/
> jdwp/ # separate module for large component
> build.xml
> make/
> src/
>
> Assumptions which look reasonable for jdktool's build subsystem:
>
> 1) it works in presence of built classlib (as HDK binaries or as a
> result of classlib phase of overall build);
> 2) the 'jre' module is always built before building 'jdk' to provide
> generic tool launcher and the jre/lib/tools.jar. Probably it will be
> easy to obtain these items from HDK.
>
> I'm rather newbie in the Harmony build system so your thoughts will be
> very helpful.
>
> Thank you
> -Ilya
Re: [general] creation of "jdktools"
Posted by Mark Hindess <ma...@googlemail.com>.
On 30 October 2006 at 23:55, "Ilya Neverov" <il...@gmail.com> wrote:
> Hello,
>
> I want to gather opinions about structure of the "jdktools" component.
>
> I'm going to create scripts for moving tools' sources from classlib/
> to top-level directory jdktools/ and to prepare patches for build
> system for building tools from new place.
Excellent!
Some general comments (that others might disagree with?):
1) Don't copy the classlib build practice of using separate build.xml
files from java, natives and documentation. Or at least, if you do use
import rather than antcall. Why? Well, besides being more efficient,
importing allows ant dependency resolution to work across all build
files.
2) Consider using subant for the modules, you may need to make it two
stages[0] ... first do modules/jre using a trivial subant task, then a
second subant task to do everything but modules/jre.
3) I recently added the build/ant/properties.xml to the hdk which
contains platform definitions, build/make also contains native code
defines. You should try to use these if possible. (If there are other
things I've missed let me know - this was just the first thing that came
up in my recent abortive attempt to do item 4.)
4) I thought the easiest way to start the tool launcher might be
to just copy (svn copy even) the current launcher. At least we'd
have something that worked. It would then be possible to hack the
java launcher to remove the tools specific code and the tool launcher
could be hacked to remove the vm initialisation code - it should be
replaced with exec("java", ...).
> I think the following structure will be appropriate for future
> evolution of the jdktools:
>
> jdktools/trunk/
> build.xml
> make/
> doc/
> modules/
> jre/ # keytool, tool launcher go here
> build.xml # classes go to jdk/jre/lib/tools.jar
> make/
> src/
> jdk/ # javac, jarsigner go here
> build.xml # classes go to jdk/lib/tools.jar
> make/
> src/
> jdwp/ # separate module for large component
> build.xml
> make/
> src/
Looks reasonable.
> Assumptions which look reasonable for jdktool's build subsystem:
>
> 1) it works in presence of built classlib (as HDK binaries or as a
> result of classlib phase of overall build);
I think it should be an HDK (with hy.hdk defaulting to
"../classlib/deploy" but with a user properties file to override it).
Perhaps something like:
<property file="${user.home}/.harmony-tools.properties" />
<property name="hy.hdk" location="../classlib/deploy" />
> 2) the 'jre' module is always built before building 'jdk' to provide
> generic tool launcher and the jre/lib/tools.jar. Probably it will be
> easy to obtain these items from HDK.
Hmm... Geir was not in favour of updating the hdk directly IIRC?
Perhaps consider a separate deploy tree to begin with.
> I'm rather newbie in the Harmony build system so your thoughts will be
> very helpful.
Fresh eyes are great. It's often useful to have to justify/describe
why/how we are doing things - it makes us think again about our
decisions.
Regards,
Mark.
[0] Statements like this usually trigger Matt Benson to appear on the
list telling me the neat trick for doing this elegantly. ;-)
Re: [general] creation of "jdktools"
Posted by Ilya Neverov <il...@gmail.com>.
Hello,
I want to gather opinions about structure of the "jdktools" component.
I'm going to create scripts for moving tools' sources from classlib/
to top-level directory jdktools/ and to prepare patches for build
system for building tools from new place.
I think the following structure will be appropriate for future
evolution of the jdktools:
jdktools/trunk/
build.xml
make/
doc/
modules/
jre/ # keytool, tool launcher go here
build.xml # classes go to jdk/jre/lib/tools.jar
make/
src/
jdk/ # javac, jarsigner go here
build.xml # classes go to jdk/lib/tools.jar
make/
src/
jdwp/ # separate module for large component
build.xml
make/
src/
Assumptions which look reasonable for jdktool's build subsystem:
1) it works in presence of built classlib (as HDK binaries or as a
result of classlib phase of overall build);
2) the 'jre' module is always built before building 'jdk' to provide
generic tool launcher and the jre/lib/tools.jar. Probably it will be
easy to obtain these items from HDK.
I'm rather newbie in the Harmony build system so your thoughts will be
very helpful.
Thank you
-Ilya
On 10/19/06, Ilya Neverov <il...@gmail.com> wrote:
> Hi Geir,
>
> Looks like that creating the "jdktools" source tree and build was
> shaded by other tasks. I can help with preparing and checking updates
> in the build system. Please let me know what needs to do in this area
> (besides svn commits) to complete the task.
>
> I'm especially interested in completing the move to "jdktools"
> structure since there will be a home for the JDWP code, which has beed
> voted but still resides in JIRA. Working with SVN will be easier.
>
> Thanks.
> -Ilya
>
> On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > yep, that's the plan. And once we have that, we can simplify the
> > launcher as well...
> >
> > Tim Ellison wrote:
> > > +1 for creating a jdktools directory. The dependency on the classlib
> > > launcher should be relatively light if we go with a simple tools
> > > launcher that rewrites the tool invocation into a generic launcher
> > > invocation. You may recall the idea was discussed a while ago.
> > >
> > > So, for example,
> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> > > is rewritten to
> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> > >
> > > and so on.
> > >
> > > Regards,
> > > Tim
> > >
> > > Geir Magnusson Jr. wrote:
> > >> Geir Magnusson Jr. wrote:
> > >>> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
> > >>> like to organize these and add them to the next snapshot.
> > >> My bad - the javap isn't being voted on yet. I was thinking of the jdwp
> > >> vote... sorry
> > >>
> > >>> So I propose adding a new top-level directory called "jdktools" (and
> > >>> rename "tools" to "project_tools") and create a build target that -
> > >>> with a dependency on classlib for the launcher - creates the 'stuff'
> > >>> needed to fill into the JDK.
> > >>>
> > >>> Any comments?
> > >>>
> > >>> geir
> > >>>
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
> Thank you.
> Ilya Neverov,
> Intel Middleware Products Division
>
Re: [general] creation of "jdktools"
Posted by Ilya Neverov <il...@gmail.com>.
Hi Geir,
Looks like that creating the "jdktools" source tree and build was
shaded by other tasks. I can help with preparing and checking updates
in the build system. Please let me know what needs to do in this area
(besides svn commits) to complete the task.
I'm especially interested in completing the move to "jdktools"
structure since there will be a home for the JDWP code, which has beed
voted but still resides in JIRA. Working with SVN will be easier.
Thanks.
-Ilya
On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> yep, that's the plan. And once we have that, we can simplify the
> launcher as well...
>
> Tim Ellison wrote:
> > +1 for creating a jdktools directory. The dependency on the classlib
> > launcher should be relatively light if we go with a simple tools
> > launcher that rewrites the tool invocation into a generic launcher
> > invocation. You may recall the idea was discussed a while ago.
> >
> > So, for example,
> > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> > is rewritten to
> > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
> > org.apache.harmony.tools.javac.Main -source 1.5 FooBar
> >
> > and so on.
> >
> > Regards,
> > Tim
> >
> > Geir Magnusson Jr. wrote:
> >> Geir Magnusson Jr. wrote:
> >>> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
> >>> like to organize these and add them to the next snapshot.
> >> My bad - the javap isn't being voted on yet. I was thinking of the jdwp
> >> vote... sorry
> >>
> >>> So I propose adding a new top-level directory called "jdktools" (and
> >>> rename "tools" to "project_tools") and create a build target that -
> >>> with a dependency on classlib for the launcher - creates the 'stuff'
> >>> needed to fill into the JDK.
> >>>
> >>> Any comments?
> >>>
> >>> geir
> >>>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Thank you.
Ilya Neverov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
yep, that's the plan. And once we have that, we can simplify the
launcher as well...
Tim Ellison wrote:
> +1 for creating a jdktools directory. The dependency on the classlib
> launcher should be relatively light if we go with a simple tools
> launcher that rewrites the tool invocation into a generic launcher
> invocation. You may recall the idea was discussed a while ago.
>
> So, for example,
> jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> is rewritten to
> jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
> org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>
> and so on.
>
> Regards,
> Tim
>
> Geir Magnusson Jr. wrote:
>> Geir Magnusson Jr. wrote:
>>> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
>>> like to organize these and add them to the next snapshot.
>> My bad - the javap isn't being voted on yet. I was thinking of the jdwp
>> vote... sorry
>>
>>> So I propose adding a new top-level directory called "jdktools" (and
>>> rename "tools" to "project_tools") and create a build target that -
>>> with a dependency on classlib for the launcher - creates the 'stuff'
>>> needed to fill into the JDK.
>>>
>>> Any comments?
>>>
>>> geir
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by Ivan Popov <iv...@gmail.com>.
+1 from me too.
I'd like idea of having separate directory for all tools going to JDK
and including them into federal build.
Ivan.
On 10/4/06, Tim Ellison <t....@gmail.com> wrote:
> +1 for creating a jdktools directory. The dependency on the classlib
> launcher should be relatively light if we go with a simple tools
> launcher that rewrites the tool invocation into a generic launcher
> invocation. You may recall the idea was discussed a while ago.
>
> So, for example,
> jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
> is rewritten to
> jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
> org.apache.harmony.tools.javac.Main -source 1.5 FooBar
>
> and so on.
>
> Regards,
> Tim
>
> Geir Magnusson Jr. wrote:
> > Geir Magnusson Jr. wrote:
> >> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
> >> like to organize these and add them to the next snapshot.
> >
> > My bad - the javap isn't being voted on yet. I was thinking of the jdwp
> > vote... sorry
> >
> >>
> >> So I propose adding a new top-level directory called "jdktools" (and
> >> rename "tools" to "project_tools") and create a build target that -
> >> with a dependency on classlib for the launcher - creates the 'stuff'
> >> needed to fill into the JDK.
> >>
> >> Any comments?
> >>
> >> geir
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> 2006/10/4, Salikh Zakirov <Sa...@intel.com>:
>> Tim Ellison wrote:
>> > +1 for creating a jdktools directory. The dependency on the classlib
>> > launcher should be relatively light if we go with a simple tools
>> > launcher that rewrites the tool invocation into a generic launcher
>> > invocation. You may recall the idea was discussed a while ago.
>>
>> Could anyone shed the light why launcher is considered part of classlib?
>>
>> As far as I understand, it depends on standard JNI Invocation API,
>> and some Harmony-wide conventions about property names and files.
>> I would suggest that we move launcher from classlib/ to jdktools/ as
>> well.
>
> +1 to move launcher out of classlib. I was going to suggest this too.
Agreed -- just in there for historical reasons, it should be pulled out.
Regards,
Tim
>> Sorry if I am missing something.
>>
>> P.S. +1 for original idea to create jdktools/
>
>
>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by Alexey Varlamov <al...@gmail.com>.
2006/10/4, Salikh Zakirov <Sa...@intel.com>:
> Tim Ellison wrote:
> > +1 for creating a jdktools directory. The dependency on the classlib
> > launcher should be relatively light if we go with a simple tools
> > launcher that rewrites the tool invocation into a generic launcher
> > invocation. You may recall the idea was discussed a while ago.
>
> Could anyone shed the light why launcher is considered part of classlib?
>
> As far as I understand, it depends on standard JNI Invocation API,
> and some Harmony-wide conventions about property names and files.
> I would suggest that we move launcher from classlib/ to jdktools/ as well.
+1 to move launcher out of classlib. I was going to suggest this too.
>
> Sorry if I am missing something.
>
> P.S. +1 for original idea to create jdktools/
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by Salikh Zakirov <Sa...@Intel.com>.
Tim Ellison wrote:
> +1 for creating a jdktools directory. The dependency on the classlib
> launcher should be relatively light if we go with a simple tools
> launcher that rewrites the tool invocation into a generic launcher
> invocation. You may recall the idea was discussed a while ago.
Could anyone shed the light why launcher is considered part of classlib?
As far as I understand, it depends on standard JNI Invocation API,
and some Harmony-wide conventions about property names and files.
I would suggest that we move launcher from classlib/ to jdktools/ as well.
Sorry if I am missing something.
P.S. +1 for original idea to create jdktools/
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by Tim Ellison <t....@gmail.com>.
+1 for creating a jdktools directory. The dependency on the classlib
launcher should be relatively light if we go with a simple tools
launcher that rewrites the tool invocation into a generic launcher
invocation. You may recall the idea was discussed a while ago.
So, for example,
jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
is rewritten to
jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
org.apache.harmony.tools.javac.Main -source 1.5 FooBar
and so on.
Regards,
Tim
Geir Magnusson Jr. wrote:
> Geir Magnusson Jr. wrote:
>> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
>> like to organize these and add them to the next snapshot.
>
> My bad - the javap isn't being voted on yet. I was thinking of the jdwp
> vote... sorry
>
>>
>> So I propose adding a new top-level directory called "jdktools" (and
>> rename "tools" to "project_tools") and create a build target that -
>> with a dependency on classlib for the launcher - creates the 'stuff'
>> needed to fill into the JDK.
>>
>> Any comments?
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Geir Magnusson Jr. wrote:
> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
> like to organize these and add them to the next snapshot.
My bad - the javap isn't being voted on yet. I was thinking of the jdwp
vote... sorry
>
> So I propose adding a new top-level directory called "jdktools" (and
> rename "tools" to "project_tools") and create a build target that - with
> a dependency on classlib for the launcher - creates the 'stuff' needed
> to fill into the JDK.
>
> Any comments?
>
> geir
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by Tim Ellison <t....@gmail.com>.
Alexei Zakharov wrote:
>> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
>
> BTW, we have more tools indeed. I mean RMI tools:
>
> rmic <-> java org.apache.harmony.rmi.compiler.Main
> rmid <-> java org.apache.harmony.rmi.activation.Rmid
> rmiregistry <-> java org.apache.harmony.rmi.registry.RegistryImpl
>
> We can hack the launcher to enable these three tools too. Seven tools
> is more than just four. :)
Cool -- yes. I suggest that we create adapters called
'org.apache.harmony.tools.rmic.Main' and so on in tools.jar to keep the
tools launcher code simple and consistent.
Regards,
Tim
> 2006/10/2, Geir Magnusson Jr. <ge...@pobox.com>:
>> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
>> like to organize these and add them to the next snapshot.
>>
>> So I propose adding a new top-level directory called "jdktools" (and
>> rename "tools" to "project_tools") and create a build target that - with
>> a dependency on classlib for the launcher - creates the 'stuff' needed
>> to fill into the JDK.
>>
>> Any comments?
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
indeed :)
Alexei Zakharov wrote:
>> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
>
> BTW, we have more tools indeed. I mean RMI tools:
>
> rmic <-> java org.apache.harmony.rmi.compiler.Main
> rmid <-> java org.apache.harmony.rmi.activation.Rmid
> rmiregistry <-> java org.apache.harmony.rmi.registry.RegistryImpl
>
> We can hack the launcher to enable these three tools too. Seven tools
> is more than just four. :)
>
> Regards,
>
> 2006/10/2, Geir Magnusson Jr. <ge...@pobox.com>:
>> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
>> like to organize these and add them to the next snapshot.
>>
>> So I propose adding a new top-level directory called "jdktools" (and
>> rename "tools" to "project_tools") and create a build target that - with
>> a dependency on classlib for the launcher - creates the 'stuff' needed
>> to fill into the JDK.
>>
>> Any comments?
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [general] creation of "jdktools"
Posted by Alexei Zakharov <al...@gmail.com>.
> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
BTW, we have more tools indeed. I mean RMI tools:
rmic <-> java org.apache.harmony.rmi.compiler.Main
rmid <-> java org.apache.harmony.rmi.activation.Rmid
rmiregistry <-> java org.apache.harmony.rmi.registry.RegistryImpl
We can hack the launcher to enable these three tools too. Seven tools
is more than just four. :)
Regards,
2006/10/2, Geir Magnusson Jr. <ge...@pobox.com>:
> Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd
> like to organize these and add them to the next snapshot.
>
> So I propose adding a new top-level directory called "jdktools" (and
> rename "tools" to "project_tools") and create a build target that - with
> a dependency on classlib for the launcher - creates the 'stuff' needed
> to fill into the JDK.
>
> Any comments?
>
> geir
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org