Author Login
Post Reply
> -----Original Message-----
> From: Thorsten Kamann [mailto:thorsten.kamann@(protected)]
> Sent: Friday, January 11, 2008 4:04 PM
> To: eclipse-plugin-dev@(protected)
> Subject: Re: [groovy-eclipse-plugin-dev] split org.codehaus.groovy
plugin
>
> Dave Dunkin schrieb:
> > The goal as I stated before is to reduce the runtime plugin to only
what
> > is required so it can be used in RCP applications without taking up
so
> > much space.
> >
>
> Sorry my question was too unexact. I meant what you want to do with
the
> library plugin. But this you have already answered :)
>
> > Here's what I have in my workspace right now:
> > org.codehaus.groovy
> > - groovy-all-1.5.1.jar
> >
> Could be in org.codehaus.groovy.runtime.library
I think this would be a mistake because it is inconsistent with Eclipse
conventions. For example, the Xerces plugin from Eclipse is
org.apache.xerces not org.apache.xerces.runtime.library.
>
> > org.codehaus.groovy.source
> > - src/org.codehaus.groovy_1.5.1/groovy-all-1.5.1src.zip
> >
> Could be in org.codehaus.groovy.runtime.library.source
> > org.codehaus.groovy.eclipse.core
> > - lib/asm-2.2.jar
> > - lib/asm-tree-2.2.jar
> > - lib/antlr-2.7.6.jar
> > - lib/groovy-1.5.1.jar
> > - lib/commons-io-1.3.1.jar
> > - lib/commons-lang-2.3.jar
> >
> Could be in org.codehaus.groovy.runtime.library or in
> org.codehaus.groovy.runtime.dependencies
> > org.codehaus.groovy uses the jarjar'd version to avoid conflicts
with
> > anything else that may use asm, antlr or commons-cli.
> > org.codehaus.groovy.eclipse.core contains the non-jarjar'd version
> > because it uses the antlr classes.
> >
> The stuff out of org.codehaus.groovy is only used for runtime. This
Jar
> will be the one in the Groovy Libraries Classpath Container.
> The stuff in org.codehaus.groovy.eclipse.core is used for development.
> Thsi are the deps you need for your RCP app. Right?
In my RCP projects I just use the Groovy runtime, groovy.* and
org.codehaus.groovy.*.
>
>
> > Adding the OSGi headers to the main groovy build would also be a
good
> > way to do it.
> >
> This I would prefer. But we have to take a look if the dependency jars
> (asm, antlr,...) are available as plugins, too. Otherwise we need a
> org.codehaus.groovy.dependencies plugin to provide this deps.
That may not be a bad approach. In my RCP projects, I create wrapper
plugins for all my 3rd party plugins. It helps keep everything separate
and clean and lets me reuse plugins between projects. If we did this we
wouldn't really even need to use the jarjar'd version because we could
let OSGi handle and version discrepancies at runtime.
>
>
> --
> Thorsten Kamann
> Software-Architect, Consultant, Coaching
> Germany, NRW
>
> thorsten.kamann@(protected)
> http://www.thorsten-kamann.de/
> callto://thorque
>
> Fornax-Platform - Platform for developing MDSD-related Tools and
> components
> http://www.fornax-platform.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email