It is clear that Maven is envisioned
as a general build mechanism and PDE Build was designed as a *plugin* building
mechanism. The things you outline that "maven does" are
actually things that plugins (third party or otherwise) to maven do. This
plugin capability is facilitated by Maven having a defined build lifecycle
and allowing contributed bits to be run at various points in the lifecycle.
PDE build has a similar though perhaps more rudimentary and certainly
less exploited mechanism with it custom targets support.
The other core aspect of Maven is its
project structure. This is largely separate from the plugin/extensibility
story and was put in place to, as I understand, bring some uniformity to
a rather caotic project structuring world. While they do not mandate
the various formats/layouts, it is clearly prescriptive in that there are
easy paths and hard paths. Having multiple source folders for example
is hard. Having one is easy. I won't argue with any of the
Maven choices but rather not that they are simply different choices than
those made in PDE.
It would be good to reconcile these
and make the path smooth for users of both build systems. The PDE
need to have the manifest at a particular spot is driven by "self
hosting" usecases. PDE developers do not have to "build"
or "deploy" or take any other action between saving changes to
a plugin and running it. This is a fundamental part of the Eclipse
philosophy and workflow. If the manifest were somewhere else then
the runtime would not be able to find it. Since it is the root of
"bundleness" that would be bad. Yes there could be a PDE
builder that copied it around but then there would be two copies causing
confusion. Note that anyone is free to write such a builder and add
it to a project.
We are actively seeking ways of better
integrating/enabling Maven usecases and workflows. In this case for
example, it would be very interesting to understand how Maven could be
enhanced to better allow for resources at the root of a project. Maven
<alex.blewitt@xxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx
07/06/2006 03:43 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
"Equinox development mailing list"
It's not about builds. Maven does a whole lot more
than PDE does --
run testing reports, upload builds to remote servers, send Jabber
notifications, run code analysis reports, automatically perform builds
of just a single plugin when that plugin has changed (unlike PDE's
build everything approach) ... the list goes on and on. In fairness,
PDE does well what it does best (just building) but Maven can do *so*
Maven has a well-defined project structure; files are split into
resources, source folders and everything gets compiled to a target
folder. Maven doesn't specifically require that the folder be called
resources (it could be stuff/that/i/want/to/include) and you can have
many of them. However, for exactly the same reasons why you've argued
that source files (and compiled output) should be in different folders
in the past -- it's one of organisation.
Maven can be defined to put other resources in (I set this up for the
automated builds tutorial @ EclipseCon) but it's a bit ugly to have a
separate resources/ directory (Maven projects almost always call it
resources; but Maven 2 has slightly different standards in project
layout; instead of 'src' and 'test', they're usually called 'src/main'
and 'src/test' so there may be a different standard for resources) --
and then have to make a 'special case' for META-INF/MANIFEST.MF
because your IDE doesn't like it being moved.
On 06/07/06, Philippe Ombredanne <pombredanne@xxxxxxxxx> wrote:
> Just curious, I am all for flexibility, but your argument seems to
> 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
> resource directory?
> And force a certain project layout based on its build system?
> 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
> > 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"
> > 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 mailing list