harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sian January" <sianjanu...@googlemail.com>
Subject Re: [classlib] [pack200] Using BCEL for Pack200
Date Mon, 01 Oct 2007 08:41:14 GMT
Thanks Tim - that's really helpful.  I think it would be good to create a
manifest for BCEL because we may find we want to use it in another module at
some point, and it's always good to avoid creating dependencies on internal
APIs.

Thanks,

Sian


On 28/09/2007, Tim Ellison <t.p.ellison@gmail.com> wrote:
>
> 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
> >>>
> >>>
> >
> >
> >
>



-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message