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

"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.