Hi Michael, On 21/09/2007, Hampel, Michael <[EMAIL PROTECTED]> wrote: > > Hello, > > Regarding the answer of Stuart I have a question about the intended use of > the bundleplugin > Manifest goal. > In the moment we are using the goal to generate the Manifest file to run > our bundles within > Eclipse (put the generated Manifest file where Eclipse expects it). (the > manifest goal runs additional > To the bundle goal) > This process works and is easy to install. I know that in certain > circumstances you will get > Differing manifest files from the manifest and bundle process - but > in most cases they are the same. > Stuart could you please detail why I should not use the manifest goal in > the described way?
it was really more of a warning to Manuel not to rely on it in this scenario as it wasn't originally designed for this use (it recomputes the manifest) differences usually occur when embedding dependencies or including resources - basically when the bundle contents aren't directly derived from the classpath if you run the manifest goal _after_ the bundle goal then it usually does match, but in this particular scenario (where Manuel wants to embed dependencies) it is safer to extract the manifest rather than use the manifest goal. perhaps we should update the bundle goal so it also writes the manifest to the file system, by default to target/classes/META-INF but allow custom locations... then you'd only need to use one goal to build the bundle and get the manifest, rather then computing it twice - I'll probably raise a JIRA issue to support this Thanx in advance for any help, > > Michael > > > > > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Stuart > McCulloch > Gesendet: Freitag, 21. September 2007 05:00 > An: [email protected] > Betreff: Re: connection of maven-bundle-plugin functionality to eclipse > IDE OSGi startup? > > On 21/09/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > hi, > > > > i managed to generate a bundle which lets itself install and start on > > commandline osgi-container. for the developing phase of course i would > > like to use OSGi runtime inside eclipse IDE, so debugging is possible > > and implement/run cycle is short. > > > > i am building my bundle with maven bundle-plugin and following settings: > > > > <instructions> > > ... > > <Embed-Transitive>true</Embed-Transitive> > > > > > > > <Embed-Dependency>*;groupId=!org.eclipse.equinox;inline=false</Embed-Dependency> > > ... > > </instructions> > > > > basically running my osgi bundle inside eclipse works if i add generated > > manifest to <rootFolderOfProject>/META-INF and if i layout embedded > > dependencies (see settings above) in <rootFolderOfProject> too (as > > stated in generated MANIFEST.MF). of course this manual actions are too > > much and hence not doable when developing. > > > yes - these are limitations of Eclipse PDE, which expects the manifest in > a > particular > place (which doesn't match well with Maven, where generated files go > inside > target) > and expects embedded jars to be exactly placed relative to the project > root. > > has anybody experience/suggestions in getting the bundle for release > > right and working inside eclipse IDE with same maven-bundle-plugin > > settings (dependencies are referenced correctly and correct path of > > MANIFEST.MF is set when doing RunAs...->OSGiStartup)? > > > there are a couple of things that can help automate this: > > 1) put dependencies under a target/dependency folder (with no group > sub-folder): > > <Embed-Directory>target/dependency</Embed-Directory> > <Embed-StripGroup>true</Embed-StripGroup> > > you can then use the dependency plugin "copy-dependencies" goal to > copy the > dependencies locally - they should then match the classpath entries > for Eclipse > > 2) unpack the generated manifest using another plugin (either antrun or > exec plugin) > - you can't use the bundleplugin manifest goal, as that's designed to > work against > existing non-OSGi artifacts that need wrapping > > FYI, the Pax-Construct plugin and archetypes do a lot of this for you > behind > the scenes: > > http://wiki.ops4j.org/confluence/x/8Q > > however, I'd strongly suggest trying out the Pax-Construct v2 *beta* as it > uses a much > cleaner project layout and has a bit better Eclipse integration (it munges > the manifest > before copying it to the PDE location, so you can put embedded jars > anywhere > you like) > > > > http://mcculls.blogspot.com/2007/09/calling-all-testers-pax-construct-v2.html > > Unfortunately the documentation is lacking, but each script supports -h > for > help, and just > running the script without any options will get it to prompt you, with > example responses. > Full documentation should be there next week :) > > There is one remaining niggle when developing OSGi with Eclipse and Maven > - > in Eclipse > developers tend to edit the PDE manifest first to add required packages to > the import list. > Then they build using Maven and wonder why it's failing - this is because > they haven't told > Maven of the required dependency! > > Projects like q4e (http://code.google.com/p/q4e) can help, as they make it > easier to add > dependencies direct from Eclipse, but they're in the early stages of > integration. There are > also ways to make your local Eclipse installation appear as a maven > repository, so you can > reference Eclipse jars from maven without having to locate a remote repo > for > them: > > http://docs.codehaus.org/display/MAVENUSER/Eclipse+Plugin > > HTH > > thanks! > > > > > > -- > > manuel aldana > > [EMAIL PROTECTED] > > homepage: www.aldana-online.de > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Cheers, Stuart > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Stuart
