[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


Yes PDE performs some magic on the bundle classpath when selfhosting. It gives to OSGi a map of bundleId to paths to add to the bundle-classpath (the manifest is not modified on disk).
However modifying the location of the manifest represents a chicken & egg problem, since in order to provide the aforementionned map PDE needs to read the id of the bundle which it gets from the manifest file. Therefore the first level of support required to do this would be to let PDE knows on a project basis where each manifest file is.
Once PDE has this information, he could then feed a modified version of osgi with the appropriate manifest location.

That said, this will not solve all the cases that you are worried about were a resource is in a certain spot of the resource tree and ends up in another one at runtime (once exported) and will cause  problem in selfhosting.

It seems to me that the easiest path to integration between maven and PDE selfhosting is for PDE to add flexibility to the manifest and for the code managed by maven to be structured in a limited set of ways where resources are not moved around too much.

PaScaL




"Neil Bartlett" <neil@xxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

07/06/2006 10:18 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





Jeff,
 
Isn't there still an inconsistency here, as Alex pointed out, between how the manifest is handled and the compiled classes are handled?
 
That is, if "self-hosting" requires that the meta-inf/manifest.mf be at the root of the project, why does it allow the classes to be under bin/? The runtime classpath of the bundle is defined by the manifest and the manifest (in many cases) will say "Bundle-Classpath: .". Does Equinox dynamically change that to "Bundle-Classpath: bin/" when launching from PDE? If so, couldn't there be support in Equinox for manifest.mf to be located somewhere other than the OSGi-mandated location when "self-hosting"?
 
Regards,
Neil


On 7/6/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:

It is clear that Maven is envisioned as a general build mechanism and PDE Build was designed as a *plugin* building mechanism.  The things you outline that "maven does" are actually things that plugins (third party or otherwise) to maven do.  This plugin capability is facilitated by Maven having a defined build lifecycle and allowing contributed bits to be run at various points in the lifecycle.  PDE build has a similar though perhaps more rudimentary and certainly less exploited mechanism with it custom targets support.  


The other core aspect of Maven is its project structure.  This is largely separate from the plugin/extensibility story and was put in place to, as I understand, bring some uniformity to a rather caotic project structuring world.  While they do not mandate the various formats/layouts, it is clearly prescriptive in that there are easy paths and hard paths.  Having multiple source folders for example is hard.  Having one is easy.  I won't argue with any of the Maven choices but rather not that they are simply different choices than those made in PDE.  


It would be good to reconcile these and make the path smooth for users of both build systems.  The PDE need to have the manifest at a particular spot is driven by "self hosting" usecases.  PDE developers do not have to "build" or "deploy" or take any other action between saving changes to a plugin and running it.  This is a fundamental part of the Eclipse philosophy and workflow.  If the manifest were somewhere else then the runtime would not be able to find it.  Since it is the root of "bundleness" that would be bad.  Yes there could be a PDE builder that copied it around but then there would be two copies causing confusion.  Note that anyone is free to write such a builder and add it to a project.


We are actively seeking ways of better integrating/enabling Maven usecases and workflows.  In this case for example, it would be very interesting to understand how Maven could be enhanced to better allow for resources at the root of a project.  Maven experts?


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





--
Neil Bartlett
Senior Technical Consultant, Integility Ltd
Tel: +44 (0) 20 7043 8328
Fax: +44 (0) 20 7043 8329

LinkedIn Profile:
https://www.linkedin.com/in/neilbartlett _______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev