> my feeling is though, is that you are going for the "mavenization" just > to run the BND or BNE or whatever the plugin is called, that generates > the OSGi manifests. The project is called bnd (pronounce b and d). The jar can be used as an ant task, command utility, eclipse plugin, and library. The Apache Felix project (an OSGi implementation) has wrapped this library in plugin.
> having personally done that, I can say that it simply doesn't work. IT > works in most cases, but not in Tomcat, and even in the cases it works, > the output it produces into the manifest file is completely useless to > the human eye. the amount of stuff it exports and imports is insane, in > in most cases irrelevant to the data you actually wanna export/import As the author of bnd I'd like to object :-) I assume you have used the wrap function that just exports anything and imports everything optional. This is a convenience function that is used to get an existing JAR osgified quickly. Extremely useful if you need it, but it obviously bnd can not guess your module boundaries. That is why it is so important that the developers of a library do this because not only do they know the boundaries, they can also improve them. Therefore, bnd normally uses a recipe to steer it. This recipe allows you to use wildcards and variables to minimize the amount of manifest work. I.e. Import-Package: * Will import everything (the default). However, if you have an ant task in your code but that task is only used in build time, then you like want to exclude the ant imports from your bundle to not create a dependency on it: Import-Package: !org.apache.ant.*, * Inside the OSGi we use org.osgi.service.* packages for public API, and org.osgi.impl.* packages for private code. The private and export package headers allow wildcard packagenames. These packages are copied from the classpath into the JAR. This is included in the JAR like: Export-Package: org.osgi.service.log.* Private-Package: org.osgi.impl.log.* So what bnd does is a combination of packaging packages from the classpath, analyzing the result, calculating the manifest, and then at the end a thorough analysis of all the headers so you catch errors before you deploy. > that's why I posted my combined version of the Export/Import, nice and > clean, when/if we do it on a per jar basis, I would hope we aim to > produce the same quality data as the example I showed. The problem is getting it right the first time and then maintaining it over time. This kind of information is extremely sensitive to refactoring, additions of packages, and use of other code. The manifest is NOT intended for the human, it is intended for an OSGi framework. I.e. the Java manifest rules state that you must break after 72 characters, the uses statement is crucial to maintain classpace consistency but is quite verbose. However, when you use bnd, you can use the recipe file quite readable due the wildcards and defaults. This recipe is supported in the ant task, eclipse plugin, and command line. In the maven plugin it is encoded in the POM (and can take variables from the pom). Bnd can be used from the command line to show the information in a much more readable form. Anyway, if bnd generates a lot of information in the manifest, than this information is really in your JAR. It creates Import-Package statements (and uses directives) based on an analysis of your class files. Some people do not trust bnd to generate the JAR. Bnd could just generate the manifest if this is an issue. However, I would suggest to try to let bnd do the packaging because it is quite flexible and reliable. One of the cool things (at least I think it is) is that you can really compose your jars, regardless of project boundaries. If there is anything special that you need from bnd, let me know. Kind regards, Peter Kriens Filip Hanik - Dev Lists wrote: > > Henri Gomez wrote: >>> I'm not sure it's the best idea, my goal is to move it out of sandbox, >>> it already has enough experiments >>> that need completion. and the main goal is to be 'lite' :-). It has a >>> simple Addon mechanism, and I don't mind >>> having an optional addon manager impl using OSGI - but I don't want to >>> get distracted, I started >>> tomcat-lite experiment >2 years ago. >>> >>> >> >> Yep, time to stabilize >> >> >>> The first part ( adding manifests to existing tomcat ) seems to have >>> support so could be done in the trunk. >>> >> >> And no consequences outside OSGI world >> >> >>> I don't see any reason for having non-intrusive OSGI support developed >>> in sandbox - as long >>> as the code is in a package that is excluded from the official distro, >>> and is released as a separate >>> unit it could live in trunk. It'll need the 3 +1 to be released, of >>> course - but the whole point of >>> modularity is to be able to develop modules independent of the >>> container. >>> >> >> Right >> >> >>> IMO sandbox is for experiments that would replace existing tomcat >>> components or core stuff. If you do it in >>> trunk - it's easier to get it released eventually, and you may get >>> better reviews and attention. >>> >> >> Indeed >> >> I'll try to spend some time on mavenize tomcatlight first and how it >> could be done then for tomcat trunk. >> > LOL, ouch, you just opened up the can of worms we thought we put a lid > on :) he he > basically, Tomcat 6 is mavenized, and we publish the individual JARs to > ASF Maven repo. >> Next how to OSGIfy the mavenized tomcats, experiences and advices >> welcomed here >> > my feeling is though, is that you are going for the "mavenization" just > to run the BND or BNE or whatever the plugin is called, that generates > the OSGi manifests. > having personally done that, I can say that it simply doesn't work. IT > works in most cases, but not in Tomcat, and even in the cases it works, > the output it produces into the manifest file is completely useless to > the human eye. the amount of stuff it exports and imports is insane, in > in most cases irrelevant to the data you actually wanna export/import > > that's why I posted my combined version of the Export/Import, nice and > clean, when/if we do it on a per jar basis, I would hope we aim to > produce the same quality data as the example I showed. > > Filip >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Osgifing-Tomcat-tp16830131p16930379.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
