Hi Reinhard,
Some notes inlined below:
Reinhard Poetz wrote:
Rinku wrote:
<snip/>
So far I added the configuration parameter "pde". If set to true,
the PluginNature and the schema and manifest builders are added to
.project.
I have a patch submitted for this for the maven-eclipse-plugin.
Though not sure when that gets integrated into the plugin. IMHO you
would not need a separate config param but just detect the natures
being specified in the config and that should set up PDE project
definition.
My idea was consistency with the WTP configuration parameter, less
typing and I'm sure that I will never remember the class name of the
nature ;-)
While I agree to the inability to remember the name of PDE natures, I am
not really sure about having a WTP configuration parameter either. The
current plugin implementation adds the list of natures specified from
the plugin config. Not sure why we should deviate in case of adding the
PDE Plugin nature? Having said that, if there is a better way to handle
Eclipse project natures (in general) rather than specifying them as
fully qualified names in the plugin config - then best to raise
suggestions on this list :-)
Additionally, instead of pointing to libraries in the local
repository, I copy them to "target/osgi/lib" and point to them from
within .classpath - unfortunatly PDE doesn't allow referencing
libraries outside of the project (as you describe in 3).
Yep, I noticed that too. Just curious why do want to copy them to the
target/osgi/lib and then reference them from there. Why not copy them
under the PDE project/osgi/lib directory (and may be add that folder
to ignore list in for CVS/SVN).
My initial idea was that a "mvn clean" should remove them. But I'm not
sure about this.
I think it would be nice to be able create symlinks to JARs in M2_REPO
from a <plugin-project> /lib directory (for example) and then copy the
actual JARs when the Plugin is packaged(from a maven build). Though I am
not sure how Eclipse PDE would handle symlinks. But I think its a
cleaner way rather than copying around the whole shebang!
I think you will need to update both .classpath and Manifest.mf (see
3) for the libs.
Yes, the cocoon-maven-eclipse-plugin already does so.
Cool! I haven't had a chance to look cocoon version's sources but keen to.
Before I will provide a patch, I will implement what you describe in
2). I was thinking of keeping "Bundle-ClassPath" in sync with the
libraries in "target/osgi/lib".
You can also look under Apache Felix sources, they have a maven osgi
plugin implemented, may be you can draw some ideas from there as well.
Thanks for the pointer!
Thanks for the note. I had indeed missed your response :-)
Cheers,
Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
