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
Hi, see below.
On 11/12/06, Nathan Beyer [EMAIL PROTECTED] wrote:
On 11/11/06, Ilya Neverov [EMAIL PROTECTED] wrote:
On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
[skip]
Assumptions which look reasonable for jdktool's build subsystem:
1) it works in presence of built
Thanks for trying. I've created the folder. It's at revision 474016.
-Nathan
On 11/12/06, Ilya Neverov [EMAIL PROTECTED] wrote:
Hi, see below.
On 11/12/06, Nathan Beyer [EMAIL PROTECTED] wrote:
On 11/11/06, Ilya Neverov [EMAIL PROTECTED] wrote:
On 10/31/06, Geir Magnusson Jr. [EMAIL
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. [EMAIL PROTECTED] wrote:
[skip]
Assumptions which look reasonable for jdktool's
On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
On 11/11/06, Ilya Neverov [EMAIL PROTECTED] wrote:
On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
On 30 October 2006 at 23:55, Ilya Neverov [EMAIL PROTECTED] 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
On 30 October 2006 at 18:38, Geir Magnusson Jr. [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote:
On 30 October 2006 at 18:38, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
+1
IMHO make is still much better than build
Regards,
2006/10/31, Ilya Neverov [EMAIL PROTECTED]:
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
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
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
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,
On 31 October 2006 at 7:24, Geir Magnusson Jr. [EMAIL PROTECTED] 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
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
On 10/31/06, Ivan Popov [EMAIL PROTECTED] 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
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
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)
2006/10/31, Ivan Popov [EMAIL PROTECTED]:
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
On 10/31/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 31 October 2006 at 7:24, Geir Magnusson Jr. [EMAIL PROTECTED] 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
Nathan Beyer wrote:
On 10/31/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 31 October 2006 at 7:24, Geir Magnusson Jr. [EMAIL PROTECTED] 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
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
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
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
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
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
Alexey Varlamov wrote:
2006/10/4, Salikh Zakirov [EMAIL PROTECTED]:
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
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
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
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
2006/10/4, Salikh Zakirov [EMAIL PROTECTED]:
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
+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,
+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 [EMAIL PROTECTED] wrote:
+1 for creating a jdktools directory. The dependency on the classlib
launcher should be relatively light if we
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
34 matches
Mail list logo
