[
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
|
As Pascal points out in a later post,
there is a chicken and egg problem with discovering the mappings. That
is, where would you put the manifest location information such that the
runtime can pick it up and do the mapping?
Note also that there are some more subtle
problems in that the manifest itself contains paths (classpath, native
code, translations, ...) Currently these are all considered to be
relative to the "root" of the bundle. The original problem
that started this thread was that Maven wants "resources" to
be somewhere in particular. Are these files considered to be resources?
As such, shouldn't these be somehow mapped too? For example,
where should the translations (typically in Eclipse the plugin.properties
file) go in a Maven layout?
We need to work through all these problems
and usecases to better understand if and how they can be addressed.
Jeff
"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
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
