harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][pack200] new module (was: [classlib][pack200] Development has stalled :-( )
Date Sun, 07 Jan 2007 23:38:00 GMT

On Jan 7, 2007, at 5:50 PM, Alex Blewitt wrote:

> On 07/01/07, Geir Magnusson Jr. <geir@pobox.com> 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.


Mime
View raw message