You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2009/07/21 16:55:25 UTC
[general] jdktools and classlib?
If you are reading the commits list, you will have noticed that I've
been making a few improvements to the ant scripts in classlib. I've
still got a way to go before I've finished the refactoring but I've
already started wondering about doing the same thing for jdktools.
But the question that sprang to mind was why am I doing it twice. Why
not just have the jdktools modules as modules in classlib? You don't
really lose anything in modularity since all classlib modules can be
checked out alone and built against an hdk.
I think we'd gain in that jdktools might get a little more attention if
it was built and tested with classlib[0]. (Currently it would break
quite a few ports since samsa seems to have quite a few linux-isms.
I'll fix these shortly though.)
Of course, it adds a little (20M on top of 250M) to the checkout
footprint and the build/test takes a little longer so there is a
downside.
I've read the original thread[1] but I still don't see a good
argument[2] for this separation. What do other people think?
Regards,
Mark.
[0] and trunk -> branches/java6 merged with classlib
[1] http://markmail.org/thread/l44kkyiom45ks6e6
[2] That thread did contain an argument but not a good one and not one
related to this topic. ;-)
Re: [general] jdktools and classlib?
Posted by Alexey Varlamov <al...@gmail.com>.
I think Oliver has made really good argument. Once I refactored out to
common_resources quite a few duplicated build functions from drlvm and
jdktools, but somehow did not gain enough momentum to push classlib in
this direction - I guess people were reluctant to force dependency on
federated build?
I still think common_resources would be the best way to mitigate build
maintenance efforts, even more so if extended with the vision Oliver's
suggested.
Really I don't see why jdktools could get more attention if merged to
classlib. OTOH, from VM development point of view I'd be bothered with
extra build&test time of basic JRE. Surely this could be coped with
via predefined module sets, but the point is lost then.
Regards,
Alexey
2009/7/23 Oliver Deakin <ol...@googlemail.com>:
> Tim Ellison wrote:
>>
>> On 23/Jul/2009 09:43, Sean Qiu wrote:
>>
>>>
>>> Do we really need this big change?
>>>
>>> There are so many "duplicated" xml files whose original goal is to
>>> achieve modularity.
>>> So each component can be developed and tested separately.
>>> I guess that's the reason that we got so many build scripts on each
>>> modules of classlib.
>>> (It is another story whether they worked as we expected)
>>>
>>> I prefer to keep jdktools and classlib separately, it sounds more natural
>>> to me.
>>>
>>
>> My gut feeling is also to keep the class library and jdktools separated,
>> but I'll admit that it is only a gut feeling and not something I can
>> defend technically.
>>
>> If it really does make life easier for build then it is something I
>> could learn to live with. I'd like to hear the arguments though.
>>
>
> I agree. It just feels to me like the VM and classlib are obvious "units"
> and putting the additional jre/jdk tools in with either one of them doesn't
> sit right. If our goals are to get the jdktools used/looked at more and to
> unify the build scripts as much as possible, then I would suggest improving
> the federated build for wider use.
>
> At the moment if a contributor wants to just work on classlib, they will
> probably just check out classlib trunk and build from there copying in
> whichever VM they wish to use. I think it would be better if we made the
> federated build the starting point for this kind of development and improved
> the build targets it provides so it plays nicely when working with
> individual components. For this to work we would need to allow more control
> over what source gets checked out/built/tested, so they more closely reflect
> the targets within the components - here's a few examples of what I was
> thinking of (names like hy.component are just suggestions, not really
> important):
>
> "ant -Dhy.component=classlib,jdktools populate-src" - just checkout the
> source for classlib and jdktools
> "ant -Dhy.component=classlib rebuild-native" - just clean and build the
> native code for the classlib module, and automatically populate the built
> binaries under the federated target directory
> "ant build-java" - build java code across all components. This target could
> detect which components have been checked out, much as the classlib build
> works out which modules to build automatically by checking if build targets
> exists, and only build those so that hy.component does not always need to be
> specified.
>
>
> The above is just a rough idea of how it could be done, but I can see a few
> advantages of this approach:
> 1) The federated build would get used more, giving us a more unified
> approach to building Harmony while still allowing contributors to work in
> individual areas with the same ease. This should also help remove some of
> the build script duplication across components.
> 2) The java/javaw executables could be moved to jdktools (which makes more
> sense than classlib to me) meaning that jdktools would get more attention
> also.
> 3) The common_resources directory would work for those working on the whole
> jdk and also for those just working on one or two components, as they would
> both use the federated build.
> 4) If we ever wanted to add components (for example, split portlib into it's
> own component) it would be easier managed.
> 5) If you started working on drlvm only and also wanted to make some changes
> to classlib later on, you could just run populate-src specifying the
> classlib component to check out the additional source and then carry on
> working.
>
> These are just ideas at the moment, but I can see there are benefits to this
> approach. Any thoughts/comments?
>
> Regards,
> Oliver
>
>> Regards,
>> Tim
>>
>>
>>
>
> --
> Oliver Deakin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>
>
Re: [general] jdktools and classlib?
Posted by Oliver Deakin <ol...@googlemail.com>.
Mark Hindess wrote:
> In message <4A...@googlemail.com>, Oliver Deakin writes:
>
>> Tim Ellison wrote:
>>
>>> On 23/Jul/2009 09:43, Sean Qiu wrote:
>>>
>>>
>>>> Do we really need this big change?
>>>>
>>>> There are so many "duplicated" xml files whose original goal is to
>>>> achieve modularity.
>>>> So each component can be developed and tested separately.
>>>> I guess that's the reason that we got so many build scripts on each
>>>> modules of classlib.
>>>> (It is another story whether they worked as we expected)
>>>>
>>>> I prefer to keep jdktools and classlib separately, it sounds more
>>>> natural to me.
>>>>
>>>>
>>> My gut feeling is also to keep the class library and jdktools
>>> separated, but I'll admit that it is only a gut feeling and not
>>> something I can defend technically.
>>>
>>> If it really does make life easier for build then it is something I
>>> could learn to live with. I'd like to hear the arguments though.
>>>
>>>
>> I agree. It just feels to me like the VM and classlib are obvious
>> "units" and putting the additional jre/jdk tools in with either one
>> of them doesn't sit right.
>>
>
> I'm still not sure I've heard a convincing technical argument about the
> current split.
I not sure I've heard a convincing technical argument not to have them
split :) A long time ago the tools were another module of classlib, and
general concensus seemed to be that they would be better organised as a
separate component to the class libraries, so they were split. I think
the rationale was simply that all the other modules were part of the
class libraries except for the "tools" module and as such it was a bit
of an odd-one-out. Separating the tools from the class libraries made
sense from a source organisation point of view rather than a technical one.
> I feel sure we'd all be just as happy if the original
> split had been vm and non-vm. (I really think of this split as the VM
> and the frontends to the VM that users generally use and it seems quite
> natural to me.)
>
I might argue that this is not really a convincing technical argument to
separate the VM and other components' source from each other, which at
the moment seems to result in having quite different organisation of
code between VM and classlib and different build systems (cpptasks vs.
make). I think the real reason is that separating their source into
different locations just makes organisational sense because they are
clearly separate layers of the JDK [1], and I would argue similarly for
the jdktools component.
> (I think deep down Oli isn't convinced either since he recently sent
> a message to the dev@ list with tags "[classlib][jdwp]" and made no
>
I was just demonstrating how separate classlib is from jdwp by not
mentioning it in my mail ;)
> mention of anything classlib-related AFAICT. ;-)
>
> However, I think improving the federated build so that it could be used
> by those currently working with just classlib (or jdktools or vm) would
> be a reasonable compromise.
>
>
>> If our goals are to get the jdktools
>> used/looked at more and to unify the build scripts as much as
>> possible, then I would suggest improving the federated build for wider
>> use.
>>
>> At the moment if a contributor wants to just work on classlib, they
>> will probably just check out classlib trunk and build from there
>> copying in whichever VM they wish to use. I think it would be better
>> if we made the federated build the starting point for this kind of
>> development and improved the build targets it provides so it plays
>> nicely when working with individual components. For this to work
>> we would need to allow more control over what source gets checked
>> out/built/tested, so they more closely reflect the targets within the
>> components - here's a few examples of what I was thinking of (names
>> like hy.component are just suggestions, not really important):
>>
>> "ant -Dhy.component=classlib,jdktools populate-src" - just checkout the
>> source for classlib and jdktools
>> "ant -Dhy.component=classlib rebuild-native" - just clean and build the
>> native code for the classlib module, and automatically populate the
>> built binaries under the federated target directory
>> "ant build-java" - build java code across all components. This target
>> could detect which components have been checked out, much as the
>> classlib build works out which modules to build automatically by
>> checking if build targets exists, and only build those so that
>> hy.component does not always need to be specified.
>>
>>
>> The above is just a rough idea of how it could be done, but I can see a
>> few advantages of this approach:
>> 1) The federated build would get used more, giving us a more unified
>> approach to building Harmony while still allowing contributors to work
>> in individual areas with the same ease. This should also help remove
>> some of the build script duplication across components.
>> 2) The java/javaw executables could be moved to jdktools (which makes
>> more sense than classlib to me) meaning that jdktools would get more
>> attention also.
>> 3) The common_resources directory would work for those working on the
>> whole jdk and also for those just working on one or two components, as
>> they would both use the federated build.
>> 4) If we ever wanted to add components (for example, split portlib into
>> it's own component) it would be easier managed.
>> 5) If you started working on drlvm only and also wanted to make some
>> changes to classlib later on, you could just run populate-src specifying
>> the classlib component to check out the additional source and then carry
>> on working.
>>
>
> I like this idea. If we are going to improve the federated build can
> we also:
>
> 1) Find a way to reduce coupling. Currently federated/build.xml know
> too much about DRLVM - things like the "set overwrite flag to take
> hythr from VM" comment.
>
> 2) Call the directories drlvm, jdktools and classlib rather than working_*.
>
> 3) Allow the choice of VM component to be overridden - default 'drlvm'.
>
+1 to all 3 of these.
>
>> These are just ideas at the moment, but I can see there are benefits to
>> this approach. Any thoughts/comments?
>>
>
> Perhaps we could create a new federated sandbox to work out ideas?
>
That sounds like a good starting point.
Regards,
Oliver
[1] http://java.sun.com/j2se/1.5.0/docs/images/j2se5.gif
> Regards,
> Mark.
>
>
>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [general] jdktools and classlib?
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4A...@googlemail.com>, Oliver Deakin writes:
>
> Tim Ellison wrote:
> > On 23/Jul/2009 09:43, Sean Qiu wrote:
> >
> >> Do we really need this big change?
> >>
> >> There are so many "duplicated" xml files whose original goal is to
> >> achieve modularity.
> >> So each component can be developed and tested separately.
> >> I guess that's the reason that we got so many build scripts on each
> >> modules of classlib.
> >> (It is another story whether they worked as we expected)
> >>
> >> I prefer to keep jdktools and classlib separately, it sounds more
> >> natural to me.
> >>
> >
> > My gut feeling is also to keep the class library and jdktools
> > separated, but I'll admit that it is only a gut feeling and not
> > something I can defend technically.
> >
> > If it really does make life easier for build then it is something I
> > could learn to live with. I'd like to hear the arguments though.
> >
>
> I agree. It just feels to me like the VM and classlib are obvious
> "units" and putting the additional jre/jdk tools in with either one
> of them doesn't sit right.
I'm still not sure I've heard a convincing technical argument about the
current split. I feel sure we'd all be just as happy if the original
split had been vm and non-vm. (I really think of this split as the VM
and the frontends to the VM that users generally use and it seems quite
natural to me.)
(I think deep down Oli isn't convinced either since he recently sent
a message to the dev@ list with tags "[classlib][jdwp]" and made no
mention of anything classlib-related AFAICT. ;-)
However, I think improving the federated build so that it could be used
by those currently working with just classlib (or jdktools or vm) would
be a reasonable compromise.
> If our goals are to get the jdktools
> used/looked at more and to unify the build scripts as much as
> possible, then I would suggest improving the federated build for wider
> use.
>
> At the moment if a contributor wants to just work on classlib, they
> will probably just check out classlib trunk and build from there
> copying in whichever VM they wish to use. I think it would be better
> if we made the federated build the starting point for this kind of
> development and improved the build targets it provides so it plays
> nicely when working with individual components. For this to work
> we would need to allow more control over what source gets checked
> out/built/tested, so they more closely reflect the targets within the
> components - here's a few examples of what I was thinking of (names
> like hy.component are just suggestions, not really important):
>
> "ant -Dhy.component=classlib,jdktools populate-src" - just checkout the
> source for classlib and jdktools
> "ant -Dhy.component=classlib rebuild-native" - just clean and build the
> native code for the classlib module, and automatically populate the
> built binaries under the federated target directory
> "ant build-java" - build java code across all components. This target
> could detect which components have been checked out, much as the
> classlib build works out which modules to build automatically by
> checking if build targets exists, and only build those so that
> hy.component does not always need to be specified.
>
>
> The above is just a rough idea of how it could be done, but I can see a
> few advantages of this approach:
> 1) The federated build would get used more, giving us a more unified
> approach to building Harmony while still allowing contributors to work
> in individual areas with the same ease. This should also help remove
> some of the build script duplication across components.
> 2) The java/javaw executables could be moved to jdktools (which makes
> more sense than classlib to me) meaning that jdktools would get more
> attention also.
> 3) The common_resources directory would work for those working on the
> whole jdk and also for those just working on one or two components, as
> they would both use the federated build.
> 4) If we ever wanted to add components (for example, split portlib into
> it's own component) it would be easier managed.
> 5) If you started working on drlvm only and also wanted to make some
> changes to classlib later on, you could just run populate-src specifying
> the classlib component to check out the additional source and then carry
> on working.
I like this idea. If we are going to improve the federated build can
we also:
1) Find a way to reduce coupling. Currently federated/build.xml know
too much about DRLVM - things like the "set overwrite flag to take
hythr from VM" comment.
2) Call the directories drlvm, jdktools and classlib rather than working_*.
3) Allow the choice of VM component to be overridden - default 'drlvm'.
> These are just ideas at the moment, but I can see there are benefits to
> this approach. Any thoughts/comments?
Perhaps we could create a new federated sandbox to work out ideas?
Regards,
Mark.
Re: [general] jdktools and classlib?
Posted by Oliver Deakin <ol...@googlemail.com>.
Tim Ellison wrote:
> On 23/Jul/2009 09:43, Sean Qiu wrote:
>
>> Do we really need this big change?
>>
>> There are so many "duplicated" xml files whose original goal is to
>> achieve modularity.
>> So each component can be developed and tested separately.
>> I guess that's the reason that we got so many build scripts on each
>> modules of classlib.
>> (It is another story whether they worked as we expected)
>>
>> I prefer to keep jdktools and classlib separately, it sounds more natural to me.
>>
>
> My gut feeling is also to keep the class library and jdktools separated,
> but I'll admit that it is only a gut feeling and not something I can
> defend technically.
>
> If it really does make life easier for build then it is something I
> could learn to live with. I'd like to hear the arguments though.
>
I agree. It just feels to me like the VM and classlib are obvious
"units" and putting the additional jre/jdk tools in with either one of
them doesn't sit right. If our goals are to get the jdktools used/looked
at more and to unify the build scripts as much as possible, then I would
suggest improving the federated build for wider use.
At the moment if a contributor wants to just work on classlib, they will
probably just check out classlib trunk and build from there copying in
whichever VM they wish to use. I think it would be better if we made the
federated build the starting point for this kind of development and
improved the build targets it provides so it plays nicely when working
with individual components. For this to work we would need to allow more
control over what source gets checked out/built/tested, so they more
closely reflect the targets within the components - here's a few
examples of what I was thinking of (names like hy.component are just
suggestions, not really important):
"ant -Dhy.component=classlib,jdktools populate-src" - just checkout the
source for classlib and jdktools
"ant -Dhy.component=classlib rebuild-native" - just clean and build the
native code for the classlib module, and automatically populate the
built binaries under the federated target directory
"ant build-java" - build java code across all components. This target
could detect which components have been checked out, much as the
classlib build works out which modules to build automatically by
checking if build targets exists, and only build those so that
hy.component does not always need to be specified.
The above is just a rough idea of how it could be done, but I can see a
few advantages of this approach:
1) The federated build would get used more, giving us a more unified
approach to building Harmony while still allowing contributors to work
in individual areas with the same ease. This should also help remove
some of the build script duplication across components.
2) The java/javaw executables could be moved to jdktools (which makes
more sense than classlib to me) meaning that jdktools would get more
attention also.
3) The common_resources directory would work for those working on the
whole jdk and also for those just working on one or two components, as
they would both use the federated build.
4) If we ever wanted to add components (for example, split portlib into
it's own component) it would be easier managed.
5) If you started working on drlvm only and also wanted to make some
changes to classlib later on, you could just run populate-src specifying
the classlib component to check out the additional source and then carry
on working.
These are just ideas at the moment, but I can see there are benefits to
this approach. Any thoughts/comments?
Regards,
Oliver
> Regards,
> Tim
>
>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [general] jdktools and classlib?
Posted by Tim Ellison <t....@gmail.com>.
On 23/Jul/2009 09:43, Sean Qiu wrote:
> Do we really need this big change?
>
> There are so many "duplicated" xml files whose original goal is to
> achieve modularity.
> So each component can be developed and tested separately.
> I guess that's the reason that we got so many build scripts on each
> modules of classlib.
> (It is another story whether they worked as we expected)
>
> I prefer to keep jdktools and classlib separately, it sounds more natural to me.
My gut feeling is also to keep the class library and jdktools separated,
but I'll admit that it is only a gut feeling and not something I can
defend technically.
If it really does make life easier for build then it is something I
could learn to live with. I'd like to hear the arguments though.
Regards,
Tim
Re: [general] jdktools and classlib?
Posted by Sean Qiu <se...@gmail.com>.
Do we really need this big change?
There are so many "duplicated" xml files whose original goal is to
achieve modularity.
So each component can be developed and tested separately.
I guess that's the reason that we got so many build scripts on each
modules of classlib.
(It is another story whether they worked as we expected)
I prefer to keep jdktools and classlib separately, it sounds more natural to me.
Best Regards
Sean, Xiao Xia Qiu
2009/7/23 Nathan Beyer <nb...@gmail.com>:
> On Wed, Jul 22, 2009 at 3:01 AM, Regis<xu...@gmail.com> wrote:
>> Mark Hindess wrote:
>>>
>>> In message <4A...@gmail.com>, Regis writes:
>>>>
>>>> Mark Hindess wrote:
>>>>>
>>>>> If you are reading the commits list, you will have noticed that I've
>>>>> been making a few improvements to the ant scripts in classlib. I've
>>>>> still got a way to go before I've finished the refactoring but I've
>>>>> already started wondering about doing the same thing for jdktools.
>>>>>
>>>>> But the question that sprang to mind was why am I doing it twice.
>>>>> Why not just have the jdktools modules as modules in classlib? You
>>>>> don't really lose anything in modularity since all classlib modules
>>>>> can be checked out alone and built against an hdk.
>>>>
>>>> For me, this may be a bit confused - jdktools is not a part of
>>>> classlib. If I wanted to see code of jdwp, I would never thought it
>>>> was in classlib.
>>>
>>> But you would look for jre tools in the jdktools component? I didn't
>>
>> I guess so, since JDK includes a JRE, it makes sense for me.
>>
>>> really intend for this to be about the names since we've largely been
>>> happy to ignore the incorrect jdktools one for a long time. Instead of
>>> 'classlib' just think of a name that means everything-except-the-vm and
>>> consider what I wrote again. Does it make more sense now?
>>
>> I agree that move them together make things easier, but still not sure
>> 'classlib' is right place to put all them in. I can think 'classlib' means
>> 'everything-except-the-vm', but not everyone can, especially ones just join
>> the community.
>
> Then we change the name to have it make more sense.
>
> -Nathan
>
>>
>>>
>>>> For Ant script, I'm not familiar with it, just flying thinking, is
>>>> it possible to extract common parts or make some templates to reduce
>>>> maintain efforts?
>>>
>>> There is already some sharing between components. I'm increasing the
>>> use of common code in classlib at the module level at the moment. We
>>> could do more sharing across components but refactoring these takes
>>> quite a bit of (elapsed) time[3].
>>>
>>> I guess I just don't understand why we don't just have two components:
>>>
>>> 1) VM (which can be replaced by another VM and was a modular structure
>>> to allow parts to be replaced, etc)
>>>
>>> 2) Everything else (which also has a modular structure that allows
>>> a downstream user to pick and choose the bits they need or wish to
>>> replace.
>>>
>>> -Mark.
>>>
>>>>> I think we'd gain in that jdktools might get a little more attention
>>>>> if it was built and tested with classlib[0]. (Currently it would
>>>>> break quite a few ports since samsa seems to have quite a few
>>>>> linux-isms. I'll fix these shortly though.)
>>>>>
>>>>> Of course, it adds a little (20M on top of 250M) to the checkout
>>>>> footprint and the build/test takes a little longer so there is a
>>>>> downside.
>>>>>
>>>>> I've read the original thread[1] but I still don't see a good
>>>>> argument[2] for this separation. What do other people think?
>>>>>
>>>>> Regards,
>>>>> Mark.
>>>>>
>>>>> [0] and trunk -> branches/java6 merged with classlib
>>>>>
>>>>> [1] http://markmail.org/thread/l44kkyiom45ks6e6
>>>>>
>>>>> [2] That thread did contain an argument but not a good one and not one
>>>>> related to this topic. ;-)
>>>
>>> [3] The changes are usually fairly straight-forward but testing each
>>> change
>>> at federated-build, classlib, classlib-module, and hdk levels takes a
>>> long time to run. And there are lots of changes that could/should be
>>> made.
>>>
>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Regis.
>>
>
Re: [general] jdktools and classlib?
Posted by Nathan Beyer <nb...@gmail.com>.
On Wed, Jul 22, 2009 at 3:01 AM, Regis<xu...@gmail.com> wrote:
> Mark Hindess wrote:
>>
>> In message <4A...@gmail.com>, Regis writes:
>>>
>>> Mark Hindess wrote:
>>>>
>>>> If you are reading the commits list, you will have noticed that I've
>>>> been making a few improvements to the ant scripts in classlib. I've
>>>> still got a way to go before I've finished the refactoring but I've
>>>> already started wondering about doing the same thing for jdktools.
>>>>
>>>> But the question that sprang to mind was why am I doing it twice.
>>>> Why not just have the jdktools modules as modules in classlib? You
>>>> don't really lose anything in modularity since all classlib modules
>>>> can be checked out alone and built against an hdk.
>>>
>>> For me, this may be a bit confused - jdktools is not a part of
>>> classlib. If I wanted to see code of jdwp, I would never thought it
>>> was in classlib.
>>
>> But you would look for jre tools in the jdktools component? I didn't
>
> I guess so, since JDK includes a JRE, it makes sense for me.
>
>> really intend for this to be about the names since we've largely been
>> happy to ignore the incorrect jdktools one for a long time. Instead of
>> 'classlib' just think of a name that means everything-except-the-vm and
>> consider what I wrote again. Does it make more sense now?
>
> I agree that move them together make things easier, but still not sure
> 'classlib' is right place to put all them in. I can think 'classlib' means
> 'everything-except-the-vm', but not everyone can, especially ones just join
> the community.
Then we change the name to have it make more sense.
-Nathan
>
>>
>>> For Ant script, I'm not familiar with it, just flying thinking, is
>>> it possible to extract common parts or make some templates to reduce
>>> maintain efforts?
>>
>> There is already some sharing between components. I'm increasing the
>> use of common code in classlib at the module level at the moment. We
>> could do more sharing across components but refactoring these takes
>> quite a bit of (elapsed) time[3].
>>
>> I guess I just don't understand why we don't just have two components:
>>
>> 1) VM (which can be replaced by another VM and was a modular structure
>> to allow parts to be replaced, etc)
>>
>> 2) Everything else (which also has a modular structure that allows
>> a downstream user to pick and choose the bits they need or wish to
>> replace.
>>
>> -Mark.
>>
>>>> I think we'd gain in that jdktools might get a little more attention
>>>> if it was built and tested with classlib[0]. (Currently it would
>>>> break quite a few ports since samsa seems to have quite a few
>>>> linux-isms. I'll fix these shortly though.)
>>>>
>>>> Of course, it adds a little (20M on top of 250M) to the checkout
>>>> footprint and the build/test takes a little longer so there is a
>>>> downside.
>>>>
>>>> I've read the original thread[1] but I still don't see a good
>>>> argument[2] for this separation. What do other people think?
>>>>
>>>> Regards,
>>>> Mark.
>>>>
>>>> [0] and trunk -> branches/java6 merged with classlib
>>>>
>>>> [1] http://markmail.org/thread/l44kkyiom45ks6e6
>>>>
>>>> [2] That thread did contain an argument but not a good one and not one
>>>> related to this topic. ;-)
>>
>> [3] The changes are usually fairly straight-forward but testing each
>> change
>> at federated-build, classlib, classlib-module, and hdk levels takes a
>> long time to run. And there are lots of changes that could/should be
>> made.
>>
>>
>>
>
>
> --
> Best Regards,
> Regis.
>
Re: [general] jdktools and classlib?
Posted by Regis <xu...@gmail.com>.
Mark Hindess wrote:
> In message <4A...@gmail.com>, Regis writes:
>> Mark Hindess wrote:
>>> If you are reading the commits list, you will have noticed that I've
>>> been making a few improvements to the ant scripts in classlib. I've
>>> still got a way to go before I've finished the refactoring but I've
>>> already started wondering about doing the same thing for jdktools.
>>>
>>> But the question that sprang to mind was why am I doing it twice.
>>> Why not just have the jdktools modules as modules in classlib? You
>>> don't really lose anything in modularity since all classlib modules
>>> can be checked out alone and built against an hdk.
>> For me, this may be a bit confused - jdktools is not a part of
>> classlib. If I wanted to see code of jdwp, I would never thought it
>> was in classlib.
>
> But you would look for jre tools in the jdktools component? I didn't
I guess so, since JDK includes a JRE, it makes sense for me.
> really intend for this to be about the names since we've largely been
> happy to ignore the incorrect jdktools one for a long time. Instead of
> 'classlib' just think of a name that means everything-except-the-vm and
> consider what I wrote again. Does it make more sense now?
I agree that move them together make things easier, but still not sure
'classlib' is right place to put all them in. I can think 'classlib' means
'everything-except-the-vm', but not everyone can, especially ones just join the
community.
>
>> For Ant script, I'm not familiar with it, just flying thinking, is
>> it possible to extract common parts or make some templates to reduce
>> maintain efforts?
>
> There is already some sharing between components. I'm increasing the
> use of common code in classlib at the module level at the moment. We
> could do more sharing across components but refactoring these takes
> quite a bit of (elapsed) time[3].
>
> I guess I just don't understand why we don't just have two components:
>
> 1) VM (which can be replaced by another VM and was a modular structure
> to allow parts to be replaced, etc)
>
> 2) Everything else (which also has a modular structure that allows
> a downstream user to pick and choose the bits they need or wish to
> replace.
>
> -Mark.
>
>>> I think we'd gain in that jdktools might get a little more attention
>>> if it was built and tested with classlib[0]. (Currently it would
>>> break quite a few ports since samsa seems to have quite a few
>>> linux-isms. I'll fix these shortly though.)
>>>
>>> Of course, it adds a little (20M on top of 250M) to the checkout
>>> footprint and the build/test takes a little longer so there is a
>>> downside.
>>>
>>> I've read the original thread[1] but I still don't see a good
>>> argument[2] for this separation. What do other people think?
>>>
>>> Regards,
>>> Mark.
>>>
>>> [0] and trunk -> branches/java6 merged with classlib
>>>
>>> [1] http://markmail.org/thread/l44kkyiom45ks6e6
>>>
>>> [2] That thread did contain an argument but not a good one and not one
>>> related to this topic. ;-)
>
> [3] The changes are usually fairly straight-forward but testing each change
> at federated-build, classlib, classlib-module, and hdk levels takes a
> long time to run. And there are lots of changes that could/should be
> made.
>
>
>
--
Best Regards,
Regis.
Re: [general] jdktools and classlib?
Posted by Tim Ellison <t....@gmail.com>.
On 23/Jul/2009 09:45, Sean Qiu wrote:
> 2009/7/22 Mark Hindess <ma...@googlemail.com>:
>> [3] The changes are usually fairly straight-forward but testing each change
>> at federated-build, classlib, classlib-module, and hdk levels takes a
>> long time to run. And there are lots of changes that could/should be
>> made.
>
> Strongly agree with you.
>
> Do we have any public testing server from Apache?
> Can we run these tests with the Hudson Server of ASF?
Feel free to set up temporary Hudson jobs to run additional tests during
refactoring, then you can storm away while Hudson is coming along behind
testing for you. Just don't break things too much for the rest of us :)
Regards,
Tim
Re: [general] jdktools and classlib?
Posted by Sean Qiu <se...@gmail.com>.
Best Regards
Sean, Xiao Xia Qiu
2009/7/22 Mark Hindess <ma...@googlemail.com>:
>
> In message <4A...@gmail.com>, Regis writes:
>>
>> Mark Hindess wrote:
>> >
>> > If you are reading the commits list, you will have noticed that I've
>> > been making a few improvements to the ant scripts in classlib. I've
>> > still got a way to go before I've finished the refactoring but I've
>> > already started wondering about doing the same thing for jdktools.
>> >
>> > But the question that sprang to mind was why am I doing it twice.
>> > Why not just have the jdktools modules as modules in classlib? You
>> > don't really lose anything in modularity since all classlib modules
>> > can be checked out alone and built against an hdk.
>>
>> For me, this may be a bit confused - jdktools is not a part of
>> classlib. If I wanted to see code of jdwp, I would never thought it
>> was in classlib.
>
> But you would look for jre tools in the jdktools component? I didn't
> really intend for this to be about the names since we've largely been
> happy to ignore the incorrect jdktools one for a long time. Instead of
> 'classlib' just think of a name that means everything-except-the-vm and
> consider what I wrote again. Does it make more sense now?
>
>> For Ant script, I'm not familiar with it, just flying thinking, is
>> it possible to extract common parts or make some templates to reduce
>> maintain efforts?
>
> There is already some sharing between components. I'm increasing the
> use of common code in classlib at the module level at the moment. We
> could do more sharing across components but refactoring these takes
> quite a bit of (elapsed) time[3].
>
> I guess I just don't understand why we don't just have two components:
>
> 1) VM (which can be replaced by another VM and was a modular structure
> to allow parts to be replaced, etc)
>
> 2) Everything else (which also has a modular structure that allows
> a downstream user to pick and choose the bits they need or wish to
> replace.
>
> -Mark.
>
>> > I think we'd gain in that jdktools might get a little more attention
>> > if it was built and tested with classlib[0]. (Currently it would
>> > break quite a few ports since samsa seems to have quite a few
>> > linux-isms. I'll fix these shortly though.)
>> >
>> > Of course, it adds a little (20M on top of 250M) to the checkout
>> > footprint and the build/test takes a little longer so there is a
>> > downside.
>> >
>> > I've read the original thread[1] but I still don't see a good
>> > argument[2] for this separation. What do other people think?
>> >
>> > Regards,
>> > Mark.
>> >
>> > [0] and trunk -> branches/java6 merged with classlib
>> >
>> > [1] http://markmail.org/thread/l44kkyiom45ks6e6
>> >
>> > [2] That thread did contain an argument but not a good one and not one
>> > related to this topic. ;-)
>
> [3] The changes are usually fairly straight-forward but testing each change
> at federated-build, classlib, classlib-module, and hdk levels takes a
> long time to run. And there are lots of changes that could/should be
> made.
>
Strongly agree with you.
Do we have any public testing server from Apache?
Can we run these tests with the Hudson Server of ASF?
>
>
Re: [general] jdktools and classlib?
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4A...@gmail.com>, Regis writes:
>
> Mark Hindess wrote:
> >
> > If you are reading the commits list, you will have noticed that I've
> > been making a few improvements to the ant scripts in classlib. I've
> > still got a way to go before I've finished the refactoring but I've
> > already started wondering about doing the same thing for jdktools.
> >
> > But the question that sprang to mind was why am I doing it twice.
> > Why not just have the jdktools modules as modules in classlib? You
> > don't really lose anything in modularity since all classlib modules
> > can be checked out alone and built against an hdk.
>
> For me, this may be a bit confused - jdktools is not a part of
> classlib. If I wanted to see code of jdwp, I would never thought it
> was in classlib.
But you would look for jre tools in the jdktools component? I didn't
really intend for this to be about the names since we've largely been
happy to ignore the incorrect jdktools one for a long time. Instead of
'classlib' just think of a name that means everything-except-the-vm and
consider what I wrote again. Does it make more sense now?
> For Ant script, I'm not familiar with it, just flying thinking, is
> it possible to extract common parts or make some templates to reduce
> maintain efforts?
There is already some sharing between components. I'm increasing the
use of common code in classlib at the module level at the moment. We
could do more sharing across components but refactoring these takes
quite a bit of (elapsed) time[3].
I guess I just don't understand why we don't just have two components:
1) VM (which can be replaced by another VM and was a modular structure
to allow parts to be replaced, etc)
2) Everything else (which also has a modular structure that allows
a downstream user to pick and choose the bits they need or wish to
replace.
-Mark.
> > I think we'd gain in that jdktools might get a little more attention
> > if it was built and tested with classlib[0]. (Currently it would
> > break quite a few ports since samsa seems to have quite a few
> > linux-isms. I'll fix these shortly though.)
> >
> > Of course, it adds a little (20M on top of 250M) to the checkout
> > footprint and the build/test takes a little longer so there is a
> > downside.
> >
> > I've read the original thread[1] but I still don't see a good
> > argument[2] for this separation. What do other people think?
> >
> > Regards,
> > Mark.
> >
> > [0] and trunk -> branches/java6 merged with classlib
> >
> > [1] http://markmail.org/thread/l44kkyiom45ks6e6
> >
> > [2] That thread did contain an argument but not a good one and not one
> > related to this topic. ;-)
[3] The changes are usually fairly straight-forward but testing each change
at federated-build, classlib, classlib-module, and hdk levels takes a
long time to run. And there are lots of changes that could/should be
made.
Re: [general] jdktools and classlib?
Posted by Regis <xu...@gmail.com>.
Mark Hindess wrote:
> If you are reading the commits list, you will have noticed that I've
> been making a few improvements to the ant scripts in classlib. I've
> still got a way to go before I've finished the refactoring but I've
> already started wondering about doing the same thing for jdktools.
>
> But the question that sprang to mind was why am I doing it twice. Why
> not just have the jdktools modules as modules in classlib? You don't
> really lose anything in modularity since all classlib modules can be
> checked out alone and built against an hdk.
For me, this may be a bit confused - jdktools is not a part of classlib. If I
wanted to see code of jdwp, I would never thought it was in classlib.
For Ant script, I'm not familiar with it, just flying thinking, is it possible
to extract common parts or make some templates to reduce maintain efforts?
>
> I think we'd gain in that jdktools might get a little more attention if
> it was built and tested with classlib[0]. (Currently it would break
> quite a few ports since samsa seems to have quite a few linux-isms.
> I'll fix these shortly though.)
>
> Of course, it adds a little (20M on top of 250M) to the checkout
> footprint and the build/test takes a little longer so there is a
> downside.
>
> I've read the original thread[1] but I still don't see a good
> argument[2] for this separation. What do other people think?
>
> Regards,
> Mark.
>
> [0] and trunk -> branches/java6 merged with classlib
>
> [1] http://markmail.org/thread/l44kkyiom45ks6e6
>
> [2] That thread did contain an argument but not a good one and not one
> related to this topic. ;-)
>
>
>
--
Best Regards,
Regis.
Re: [general] jdktools and classlib?
Posted by Nathan Beyer <nd...@apache.org>.
A mashup that creates "jdklibs" ...
I know I don't pay much attention to the jdktools portion, so that
does seem like a strong point.
On Tue, Jul 21, 2009 at 9:55 AM, Mark
Hindess<ma...@googlemail.com> wrote:
>
> If you are reading the commits list, you will have noticed that I've
> been making a few improvements to the ant scripts in classlib. I've
> still got a way to go before I've finished the refactoring but I've
> already started wondering about doing the same thing for jdktools.
>
> But the question that sprang to mind was why am I doing it twice. Why
> not just have the jdktools modules as modules in classlib? You don't
> really lose anything in modularity since all classlib modules can be
> checked out alone and built against an hdk.
>
> I think we'd gain in that jdktools might get a little more attention if
> it was built and tested with classlib[0]. (Currently it would break
> quite a few ports since samsa seems to have quite a few linux-isms.
> I'll fix these shortly though.)
>
> Of course, it adds a little (20M on top of 250M) to the checkout
> footprint and the build/test takes a little longer so there is a
> downside.
>
> I've read the original thread[1] but I still don't see a good
> argument[2] for this separation. What do other people think?
>
> Regards,
> Mark.
>
> [0] and trunk -> branches/java6 merged with classlib
>
> [1] http://markmail.org/thread/l44kkyiom45ks6e6
>
> [2] That thread did contain an argument but not a good one and not one
> related to this topic. ;-)
>
>
>