Yes, you're right. I guess I wasn't thinking of using the groovy-all jar
in OSGi, but there's no reason it couldn't be or shouldn't be. Would you
like me to change the patch to cover that?

Dave

> -----Original Message-----
> From: Paul King [mailto:paulk@(protected)]
> Sent: Tuesday, January 15, 2008 1:46 AM
> To: eclipse-plugin-dev@(protected)
> Subject: Re: [groovy-eclipse-plugin-dev] split org.codehaus.groovy
plugin
>
>
> Hi Dave, wouldn't those headers need to be different for the different
> jars?
> I.e. wouldn't asm and antlr be excluded from the groovy-all jars but
in
> the
> vanilla jar?
>
> Paul.
>
> Dave Dunkin wrote:
> > I have created issue 2502 for adding the OSGi headers to the groovy
jar.
> > http://jira.codehaus.org/browse/GROOVY-2502
> >
> > Dave Dunkin
> > Technologist
> > DIS Corporation
> > 800.426.8870
> >
> >
> >> -----Original Message-----
> >> From: Dave Dunkin [mailto:DaveD@(protected)]
> >> Sent: Monday, January 14, 2008 3:39 PM
> >> To: eclipse-plugin-dev@(protected)
> >> Subject: RE: [groovy-eclipse-plugin-dev] split org.codehaus.groovy
> > plugin
> >>> -----Original Message-----
> >>> From: Thorsten Kamann [mailto:thorsten.kamann@(protected)]
> >>> Sent: Monday, January 14, 2008 2:05 PM
> >>> To: eclipse-plugin-dev@(protected)
> >>> Subject: Re: [groovy-eclipse-plugin-dev] split org.codehaus.groovy
> >> plugin
> >>> Michael Fraenkel schrieb:
> >>>> Let me throw in my $0.02.
> >>>>
> >>>> It makes sense to have 2 plugins, one for what is needed for the
> >>>> groovy plugins and what is needed for the groovy runtime that is
> >>>> attached to a Groovy Project. Its not clear if we need a
separate
> >>>> plugin for the JARs that make up the groovy plugins. We can
> >> leverage
> >>>> what Orbit already provides which would give us a few of the
JARs.
> >>> Yep, this I wrote in my last answer to dave. If all needed deps
> >>> available as plugins we don't need an additinally plugin. This
shoul
> >> be
> >>> the goal.
> >> commons-cli is, but asm and antlr are not. From the Orbit website:
> > "The
> >> Orbit mandate does not allow the project to be used for building or
> >> maintaining third-party libraries that are not approved by the
Eclipse
> >> foundation for us in Eclipse projects." So groovy-eclipse would
have
> > to
> >> provide the asm and antlr plugins.
> >>
> >>>> The discussion of how many JARs are packaged and the number of
> >> plugins
> >>>> seems to be a reoccurring issue since we discussed this 6 months
> > ago
> >>>> or so. What is obvious is that there should be the minimum set
as
> >> the
> >>>> default. I think we can imagine some other pre-packaged
> >> combinations,
> >>>> e.g., Grails, etc.. Are these in 1 plugin or many? Having many
> >> makes
> >>>> sense if there are other users. I haven't seen many well-known
> >>>> packagings.
> >>> We talk about 2 different approaches. One for plugin development
> > with
> >>> groovy support and one for the runtime. I think the current
solution
> >>> with the groovy-all-xxx.jar is good enough. There aren't a need
for
> >>> changes. Only the first approcah for the plugin development with
> >> groovy
> >>> can be better, so not all libs must be loaded.
> >>>
> >>> Thorsten
> >>>
> >>>
> >>> --
> >>> 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
> >
> >
> >
---------------------------------------------------------------------
> > 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


---------------------------------------------------------------------
To unsubscribe from this list please visit:

  http://xircles.codehaus.org/manage_email