[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pde-build-dev] building Eclipse with Maven


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