PDE nature for org.eclipse.uima.runtime

[Jörn Kottmann <ko...@gmail.com>]

Hello,

currently the maven build does not generate a  org.eclipse.uima.runtime
eclipse PDE project.
This is in some cases a problem for other plugins which depend on it,
in my case the Cas Editor which has the PDE nature.
It can be started, but the export (required to create a build) fails.

It is possible to generate a PDE project but this requires some  
changes to the pom.xml:

- version in the pom must be OSGI compliant
- maven places the dependent libraries in the base dir not in lib (I  
did not find a way to change it)
this must be changed in the plugin.xml

Other advantages are that maven than synchronizes the pom with the  
manifest and
PDE checks the manifest for errors.

Can I submit a patch for this ?

Jörn

Re: PDE nature for org.eclipse.uima.runtime

[Adam Lally <al...@alum.rpi.edu>]

On 3/21/07, Jörn Kottmann <ko...@gmail.com> wrote:
> Ok, you can use the patch attached to this mail.
>

Please create a JIRA issue and attach the patch there.  That way
there's a record that you've granted license to the ASF.


> > That sounds good, we have to maintain that file now anyway so that
> > doesn't make anything worse.  I still think we should still point this
> > out to the Maven eclipse plugin developers so maybe in some future
> > version they could solve this for us by letting us configure the
> > version number manually.
>
> Ok, I can do that. I will than also mention the problem with
> the broken classpath.
>

Thanks.

-Adam

Re: PDE nature for org.eclipse.uima.runtime

[Jörn Kottmann <ko...@gmail.com>]

Ok, you can use the patch attached to this mail.

> That sounds good, we have to maintain that file now anyway so that
> doesn't make anything worse.  I still think we should still point this
> out to the Maven eclipse plugin developers so maybe in some future
> version they could solve this for us by letting us configure the
> version number manually.

Ok, I can do that. I will than also mention the problem with
the broken classpath.

Re: PDE nature for org.eclipse.uima.runtime

[Adam Lally <al...@alum.rpi.edu>]

On 3/21/07, Jörn Kottmann <ko...@gmail.com> wrote:
> > I agree, that would be nice if the plugins would be set up as pde
> > projects.  Does this apply to other plugin projects, too, not just
> > uima runtime?
>
> Sure it applies for all plugin projects.
> I would like to suggest a workaround , we can set the maven-eclipse-
> plugin
> manifest parameter to an other manifest file e.g. .ignore.
> Than the META-INF/MANIFEST.MF is not modified.
> But we have maintain it.
>
> What do you think ?
>

That sounds good, we have to maintain that file now anyway so that
doesn't make anything worse.  I still think we should still point this
out to the Maven eclipse plugin developers so maybe in some future
version they could solve this for us by letting us configure the
version number manually.

> Also I found out that the plugin classpath is broken after mvn
> eclipse:eclipse,
> so every one must run after that manually the PDE-Tools/Update
> Classpath .. action.
>

A little annoying but not that bad, I still think this would be an
improvement overall.

-Adam

Re: PDE nature for org.eclipse.uima.runtime

[Jörn Kottmann <ko...@gmail.com>]

> I agree, that would be nice if the plugins would be set up as pde
> projects.  Does this apply to other plugin projects, too, not just
> uima runtime?

Sure it applies for all plugin projects.
I would like to suggest a workaround , we can set the maven-eclipse- 
plugin
manifest parameter to an other manifest file e.g. .ignore.
Than the META-INF/MANIFEST.MF is not modified.
But we have maintain it.

What do you think ?

Also I found out that the plugin classpath is broken after mvn  
eclipse:eclipse,
so every one must run after that manually the PDE-Tools/Update  
Classpath .. action.

Jörn

Re: PDE nature for org.eclipse.uima.runtime

[Adam Lally <al...@alum.rpi.edu>]

On 3/21/07, Jörn Kottmann <ko...@gmail.com> wrote:
> I had the maven-eclipse-plugin in my mind when I wrote the mail.
> There is an option for pde.

