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


I think the discussion digressed. We started from PDE UI is not flexible and we ends up on PDE build sucks and there is no good way to build OSGi things :-).
Whatever PDE Build value is in term of code, it turns out that for the last 3 years it has been (and I think it still is) the only system that allowed with minimal configuration, to build OSGi bundles respecting classpaths, various shapes of bundles and fine grained dependencies.
Now, yes PDE Build does not play well with others, but hey! there were no others when it first got written many years ago :) In fact it was the same things for the runtime when we started. Where am I going with this last point? Well at one point we looked at what we had (static runtime) and the challenges we were facing (RCP and dynamic loading) and we decided to investigate what was out there and found OSGi. We embraced it and migrated to it. Today we are at the same point with PDE Buid where we would like among other motivations play better with others and provide incremental builds. However the subtle difference is that the driver for replacing / complementing PDE Build with another technology is not as strong as it was for the runtime, since PDE build is not seen to be "as much" on the critical paths and still the majority of people are only building plug-ins simply written in java.

So where does the PDE Build team stands? Currently we are exploring Maven to see if it can just build bundles and since we are not Maven experts we have been providing code and help to Wendell Beckwith (and previously to some Maven committers) to see how far this can go. Once / if Maven can build bundles (osgi r4), we will still have to figure the parameters of the risk / reward equation but more importabtly ensure that all the functions provided by PDE build can be ported or replaced with a better story. For example, support flexible layouts, support various output shapes (jars in jars, regular jars, ...), generation of version numbers, creation of archive containing groups of bundles (in zip, tar, ), building RCP applications, building our doc,...

So in short, we are definitly interested and we are supporting / helping / investigation around Maven, but this move won't happen overnight and in the meantime we will still have to fulfill some of the requests we have.

In order to keep things separated and allow everybody playing with PDE build, bundles and Maven to talk together, I'm moving the part of the discussion to the PDE build list: https://dev.eclipse.org/mailman/listinfo/pde-build-dev (this is where Wendell has been working: http://dev.eclipse.org/mhonarc/lists/pde-build-dev/maillist.html).

Thank you for your interest,



"Peter Neubauer" <peter@xxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

07/09/2006 02:38 AM

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

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


On 7/9/06, Niclas Hedhman <niclas@xxxxxxxxxxx> wrote:
> I think that the best way forward is a command-line driven tool that
> understands OSGi, yet have the power of standardization that Maven offers. I
> know Peter Kriens has advocated this previously, but not keen to push real
> hard.
Yes, we are always getting to this point again. I fully agree.
Question is if there is more help to get from the PDE team? I
previously asked a bit and it seems the Eclipse team thinks the
current ant system and export features are sufficient at least for the
Eclipse development horizon, but there sems to be some degree of power
inside Equinox and Adapter and Resolver parts to hook into:

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

equinox-dev mailing list