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

["Wendell Beckwith" <wbeckwith@xxxxxxxxx>]

OSGi requires its metadata in the Manifest.mf so the tooling that PDE provides should stay focused on that.  I understand the whole "keeping the files in sync" thing since PDE and WTP both update the .classpath file as you add/remove bundle dependencies/JEE modules.  I suppose we are looking at several strategies like quickest, simplest and best and some of them are mutually exclusive and require more time and investment than others.

Deling with the Requires-Bundle and Import Packages will require the most work I beleive.  As for the plugin name in the repo, I would suggest the following mapping:

For a plugin/bundle with the name "
org.eclipse.core.runtime_3.2.0.v20060601b.jar", the groupId and artifactId would be "org.eclipse.core.runtime" and the version is "3.2.0.v20060601b" with a type of "jar".

So in general bundles with names like <name>_<version>.jar are mapped into the repo as 

<plugin>
   <groupId>name</groupId>
   <artifactId>name</artifactId>
   <version>version</version>
   <type>jar</type>
</plugin>

Either the above or we look at making the groupId correspond to the plugins top level eclipse project and let the artifactId be the name before the '_' and the version be the same as above.

Do we need the resources to be available in the repo?  I would answer that ultimately we would want them to but in reality we don't.  The maven-pde-plugin, since we need to call it something, could be configure with a path to the eclipse target to compile against similar to how you need to specify a target for the ant-based headless build.  Now without the use of the repo you losing a lot of the mavenness of it all but again it isn't required.

On 6/9/06, Tom Huybrechts <tom.huybrechts@xxxxxxxxx> wrote:

Hi Wendell,

I read your post on maven-dev. But it seems to me that if you don't
mind having duplicated information in manifest and pom, you can get by
without modifying Maven. Maybe some tooling support could take care of
bidirectional synchronization between both.

In any case, you would still need your dependencies to be available in
the repository, right ?

Tom

I read on your past on maven

On 6/9/06, Wendell Beckwith < wbeckwith@xxxxxxxxx> wrote:
> Hi Tom,
>
> Recently on the maven dev list I asked about how to deal with the whole
> dependency resolving that maven does.  I was told that we may need a custom
> maven install, but that the changes could be pushed back into maven core if
> done right.  I was also told to check out the Eclipse Buckminster project as
> their goal seems to be geared towards dealing with this problem for maven
> and others.  So far all I've had time to do is install their plugins.  I'll
> get to reading their mailing and newsgroups soon enough.
>
> BTW, I think we would want an eclipse plugin with its own lifecycle and that
> for the compile dependency resolution stage we would take the code that is
> already in/being used by PDE and put that into a maven plugin.  I do believe
> you would need a pom, but the pom wiould have a type of "eclipse-plugin" or
> "osgi-bundle" and where we normally include the maven-java-plugin in the pom
> we would instead include the maven-eclipse-java-plugin which would read the
> manifest.mf and dynamically add the appropriate entries to the classpath for
> compilation.
>
> Wb
>
>
>
> On 6/9/06, Tom Huybrechts < tom.huybrechts@xxxxxxxxx> wrote:
> >
> Hi all,
>
> I've been using Maven to build Eclipse plugins for some time now. This
> is currently a bit of a pain, since I synchronize between the pom.xml
> and manifest.mf manually. Other than that, it isn't that hard. Some of
> the things I did are:
> - deploy required Eclipse bundles to our corporate Maven repository,
> including simple POMs that define their internal dependencies.
> - translate the manifest dependencies to pom dependencies for my own
> projects. I used a small script to create the initial set of poms for
> my projects, but updated them manually afterward.
> - create a packaging mojo (a Maven plugin) that uses the
> build.properties to assemble the artifact.
>
> This works well, with some limitations. If a plugin you're using has
> jars included, you can't let Maven put it on the classpath. I got
> around this by creating my own compiler plugin, that wraps the normal
> compiler but first unzip the jars and then creates a custom classpath.
>
> Also,since I'm using the normal Java compiler, Import-Package headers
> are not verified.
>
> Anyway, to get to the topic of this post: it would make it easier to
> allow people to build their own plugins using Maven, if the eclipse
> bundles were available on the Maven repository
>  (www.ibiblio.org/maven2). There already are some plugins available
> there, but not enough.
>
> The hard part would be to create correct POMs for each of the bundles:
> - translate Require-Bundles and Import-Package to dependencies
> - decide how to map Bundle-SymbolicName into a groupId + artifactId.
> - versions can probably be copied verbatim when you're not using snapshots
>
> The usual way to get something uploaded to ibiblio, is to put an
> upload request on the Maven JIRA together with the JAR and POMs. See
> http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
>
>  Tom
> _______________________________________________
> pde-build-dev mailing list
> pde-build-dev@xxxxxxxxxxx
>  https://dev.eclipse.org/mailman/listinfo/pde-build-dev
>
>
> _______________________________________________
> pde-build-dev mailing list
> pde-build-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/pde-build-dev
>
>
>
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev