On Jan 7, 2007, at 5:50 PM, Alex Blewitt wrote:
On 07/01/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
From what I grok, Alex has problems with
1) not having patches applied fast enough
-> 1) I vote that Alexei is responsible for getting patches in SVN :)
It's not so much the patches being applied fast enough. The problem is
that if I'm adding a new file, and I contribute that, I effectively
can't work on it any more until the file is applied. That's because
when it's subsequently added SVN throws a wobbly and refuses to do
anything because there's a file already there. I'm going to get this
anyway -- solution is to delete and then svn up -- but if I've made
changes to that file (or someone else has made changes that I don't
have) then any further changes get lost. It's less of a problem when
there are already added files there, but most patches I've submitted
have had new files in place, and it does take me a while to sync after
a patch has been applied.
Right - that's not a solution. You shouldn't have to do otherworldly
and weird things like that.
Now, I'm expecting that over time, other contributors will have or do
have the same problems, so we should work out a suggested method for
doing this.
How about svk?
As such, I've found it easier to wait until a patch has been applied,
so that I can do an svn up knowing I've not lost any of my new files.
2) not being able to keep the code at Java 1.4 for portabliity
-> 2) This I think we can handle easily - can we add a small CC
target
that simply compiles this package as 1.4 code? While it doesn't
prevent someone from making an inappropriate change, it does ensure
that if it is changed, it's identified and reversed quickly.
That doesn't help for people who try to genericise the code, for
example.
Why? it wouldn't compile.
Plus, the manifest should list J2SE-1.4 as its requirements,
and not J2SE-1.5 (or J2SE-5 or whatever it is).
That's only because there's one manifest at the moment - there's no
reason why there can't be other build targets, and therefore other
manifests.
There's also the issue
of compile time libraries; you can compile against a 1.5 system with
1.4 code compatibility, but still end up using e.g. System.nanoTime()
inadvertently. As a separate project, with 1.4 in the manifest, I can
actually compile against the real 1.4 VM libraries on my machine; and
know that I'm not going to get burnt by accidental inclusion of an API
that's not there.
Right - so how do we do this so that there's the appropriate maifest
for you?
Lets try this - what does the manifest look like?
3) ease of use working w/in eclipse because of other packages (java/
util/*) as well as manifest drek
-> 3) I don't quite know what to do here, other than setup a work
environment in a sandbox where we use the svn switch trick to just
let the code get checked out as a workable tree, yet still have the
checkins happen where we like them to be, in the archive tree
Or, just have a separate module. Plus, if there's going to be a
separate bundle generated, why not use the fact that one module is a
bundle? Why go to all the trouble of setting up a build library that
has this separation and then try and force two bundles to live in one
module?
Because I think that our notion of module was defined with
architectural boundaries for the classlibrary, not issues like this.
So I'm against it being a classlib module.
It may make sense as a jkdtools module for which the classlib has a
dependency - that's not that much better, but it's an improvement.
4) what else?
Well, I've also made the point about messages and internationalisation
thereof. The goal is for this to be separately downloadable outside of
the Harmony APIs; therefore, mixing up messages designed for this
bundle with messages in the generic Java util library.
Ah - yes. I remember that and meant to say something about it in my
last message (today is my last day of vacation and I'm distracted...)
Yes, there should be separate messages.
The same also goes for the Apache NLS classes. The Pack200 stuff can't
rely on that for internationalisation without dragging extra baggage
with it. This has already been applied once to the strings in the
pack200 code, and I had to manually undo it.
Sure - the key here is to respect these boundaries and you shouldn't
have to undo - you should squawk and someone who made the change
should fix it.
I'm hoping we can find solutions to these. Some suggestions about
the individual pieces...
Personally, I'd also like to hear from people about why moving this
out into a separate module is a bad idea. There seems to be resistance
for resistance's sake ("No, let's try and find a way to keep it the
same") as opposed to a justification ("We shouldn't do that because
..."). I've been arguing since the beginning that it made sense to
keep it separate, and justified the reasons for doing so. I don't
believe that there have been reasons given against moving it out, just
that it should not be moved out.
Because our module structure is organized around well-thought-out
boundaries for a classlibrary for java SE 5, not because of a
developers issues w/ SVN or our message bundle system or any of the
other reasons.
I certainly understand the arguments for separation.
Another solution is to simply have Alex submit a work environment
that we place in the sandbox, and from time to time we migrate code
from there into modules/archive?
Frankly, it's probably easier for me to continue development on a
completely different repository. If you're going to go to the extent
of doing a wait and merge, it's going to be far easier for me to work
against an SVN repo that I can commit directly, and then build myself
and make available for anyone (including Harmony) that wants to use
it.
Well, that is always your choice. I'd prefer not to see that happen
- having you do the work here is great. I think that we need to just
find solutions to these problems that we're all happy with.
geir
Looking forward to your thoughts,
Alex.
