[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: RE: RE: [equinox-dev] OSGI Bundles: alternate manifest.mf location



>Easy solution: add a (maven) plugin to the generate-resources phase that copies META-INF/Manifest.MF to target/classes.
>(although I don't know how Eclipse or  OSGi will react to the fact that there are now two manifests in the plugin classpath)


>Intermediate solution: use the assembly plugin to assemble the plugin jar, adding the right files and folders

>Hard solution: create your own packaging plugin that uses build.properties to assemble the jar.

        These solution would only satisfiy the runtime aspect of things since the bundle will be in a "executable" format, however PDE would not recognize the project as a bundle and therefore this project would not get its classpath managed by PDE, nor will other bundles be able to reference it (require bundle or import packages).


PaScaL




"Tom Huybrechts" <tom.huybrechts@xxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

07/06/2006 10:31 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: RE: RE: [equinox-dev] OSGI Bundles: alternate manifest.mf location








Easy solution: add a (maven) plugin to the generate-resources phase that copies META-INF/Manifest.MF to target/classes.
(although I don't know how Eclipse or  OSGi will react to the fact that there are now two manifests in the plugin classpath)

Intermediate solution: use the assembly plugin to assemble the plugin jar, adding the right files and folders

Hard solution: create your own packaging plugin that uses build.properties to assemble the jar.

Tom



Jeff


"Alex Blewitt" <alex.blewitt@xxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

07/06/2006 03:43 AM

Please respond to
Equinox development mailing list <
equinox-dev@xxxxxxxxxxx>


To
"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: RE: RE: [equinox-dev] OSGI Bundles: alternate manifest.mf location







It's not about builds. Maven does a whole lot more than PDE does --
run testing reports, upload builds to remote servers, send Jabber
notifications, run code analysis reports, automatically perform builds
of just a single plugin when that plugin has changed (unlike PDE's
build everything approach) ... the list goes on and on. In fairness,
PDE does well what it does best (just building) but Maven can do *so*
much more.

Maven has a well-defined project structure; files are split into
resources, source folders and everything gets compiled to a target
folder. Maven doesn't specifically require that the folder be called
resources (it could be stuff/that/i/want/to/include) and you can have
many of them. However, for exactly the same reasons why you've argued
that source files (and compiled output) should be in different folders
in the past -- it's one of organisation.

Maven can be defined to put other resources in (I set this up for the
automated builds tutorial @ EclipseCon) but it's a bit ugly to have a
separate resources/ directory (Maven projects almost always call it
resources; but Maven 2 has slightly different standards in project
layout; instead of 'src' and 'test', they're usually called 'src/main'
and 'src/test' so there may be a different standard for resources) --
and then have to make a 'special case' for META-INF/MANIFEST.MF
because your IDE doesn't like it being moved.

Alex.

On 06/07/06, Philippe Ombredanne <
pombredanne@xxxxxxxxx> wrote:
> Ravi:
> Just curious, I am all for flexibility, but your argument seems to be
> that Eclipse is not flexible when it comes to PDE and PDE build looking
> for potential alternate locations for the manfest. And you are asking
> for a way to add that flexibility in Eclipse.
> The argument could be turned around:
> Why would Maven be so inflexible as to mandate the manifest to be in a
> resource directory?
> And force a certain project layout based on its build system?
> Cordially
>
> --
> Cheers
> Philippe
>
> philippe ombredanne | 1 650 799 0949 | pombredanne at
nexb.com
> nexB - Open by Design (tm) -
http://www.nexb.com
>
http://EasyEclipse.org  -  irc://irc.freenode.net/easyeclipse
>
>
>
> > -----Original Message-----
> > From:
equinox-dev-bounces@xxxxxxxxxxx
> > [mailto:
equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Ravindar Reddy
> > Sent: Wednesday, July 05, 2006 10:46 PM
> > To: Equinox development mailing list
> > Subject: Re: RE: [equinox-dev] OSGI Bundles: alternate
> > manifest.mf location
> >
> >
> > Just to add to what Alex said below - I understand that the
> > OSGI package needs the META-INF in the jar at top level. All
> > I am asking is that the source location in OSGI plugin
> > project could be anywhere (like
> > resources/META-INF/MANIFEST.MF) that gets relocated to
> > META-INF/MANIFEST.MF for final bundle package.
> >
> > The reason I am doing this is to use "Apache Maven" for
> > headless builds and use Eclipse as IDE for OSGI bundles.
> > Currently I am using normal java project for OSGI bundles as
> > I can not relocate the META-INF and let build.properties know
> > about it. Seems like all you need is to introduce an extra
> > property to inform the PDE as to where META-INF is located.
> > Just with this functionality I would be able to build OSGI
> > bundles in both (Maven abd Eclipse) with the same source layout
> >
> > - Ravi R
> >
>
> _______________________________________________
> equinox-dev mailing list
>
equinox-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
_______________________________________________
equinox-dev mailing list

equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list

equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev