[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[4]: [equinox-dev] OSGI Bundles: alternate manifest.mf location
|
JM> .... The PDE need to have the manifest at
JM> a particular spot is driven by "self hosting" usecases. PDE
JM> developers do not have to "build" or "deploy" or take any other
JM> action between saving changes to a plugin and running it.
This is not really true. You map around the class path to get the bin folder
on the class path (the magic source.. and output.. properties), they are normally in the
root of the bundle. Why you could not have a magic meta.. property?
You do have a "deploy" phase before you launch, you just distributed most
of the work during editing. E.g. before you launch you must commit all
your files and I am pretty sure you internally do some more things
before you launch, however, as far as I know that point is not
available to run a script.
JM> This is a fundamental part of the Eclipse philosophy and workflow.
Unfortunately :-( As I have argued in vain too many times, it just does
not work very well for bundle development. It might work for big
Eclipse plugins development, for my kind of work where I have lots and
lots of small bundles and complex packaging requirements it just
does not work. I converted many bundles to use the Eclipse model
for a tutorial. Since then they all slipped back to btool because it
was just too painful.
The Eclipse model with 1 project = 1 bundle is too constrained.
It also forces you to put the same information in lots of places
because you can not define variables in a single point and use them
in many places, causing the root of most software evil: redundancy. A
build tool can easily generate the imports, now you must edit them by
hand.
I feel that the "no-build" mantra is blinding Eclipse folks for the many
disadvantages. It would be interesting to know how many people on this
list would like to be able to do something before launching/packaging
and get rid of the project==bundle constraint?
Don't get me wrong I love Eclipse and there are an enormous amount of
tremendous features in it. However, the PDE development model is too
constrained for me (and as it seems for many others).
Kind regards,
Peter Kriens
JM>
JM> It is clear that Maven is envisioned as a general build mechanism
JM> and PDE Build was designed as a *plugin* building mechanism. The
JM> things you outline that "maven does" are actually things that
JM> plugins (third party or otherwise) to maven do. This plugin
JM> capability is facilitated by Maven having a defined build
JM> lifecycle and allowing contributed bits to be run at various
JM> points in the lifecycle. PDE build has a similar though perhaps
JM> more rudimentary and certainly less exploited mechanism with it custom targets support.
JM>
JM> The other core aspect of Maven is its project structure. This is
JM> largely separate from the plugin/extensibility story and was put
JM> in place to, as I understand, bring some uniformity to a rather
JM> caotic project structuring world. While they do not mandate the
JM> various formats/layouts, it is clearly prescriptive in that there
JM> are easy paths and hard paths. Having multiple source folders for
JM> example is hard. Having one is easy. I won't argue with any of
JM> the Maven choices but rather not that they are simply different
JM> choices than those made in PDE.
JM>
JM> It would be good to reconcile these and make the path smooth for
JM> users of both build systems. The PDE need to have the manifest at
JM> a particular spot is driven by "self hosting" usecases. PDE
JM> developers do not have to "build" or "deploy" or take any other
JM> action between saving changes to a plugin and running it. This is
JM> a fundamental part of the Eclipse philosophy and workflow. If the
JM> manifest were somewhere else then the runtime would not be able to
JM> find it. Since it is the root of "bundleness" that would be bad.
JM> Yes there could be a PDE builder that copied it around but then
JM> there would be two copies causing confusion. Note that anyone is
JM> free to write such a builder and add it to a project.
JM>
JM> We are actively seeking ways of better integrating/enabling Maven
JM> usecases and workflows. In this case for example, it would be
JM> very interesting to understand how Maven could be enhanced to
JM> better allow for resources at the root of a project. Maven experts?
JM>
JM> Jeff
JM>
JM>
JM>
JM> "Alex Blewitt" <alex.blewitt@xxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 07/06/2006 03:43 AM
JM>
JM> Please respond to
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM>
JM>
JM> To
JM> "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
JM> cc
JM>
JM> Subject
JM> Re: RE: RE: [equinox-dev] OSGI Bundles: alternate manifest.mf location
JM>
JM>
JM>
JM>
JM> It's not about builds. Maven does a whole lot more than PDE does --
JM> run testing reports, upload builds to remote servers, send Jabber
JM> notifications, run code analysis reports, automatically perform builds
JM> of just a single plugin when that plugin has changed (unlike PDE's
JM> build everything approach) ... the list goes on and on. In fairness,
JM> PDE does well what it does best (just building) but Maven can do *so*
JM> much more.
JM>
JM> Maven has a well-defined project structure; files are split into
JM> resources, source folders and everything gets compiled to a target
JM> folder. Maven doesn't specifically require that the folder be called
JM> resources (it could be stuff/that/i/want/to/include) and you can have
JM> many of them. However, for exactly the same reasons why you've argued
JM> that source files (and compiled output) should be in different folders
JM> in the past -- it's one of organisation.
JM>
JM> Maven can be defined to put other resources in (I set this up for the
JM> automated builds tutorial @ EclipseCon) but it's a bit ugly to have a
JM> separate resources/ directory (Maven projects almost always call it
JM> resources; but Maven 2 has slightly different standards in project
JM> layout; instead of 'src' and 'test', they're usually called 'src/main'
JM> and 'src/test' so there may be a different standard for resources) --
JM> and then have to make a 'special case' for META-INF/MANIFEST.MF
JM> because your IDE doesn't like it being moved.
JM>
JM> Alex.
JM>
JM> 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
>>
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>
JM>
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
