Re: [pde-build-dev] Eclipse Builds and Maven 2.x

[Andrew Niefer <aniefer@xxxxxxxxxx>]

I think that the biggest gains here
are in augmenting small parts of maven/PDE build to take advantage of what
the other does well.    It seems to me that the best of maven
is the idea of convention instead of configuration which makes for a simplified
starting point.  The advantage to PDE build is the flexibility and
power it provides.  The two are coming from opposite sides of a spectrum.
  There are things we can do to move each closer to the middle but
actually merging the two is a different question.

Some things that would be interesting
to add to maven are the dependency resolution based on a manifest, and
perhaps the compilation using access rules.
Things that would be interesting to
add to PDE build are fetching dependencies automatically from some repository
as well as posting the results back into the repo.  Also perhaps the
notion of the implicit pom with default settings that simplifies the initial
setup.

It could be that the two are not as
far appart as it seems, this is where it would help to know more about
maven.  A couple of the general areas that look like they might be
problems are controlling the input (fetching source, plugin versions, bundles
with multiple source folders or nested jars), building multiple platforms
at once (can maven profiles be used for this?), and controlling the output
packaging.

-Andrew

"Wendell Beckwith" <wbeckwith@xxxxxxxxx>
Sent by: pde-build-dev-bounces@xxxxxxxxxxx

06/06/2006 07:41 PM

Please respond to
"Eclipse PDE Build developers list." <pde-build-dev@xxxxxxxxxxx>

To	pde-build-dev@xxxxxxxxxxx
cc
Subject	[pde-build-dev] Eclipse Builds and Maven 2.x

This came up previously in this thread, http://dev.eclipse.org/mhonarc/lists/pde-build-dev/msg00076.html,
but it seems to have fallen on the floor and rolled under the couch.  Nonetheless,
my company had migrated out builds to maven and we were reaping the rewards
of mavenized nirvana when we started developing RCP apps and needing to
build the plugins in our automated build system, Anthhill Pro. 

I've checked out the org.eclipse.pde.build plugin and from what I can tell
the current build system is too tightly coupled to ant.  Recently
in the 3.2 timeframe the IFetchFactory was introduced to deal with getting
source from cm systems other than cvs ( i.e. subversion, perforce, etc).
 This was a welcome change but even then the result was forced to
generate ant.  I have not done a complete review of all 66 source
files in the build plugin, but from a quick review it seems like the eclipse
build mechanism could be refactored to support other build mechanisms without
breaking the current predisposition towards ant. 

>From a high level eclipse wants to do pre and post actions for build setup,
retrieving the source, building the feature/plugin, testing the plugin,
assembling the feature/plugin, packaging and publishing the feature/plugin.
 These actions map extremely well to maven 2's notion of a lifecycle.
 Either the current default maven 2 lifecycle could be used or a custom
plugin can be defined that uses an eclipse specific lifecycle similar to
how the clover plugin has its own lifecycle.  To make this happen
I think that there should be a org.eclipse.pde.build.IBuildScript interface
that is used.  The current IAntScript interface could extend the IBuildScript
interface to maintain backwards compatibility.  Nonetheless, if the
lifecycle phase methods were placed in the IBuildScript interface then
other methods builds systems (IMavenScript, IIvyScript, IJamScript, etc)
could be plugged in at ease without being tied to a specific one. 

There may be glaring holes and over simplifications I have made but getting
our builds working again in a smooth fashion is a priority goal I have
and currently I have 1.5 engineers I can throw at the problem.  Thoughts??

Wb_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev