From dev-return-22713-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Sun Jan 07 09:25:11 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 71946 invoked from network); 7 Jan 2007 09:25:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Jan 2007 09:25:10 -0000 Received: (qmail 31702 invoked by uid 500); 7 Jan 2007 09:25:15 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 31679 invoked by uid 500); 7 Jan 2007 09:25:15 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 31669 invoked by uid 99); 7 Jan 2007 09:25:15 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Jan 2007 01:25:15 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of alex.blewitt@gmail.com designates 64.233.182.189 as permitted sender) Received: from [64.233.182.189] (HELO nf-out-0910.google.com) (64.233.182.189) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Jan 2007 01:25:06 -0800 Received: by nf-out-0910.google.com with SMTP id a4so8834545nfc for ; Sun, 07 Jan 2007 01:24:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YAkwitOTqfvYuRwtq9FHA608fHcBXkRLmVGogD+BSGM1fwG26JvUFmv7sp85inH7w3oSVAlu+68R0YeHxwit+JODSi8UELfh65Pf02ztN8KrQi2m56PgZXtP/GHZJWibl+bXyceA0+voH8T7RLzsLS1UyXAjt0U1VxwiWST9iKA= Received: by 10.78.201.2 with SMTP id y2mr5214300huf.1168161884702; Sun, 07 Jan 2007 01:24:44 -0800 (PST) Received: by 10.78.100.6 with HTTP; Sun, 7 Jan 2007 01:24:44 -0800 (PST) Message-ID: <636fd28e0701070124j1cd16db1r9a9651862cdf36b6@mail.gmail.com> Date: Sun, 7 Jan 2007 09:24:44 +0000 From: "Alex Blewitt" To: dev@harmony.apache.org Subject: Re: [classlib][pack200] new module (was: [classlib][pack200] Development has stalled :-( ) In-Reply-To: <2c9597b90701061246j749bd7ccydc48ae15415d674d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2c9597b90701061246j749bd7ccydc48ae15415d674d@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org 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 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 : > > 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 : > > > > 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 >