Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=UrwJttyNXkHOGiB8SmSmgcWJwei2V/q27RS4qeNY7G/Ub1e0MTN+1VkgOm9KoG7oxDtL+0t8iz7DQrswS6HimSk8CfjiXEJwdzssriHQfS859G5fC0p90qTnB0ufuy31uA9NTckgelYDSpqAKTUpOgdBBkdYIXrjGp6X0VPPfJM=
Message-ID: <46FD15CD.6050601@gmail.com>
Date: Fri, 28 Sep 2007 15:55:09 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib] [pack200] Using BCEL for Pack200
References: <fc2fc95c0709280236y32071b77k53d1ed2662cfd842@mail.gmail.com>
	 <46FCDCBF.3080706@gmail.com>
	 <f944d83d0709280459r1535a87eyc0ed223b8f38f428@mail.gmail.com>
 <fc2fc95c0709280525j7419a2aawd6db7d690da46341@mail.gmail.com>
In-Reply-To: <fc2fc95c0709280525j7419a2aawd6db7d690da46341@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Sian January wrote:
> Yes - BCEL is already in the classlib build,

Duh, yes (it's Friday, thank goodness).

> my question was really about
> how to get the individual pack200 module to find it when I'm just working on
> that module on its own (in Eclipse if that's relevant).  I tried adding
> org.apache.bcel to the list of imported packages in MANIFEST.MF but I think
> I also need to get another plug-in to export it.  Is that right?

Yes, I took a look and the BCEL code is not participating in our target
structure as an OSGi module.  To do that we can simply create a new
manifest for it (like we do for the other dependencies that we adopt as
modules).

The advantage of making BCEL a module is that we can then specify
particular version dependency ranges etc using the pack200 modules
dependencies, and import only the packages that BCEL exports, thereby
avoiding building dependencies on its internals.

The alternative is to use it as a regular JAR dependency, and for that
you just need to tell Eclipse about it in the Pack200 build path.  You
should use the ECLIPSE_HOME variable as the root of the target so that
other people can use the same build path on their systems, and the
modular builds work against a HDK.

i.e.
Index: pack200/.classpath
===================================================================
--- pack200/.classpath	(revision 579314)
+++ pack200/.classpath	(working copy)
@@ -6,5 +6,6 @@
 	<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
 	<classpathentry kind="var" path="JUNIT_HOME/junit.jar"
sourcepath="JUNIT_SRC_HOME/junitsrc.zip"/>
 	<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.4"/>
+	<classpathentry kind="var" path="ECLIPSE_HOME/bcel-5.2/bcel-5.2.jar"/>
 	<classpathentry kind="output" path="bin/main"/>
 </classpath>


Regards,
Tim

> On 28/09/2007, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>> 2007/9/28, Tim Ellison <t.p.ellison@gmail.com>:
>>> Sian January wrote:
>>>> I would like to use BCEL in pack200 to re-create class files from the
>> data
>>>> obtained from the pack200 archive.  BCEL is able to create class files
>> in
>>>> the correct format and provides a higher-level interface that we would
>> use
>>>> instead of creating the class files directly.  This would mean that we
>> would
>>>> not need to duplicate this effort in pack200 and so there would be
>> less
>>>> scope for creating bugs in this area.  I know that BCEL is already a
>> Harmony
>>>> dependency and it's an Apache project so I can't see there being a
>> licence
>>>> issue, but just wondered if anyone has any other objections?
>>> There is no problem with using BCEL as you say.  At the moment it is a
>>> dependency of the DRLVM and you will need to move it to be a dependency
>>> of the classlib code, and then DRLVM can inherit this dependency I
>> believe.
>>
>> Tim,
>> You might confuse bcel with antlr? bcel is already in classlib,
>> make/depends.properties says:
>> # bcel is needed by yoko-rmi
>>
>>>> If not, could anyone suggest what would be the best way to add the
>> BCEL jar
>>>> file as a dependency to the pack200 project, given that it's already
>> in
>>>> Harmony?
>>> Take a look at the classlib tree's make/depends.xml and
>>> make/depends.properties to see how they are handled there for other
>>> modules.  These classlib dependencies are managed 'globally' (i.e. not
>>> per module).
>>>
>>> Regards,
>>> Tim
>>>
>>>
> 
> 
>