2008/10/23 Gul Onural <[EMAIL PROTECTED]> > I am quite new to the OSGi and the project I am working on will be based > on OSGi. > > Obviously, one of our considerations is the loadbuild. I did some > googling on this subject to asses > what changes we have to make in our existing loadbuild environment to build > osgi bundles and I want > to ask some questions to the people in this list to get a general feeling > of what people are doing > for the loadbuilds. > > Currently, the project I am working on uses maven2 for the loadbuilds. May > be it is a naïve questions to ask, > but I am trying to see is a viable option for building osgi components > without making big changes to the existing > loadbuild infrastructure. > > By the way we are using* equinox osgi container*, not quite sure if this > matters from the loadbuild infrastructure point of view. > no, it shouldn't matter
> Based on my googling, I understand that there is a maven-osgi plugin which > our current loadbuild doesn't use this plugin. > maven-osgi-plugin is deprecated, it has been superceded by the maven-bundle-plugin: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html any questions about this plugin can be asked over at [EMAIL PROTECTED] > Now, here is my basic fundamental question : > > - Is it possible to use standard maven2 (without the maven-osgi plugin) to > generate osgi bundles, given that we will hand-write the MANIFEST.MF files, > rather than using maven-osgi plugin to generate them ? > certainly, for example if you put the manifest file under src/main/resources/META-INF/MANIFEST.MF then you can use the following maven-jar-plugin configuration to add it to the final jar: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile> </archive> <!-- etc --> or: <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile> if you want to use resource filtering on the manifest file. http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html then again if you use Eclipse/PDE to edit the file, you might want Maven to take the manifest from the top of the project, instead of src/main/resources (note this doesn't change the manifest location in the jarfile, just where the maven-jar-plugin should read the manifest from): <manifestFile>${project.basedir}/META-INF/MANIFEST.MF</manifestFile> > Is there any cases people can think of where this approach wouldn't work > technically ? I understand that this approach might manifest some > maintenance issues, but I am just trying to understand if it can get us > started. > this will work technically, at least to get you started - adding OSGi metadata to the manifest is all you need to turn a plain jarfile into an OSGi bundle. Of course, then the fun begins with getting the right imports/exports, sorting out legacy code that assumes hierarchical classloading, adding lifecycle code to set up and tear down threads, etc. But there's plenty of people around to help give advice when you need it :) in the longer term you'll want to look into using some form of automated manifest generation, or at least verification to make sure that any omissions/typos are seen early on. That way you can concentrate on the code and not worry about getting the manifest right. As Niclas mentioned there's a set of tools that we (OPS4J) developed to help build bundles in Maven: http://www.ops4j.org/projects/pax/construct/index.html but this is more suited to people starting a brand-new project rather than migrating an existing one. > Thanks, > > Gul > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Cheers, Stuart
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
