[pde-build-dev] Re: [equinox-dev] OSGI Bundles: alternate manifest.mf lo

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

Hello, 

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, 

Regards, 

PaScaL

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

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

Niclas,

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:
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01168.html

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

/peter
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev