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 22:01:58 GMT
Yarg.

Ok, I'm really, really sorry that it took me this long to speak up -  
I had meant to for a while, but was letting people discuss, and also  
sorta got burned out in December, and didn't think anyone would do  
anything until we all got going in the New Year, but Alexei took me  
by surprise.  Serves me right for waiting, I guess.

First, I think that in the future, we need to be more proactive and  
clearer about things like this.  I don't think we have consensus -  
clearly I'd count Tim and Nathan as indicating a preference to avoid  
a new module, and I am not in favor of another module either, for  
both technical and community reasons.

That said, I'd also like to see us find a solution where Alex is  
happy and he can keep doing this great work on it.  I suspect that in  
the end, no one will get everything they want, but we maybe be able  
to find a better position than where we are now.

 From what I grok, Alex has problems with

1) not having patches applied fast enough

2) not being able to keep the code at Java 1.4 for portabliity

3) ease of use working w/in eclipse because of other packages (java/ 
util/*) as well as manifest drek

4) what else?

I'm hoping we can find solutions to these.  Some suggestions about  
the individual pieces...

1) I vote that Alexei is responsible for getting patches in SVN :)

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.

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

4)?

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?

geir



On Jan 7, 2007, at 4:24 AM, Alex Blewitt wrote:

> Great, thanks for that. I'll investigate the Segment test ... it's
> probably because it was looking a resource up by name and if the
> resources/ have moved into the harmony/pack200 folder it can't find
> them. Shouldn't be too tricky to fix.
>
> I'll also update the Manifest and/or other files that fixing and
> submit a patch shortly.
>
> Thanks again!
>
> Alex.
>
> On 06/01/07, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
>> Hi all,
>>
>> I've just finished with moving pack200 code to the new module
>> (r493560). The name of the new module is "pack200" (no surprises),  
>> new
>> package names start with "org.apache.harmony.pack200". The build can
>> be customized for using arbitrary build source and build target (Alex
>> has asked for it). One test is currently failing:
>> org/apache/harmony/pack200/tests/SegmentTest
>> so I've put it to the exclude list. I don't know why does it fail,
>> probably because of the package name change. I suppose Alex can shed
>> light on it.  There are also files that probably need fixing -
>> META-INF/MANIFEST.MF for example. So patches are welcome as always.
>>
>> I've seen build failure alerts after my commits - there were problems
>> with ant clean. After running ant clean twice all problems disappear
>> on my machine. So..
>>
>> Thanks for your attention and Merry Christmas to the Orthodox part of
>> the community,
>>
>> 2006/12/14, Alexei Zakharov <alexei.zakharov@gmail.com>:
>> > All,
>> >
>> > Does anyone have real objections to this Alex's proposal? If no  
>> I can
>> > take care of it.
>> >
>> > Thanks,
>> >
>> > 2006/12/14, Alex Blewitt <alex.blewitt@gmail.com>:
>> > > > Agreed, in general we cannot serialize on waiting for  
>> patches to be
>> > > > committed before moving on, and keeping track of your  
>> development can be
>> > > > a problem in the face of multiple patches and commits etc.
>> > >
>> > > Actually, in this case, there is no patch. This is the discussion
>> > > about moving the pack200 code to a separate module [1], like  
>> I've been
>> > > suggesting from the beginning [2], so that it can be built with a
>> > > lower Java version (both via the build.xml, the associated  
>> Eclipse
>> > > metadata and the compliance settings for the bundle itself)  
>> than the
>> > > remainder of the archive module. It will also mean that we  
>> don't end
>> > > up with messages being mixed together, which will be more of a  
>> problem
>> > > when it comes to distributing the decoding as a separate bundle
>> > > externally to Harmony, which was one of my original  
>> motiviations in
>> > > doing this [2]
>> > >
>> > > In any case, it doesn't make sense to me to be in-flight doing  
>> work
>> > > whilst the code is in the wrong place (from my point of view, at
>> > > least). Generating SVN patches after doing a lot of (renaming)
>> > > refactoring seems to break things, and the only way that the most
>> > > recent set of code was integrated was by me providing the entire
>> > > contents of the project that I was working on. If there's  
>> directory
>> > > moves (and/or package names, if it moves to a different  
>> module) then
>> > > it's going to make that process a lot more painful than it  
>> already is.
>> > >
>> > > I'm sure there's reasons why the general feeling is that it  
>> shouldn't
>> > > be moved out into its own module, but I've not seen a  
>> suggestion yet
>> > > which addresses the issues I've outlined above; though please  
>> let me
>> > > know if I've misunderstood something and it is in fact possible.
>> > >
>> > > Unfortunately, I get the feeling we're at an impasse on this,  
>> and that
>> > > in order to achieve my original goal of having an  
>> implementation that
>> > > could be used by other OSGi systems, it would be better to  
>> develop
>> > > this as an entirely standalone OSGi bundle which Harmony could  
>> then
>> > > chose to use if it wanted. This isn't my preferred option,  
>> since after
>> > > all Harmony needs this code, and it's likely to be a better up- 
>> stream
>> > > source for changes in the future, but rather than me trying to
>> > > repeatedly initiate conversations about why I think it would  
>> be better
>> > > to move it to a separate module, it will likely be easier for  
>> me to
>> > > develop code against a repository which I have write access  
>> and an
>> > > structure it appropriately. Since it too will be licensed  
>> under AL,
>> > > Harmony can then chose to take advantage of it or someone else  
>> can
>> > > continue working on the codebase so far.
>> > >
>> > > Alex.
>> > >
>> > > [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony- 
>> dev/200610.mbox/% 
>> 3C636fd28e0610141654rcd650f8x32c7c2b311a5fd65@mail.gmail.com%3E
>> > >
>> > > [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony- 
>> dev/200605.mbox/% 
>> 3c636fd28e0605251346m47a5289ch1e61ce611d0de615@mail.gmail.com%3e
>>
>> --
>> Alexei Zakharov,
>> Intel ESSD
>>


Mime
View raw message