Ah... now I understand better what you were suggesting.  I didn't know
about the pde option.  When you mentioned maven I thought you were
referring to something that would get done at build-time (mvn
install).  But now I see you mean something that happens during mvn
eclipse:eclipse to better set up your eclipse workspace.  So, ignore
what I said about assemble-plugin.xml (that's a build-time step).

I agree, that would be nice if the plugins would be set up as pde
projects.  Does this apply to other plugin projects, too, not just
uima runtime?

> But this does not work out of the box,
> because the version is not OSGI compliant.

It's too bad they don't have an option to override the plugin name.
We could ask the maven eclipse plugin developers if there's any way to
do that, or if they could add it.

I suppose I shouldn't be too quick to rule out changing our POM.
Maybe others have a different opinion.  We could ask on
general@incubator.apache.org.

> <snip/>
> If we cannot change the version in the pom.xml, maybe we can write
> an ant build script which packages the classes of the other projects
> as jar files
> and then copy these jar files over the org.apache.uima.runtime project.
> The ant build file can than be included into the eclipse build system.
>

Or an ant task to post-process the results of eclipse:eclipse and fix
the plugin version number?  Or does eclipse:eclipse just fail
outright?

-Adam

Re: PDE nature for org.eclipse.uima.runtime

[Jörn Kottmann <ko...@gmail.com>]

> I'm not an Eclipse plugin development expert, but I think other UIMA
> Eclipse plugin developers install the UIMA runtime plugin into their
> Eclipse environment (meaning their plugins directory) and then the PDE
> allows other plugins to reference it from there rather than the
> workspace.  Is that not sufficient?

Yes this is possible. Currently I am using the eclipse setup  
described  on
the uima webpage. So I have also all uima projects in my workspace.
If I now add the org.apache.uima.runtime project to my plugin directory
it is duplicated, so I have to remove it from the workspace.
Every time something changes I have to redeploy it in my plugin  
directory.

I had the maven-eclipse-plugin in my mind when I wrote the mail.
There is an option for pde. But this does not work out of the box,
because the version is not OSGI compliant.

> If we do modify our build, is all that's necessary to include .project
> and .classpath files inside the
> org.apache.uima.runtime_2.1.0.incubating directory?  I think that
> would allow it to be imported as a PDE project.  If we prepare the
> .project and .classpath files ourselves and put them in SVN, then I
> think this can be done by modifying the Maven assembly descriptor
> (uimaj-ep-runtime/src/main/assembly/assemble-plugin.xml).  Or did you
> have something else in mind?

Simply checkin the .project and .classpath does not work.
The jar files of the dependent projects must
be copied or linked to the org.apache.uima.runtime project (Can this  
be done in the assemble-plugin.xml ?).
If the projects are only referenced (current setting) it does not work.
If we enable the pde option in the maven-eclipse-plugin this is done  
automatically.

> I don't think we want to change the version number in the POM, since
> we're following standard ASF conventions there.  Instead we configure
> the Maven assembly plugin to specifically designate an OSGi-compatible
> name for the directory that's produced.

If we cannot change the version in the pom.xml, maybe we can write
an ant build script which packages the classes of the other projects  
as jar files
and then copy these jar files over the org.apache.uima.runtime project.
The ant build file can than be included into the eclipse build system.

Jörn

Re: PDE nature for org.eclipse.uima.runtime

[Adam Lally <al...@alum.rpi.edu>]

On 3/21/07, Jörn Kottmann <ko...@gmail.com> wrote:
> Hello,
>
> currently the maven build does not generate a  org.eclipse.uima.runtime
> eclipse PDE project.
> This is in some cases a problem for other plugins which depend on it,
> in my case the Cas Editor which has the PDE nature.
> It can be started, but the export (required to create a build) fails.
>
> It is possible to generate a PDE project but this requires some
> changes to the pom.xml:
>
> - version in the pom must be OSGI compliant
> - maven places the dependent libraries in the base dir not in lib (I
> did not find a way to change it)
> this must be changed in the plugin.xml
>
> Other advantages are that maven than synchronizes the pom with the
> manifest and
> PDE checks the manifest for errors.
>
> Can I submit a patch for this ?
>

Hi Jörn,

I'm not an Eclipse plugin development expert, but I think other UIMA
Eclipse plugin developers install the UIMA runtime plugin into their
Eclipse environment (meaning their plugins directory) and then the PDE
allows other plugins to reference it from there rather than the
workspace.  Is that not sufficient?

If we do modify our build, is all that's necessary to include .project
and .classpath files inside the
org.apache.uima.runtime_2.1.0.incubating directory?  I think that
would allow it to be imported as a PDE project.  If we prepare the
.project and .classpath files ourselves and put them in SVN, then I
think this can be done by modifying the Maven assembly descriptor
(uimaj-ep-runtime/src/main/assembly/assemble-plugin.xml).  Or did you
have something else in mind?

I don't think we want to change the version number in the POM, since
we're following standard ASF conventions there.  Instead we configure
the Maven assembly plugin to specifically designate an OSGi-compatible
name for the directory that's produced.

-Adam