Re: [pde-build-dev] building Eclipse with Maven

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

pde-build-dev-bounces@xxxxxxxxxxx wrote on 08/27/2005
11:55:18 PM:

> Just to introduce myself - I'm one of the Maven developers that has
been
> discussing this recently with Jeff in relation to OSGi. I'm new to
OSGi
> and Eclipse plugin development but am quite familiar with working
in a
> component-oriented environment. Please forgive any obvious questions
I
> might ask as I get up to speed.

Well, we are Maven newbies so now we're equal :-)

> One option mentioned briefly was that pde-build
could generate a Maven
> POM as an alternative to the Ant build script, and let Maven provide
a
> lot of the services that are being generated. These are provided by

Right, this seems like a good direction to start.
 Take our current build inputs (manifest.mf and build.properties)
and generate a POM.  The POM would include declarations of all the
dependencies etc.  So in effect this is a manifest => POM converter.
 Can the POMs have what amounts to prebindings?  To do the generation
we likely already have to do the resolution (in OSGi-land) until there
is a resolvers plugin for Maven.  So perhaps we just do our resolution,
generate highly detailed bindings in terms that Maven understands and then
run.

Is it ok to regenerate the POMs every time? 

When we run the build, would Maven then want to regenerate
the manifests?

A key point here is that developers only express their
dependencies etc info in one place and that it be the place that is natural
to them.  To my mind, since we are developing OSGi bundles, that place
should be the manifest.mf.  We have considerable tooling built around
that file and various containers (e.g. Eclipse or Felix or Knopflerfish)
will have extensions etc that need to be interpreted.  I would say
the same thing if I were writing EARs or ...

> Maven plugins - which could easily be OSGi bundles
in the future since
> Maven is built around a component architecture.

Are you suggesting that Maven may some day be based
on OSGi?

> As far as it "wanting to be on top":
this is really a matter for those
> using Maven to build as you need to add additional information such
as
> that provided in build.properties of pde-build. For dependencies in
the
> repository using the information OSGi provides is most likely sufficient.

What I was meaning was that there are many things
about OSGi/Eclipse that are not likely covered in Maven.  The dependency
stuff I mentioned is likely one.  There are also issues around packaging
that may need to be worked through.  The fact that the resolver is
pluggable is promising.  It will be great to see how this works out.

> It seems the dependency model is to some extents
similar, though Maven
> doesn't have any notion of package importing. Fragments were also
> mentioned - I'm not sure if they are similar to Maven profiles or
not,
> but regardless are not going to be as similar as the bundle requirements
> which seem to map straight on to Maven dependencies. It is possible
that
> Maven could use an alternative resolver for its dependencies if
> necessary (which is what Jeff mentioned you are doing with pde-build).

Just a bit of background on fragments.  
- Fragments are essentially bundles that capture parts
of other bundles.  Effectively they allow one bundle to be broken
into several pieces.
- Typiclaly this is for NLS or to capture platform
specific code.  
- Fragments only ever add things to their "host"
bundle.  
- There can be many fragments on one host.  
- Fragments can add API and other classes to their
host.  
- A bundle that depends on a host implicitly depends
on all its resolved fragments.  
- A given system of bundles may include many fragments
that are not applicable in the current configuation (e.g., OS, Window system,
...), 
- Fragments are packaged separately from their hosts.

> > So, if there is anyone out there who knows
about Maven (actually Maven
> > 2 seems a better choice) and wants to take a stab at setting
up a M2
> > based build for Eclipse, lets hear from you.  It should
be quite
> > instructive to take a small set of existing bundles (say the
11 RCP
> > bundles) and see if we can build those for a couple different
> > platforms (e.g., Windows and Linux GTK).
> 
> I have a busy month ahead but I plan to take a look at this in some
down
> time. Can you point me in the right direction with this? I'm not an
> Eclipse user (at least not recently) so I'm really starting from scratch
> here.
>
> I've taken a look at the pde-build page and looked
through some of the
> build files. I have some of this checked out from CVS.
> What I'd like to know is how to get started using pde-build to build
a
> sample bundle. I haven't had much luck there so far. Any other resources
> that are relevant would be most helpful.
> 
Probably the easiest way to get a feel is to start
Eclipse 3.1, create a new plugin project and choose one of the templates
that looks complicated (just to get alot of prereqs).  Then right
click on the created manifest.mf and select PDE Tools > Create Ant Build
File.  This generates a build.xml and that file should give you a
feel for the sort of classpath/dependency issues involved.  

To run it just right click on the build.xml and say
Run As... > Ant Build.  Note that if you just want the final output
you could also click on the plugin project and use Export As > Deployable
Plugin and go through the wizard.  Under the covers this generates
a build.xml and runs it.

> >From there I would look at setting up a Maven
build that could produce
> similar results to the generated ant build. Which are the 11 RCP bundles
> you are referring to?

Check out the list in eclipse/features/org.eclipse.rcp_3.1.0/feature.xml.
 There are more than 11 there but you can ignore the source ones and
treat the 10 or so SWT fragments as part of SWT.

Actually, that brings up another point, PDE build
actually is written in terms of building features (collections of plugins).
The plugins are still built individually but the typical usecase is to
ask the build mechanism to build a feature.  (the feature may contain
just one plugin but it is still a feature).  In many cases we actually
do still need the feature to be output.

Hope that created more questions than it answered
:-)

Jeff