Re: [equinox-dev] OSGI Bundles: alternate manifest.mf location

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

"Jeremy Volkman" <jvolkman@xxxxxxxxx>
wrote on 07/09/2006 12:30:26 PM:

> On 7/9/06, Peter Neubauer <peter@xxxxxxxxxxx> wrote:
> >
> > So, if we could get a project financing for it, probably one
could
> > start playing with putting in Hansa as the resolver etc. Btw
there

Dunno what Hansa is but you ought to be quite careful
about using different resolvers.  The one we use is the actual code
used at runtime so there are no issues with inconsistencies etc.  As
has been mentioned several times here (see below) and on the PDE list,
that resolver is quite independent of the Equinox framework and can be
used separately (we currently have not cleaned up the packaging separation
but the code can be run independent of any framework instance).

> > seems to be a common issue with Eclipse
not treating everything as
> > URLs, and especially not being able to handle nested Jar URLs,
giving
> > problems in e.g. mounting custom URL formats as source jars,
javadoc,
> > and resolve nested jars from library bundles that are not expanded
on
> > disk.

This has been mentioned before. While I do understand
what you are talking about, I am not sure of which systems actually do
allow you to supply your own custom URLs and URL handlers at compile time.
 Keep in mind I am not a Java compiler guy so perhaps I'm just missing
the boat...

> At my company we're currently working on a new
system built on OSGi
> using Eclipse's PDE.  This being the case, I've recently developed
a
> continuous integration system around the PDE's building/exporting
code
> (it can be done!)  While this currently satisfies most of our
needs,
> it would be nice to have a system based on Maven or some other
> standard build framework to get all of the extras that come with.
> 
> That being said, I've learned a few things about working with the
> internals of the PDE -- mostly that it's not pleasant in there, being
> massive, undocumented and seemingly laced with legacy work-arounds
> from the pre- to post-OSGi switch.    

Yes.  PDE Build has never been very elegant or
graceful and we would love to rewrite it.  Time is the killer.  Build
systems are notoriously hard to get right as every little detail counts.
 Even if we could get Maven to do what we want for 80% of what we
need, the last 20% of permission setting, packaging for different platforms,
whacky things one must do for a Mac, ... would take the proverbial 80%
of the time.  This does not excuse the current state or the Ant induced
mind bends that one must endure to dive into PDE but does set the scene
for why we have not redone it.  Thankfully most people simply *use*
the build system rather than trying to dive into the code.

> However, the PDE appears to use
> Equinox's State/Resolver API for the OSGi dirty work, which as stated
> before can be used by anyone fairly easily (and it's documented).

"Niclas Hedhman" <niclas@xxxxxxxxxxx>
 wrote on 07/08/2006 11:08:06 PM:
> Btw, is the PDE part of the Equinox team's responsibility, or is 
> that handled by other folks??

Not sure where you are going with this but...

Technically they are separate projects but in effect
we are one team.  In the interest of full disclosure I have PMC responsibility
for both Equinox and PDE.  PDE is made up of PDE UI (all the UI, workspace
models and classpath containers, editors, User assistance and Update tooling,
...) and PDE Build (command line builds, plugin/feature export, ...).  So,
the reality is that Wassim Melhem leads PDE UI and Pascal Rapicault leads
PDE Build.  Pascal is also a key member of the Equinox team.  The
Equinox team works closely with Wassim and the merry band of PDE UI guys.
 

Jeff