Re: [pde-build-dev] Eclipse bundles on the Maven repository

["Wendell Beckwith" <wbeckwith@xxxxxxxxx>]

I didn't think of adding an explicit header to the manifest but that would be a good addition IMO.  I think the default should be to always use the bundle's symbolic name as the artifactId and the groupId can be the symbolic name too unless there is a header stating what the groupId should be.  I have spent too much of this weekend looking into this problem, but
I'm finding it hard to let it go because I believe it is doable.  Over
the weekend I started work on skeleton java and ant-based maven mojos because I foresee that we will need several pde mojos to pull this
off.  The osgi-bundle pugin that is
available from the Apache Felix project can serve as a blueprint for
creating m2 plugins defining lifecycles and artifact handlers. 
However, eclipse already has all the code needed for compilation.  What
we need to talk about is the higher level phases and repository mapping.  The following are major issues I think need to be dealt with.

Compilation:

For compilation I see configuration flowing along lines like the following plugin declaration

<plugin>
    <groupId>org.eclipse.pde.maven.plugins</groupId>
    <artifactId>maven-eclipsecompiler-plugin</artifactId>
    <configuration>
        <source>1.5
</source>
        <target>1.5</target>
        <!-- ... other config parameters here ... -->

        <!-- The manifest to use for this bundle. -->
        <manifest>${basedir}/src/main/resources/META-INF/Manifest.mf</manifest>
        <!-- The base to compile against.  ${eclipseTarget} = c:/eclipse-3.2 -->
        <eclipseTarget>${eclipseTarget}</eclipseTarget>
    </configuration>
</plugin>

Basically the eclipsecompiler plugin will take the manifest and the target eclipse into consideration the same as it does today and then dynamically add the bundle's dependencies to the project's classpath.  IIRC, this is kinda reversed of what the osgi-bundle plugin from the Apache Felix project does.  Nonetheless, coming from the standpoint of using eclipse and the pde tools to manipulate the manifests and then letting the headless build simply read and massage over the data to dependencies that are added to maven seems more natural.  

Now the <eclipseTarget> configuration parameter can be resolved 1 or 2 ways, however the end result would be the same.   In the simple case, case 1, we simply point to an eclipse install on the filesystem and the compiler can resolve dependencies against that.  In the more complicated case, case 2, the target will refer to a path in the maven repo.  Case 2 has a few wrinkle which I will talk about below under Repository Mapping.  Even with the wrinkles case 2 is where we should shoot for in the long run, but we can use case 1 to test out everything else while case 2 is being worked on.

Repository Mapping

Mapping in the repo happens both when getting artifacts out of it as well as when installing/deploying artifacts to it.  In theory if we solve one then the other is also solved.  Now from the above we have kinda described how to put a single jar (plugin/feature/fragment) into the maven repo.  What I feel is missing is some way of aggregating the various elements into groups.  If I have 3 plugins p1, p2, p3 and 2 features f1, and f2, then feature f1 might be composed of plugins p1, p2, p3 while feature f2 only has plugins p1 and p3.  How do we specify this?  If I just list them all in the pom, which would work, then I perform double duty against the pde work to specify stuff in the manifest.  If maven doesn't currently handle it, then I think it needs to be configured with some type of aliasing/symlinking mechanism for forming repo groups.  If maven had this capability then we could set the <eclipseTarget> config element to this mythical RepoGroup "
org.eclipse.platform-3.2".  The org.eclipse.platform-3.2 group would be composed of 7 features an 3 plugins and 2 fragments.  The features would be recursively resolved down to their transitive dependencies and the whole thing would ultimately resolve out the same way as if we specified an eclipse target directory on the filesystem.

When installing/deploying features and higher level groups the plugins would also add the group info to where their component plugins live.  

This feature could definitely be pushed back to maven as it would allow people to configure their own stacks in their local repos which are then pulled from the maven repo, sort of like a "web-config" repo group, which auto-magically adds 
commons-logging-1.1, log4j-1.2.13, spring-2.0, hibernate-3.1.3 to the pom's classpath.  How nutty does this sound?

Wb

On 6/12/06, Andrew Niefer <aniefer@xxxxxxxxxx> wrote:

I agree with Wendell on the mapping of names.

If we are using the equinox resolver to computer dependencies, it ultimately resolves down to a Bundle-SymbolicName.  To play well with maven and be able to fetch the required bundles from a maven repo, we need a 1-to-1 mapping between the symbolic name and maven's groupId, artifactId, version.  The simplest way I see to do this is using groupId == artifactId == symbolic Name.

If we wanted to use something else for the groupId, then the best way I see is to introduce some new header (Bundle-MavenGroupId ?) into the manifest.

-Andrew