> Someone recently pointed out to me that the Bnd tool comes with ant > tasks. I haven't tried that (we've used maven in commons) and I > suspect that there isn't the option to just produce the manifest > (rather than jar and manifest) as there is in the maven plugin. If > that was required then in might be worth requesting that: If you need this, let me know. However, it might be an idea to start with a separate set of jars that are produced by bnd, independently of the main jars. You can setup bnd as ant task, give it a classpath of the primary jars and then provide the recipe to create the manifest. This way, nobody has to become nervous for touching the crown jewels.
> Are you talking about all the "uses" statements it adds? If so an > option to turn off producing them was recently added to the Bnd tool - > which improves the situation. It still wraps everything to 72 > characters which is harder to read than a manually created manifest - > but I think automating this to reduce the chance of errors from > manually keying in is worth the trade off. The manifest is a machine readable file, it is not intended for humans. I.e. the 72 caracter limit is in the Java spec, not the OSGi spec. The bnd recipe file (which is a properties file) is the one that is intended to be readable, not the generated manifest. And yes, you can switch off the generation of uses but the uses directive has a very important purpose: class space consistency. It ensures that the class loaders will not put two classes in the same class space if they could clash. I.e. if both classes use class com.foo.A, then the OSGi framework must ensure that com.foo.A really comes from the same classloader for both bundles. The uses define for each package, what other imported or exported packages are used. I -strongly- recommend against switching this off. The option was only added for a very specific use case. Bnd used as command line can also display this information in a less human unfriendly form. I.e. you can use bnd as a dependency analyzer. Kind regards, Peter Kriens Niall Pemberton-2 wrote: > > On Wed, Apr 23, 2008 at 6:56 PM, Filip Hanik - Dev Lists > <[EMAIL PROTECTED]> 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. > > Someone recently pointed out to me that the Bnd tool comes with ant > tasks. I haven't tried that (we've used maven in commons) and I > suspect that there isn't the option to just produce the manifest > (rather than jar and manifest) as there is in the maven plugin. If > that was required then in might be worth requesting that: > > http://www.aqute.biz/Code/Bnd > >> 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 > > Are you talking about all the "uses" statements it adds? If so an > option to turn off producing them was recently added to the Bnd tool - > which improves the situation. It still wraps everything to 72 > characters which is harder to read than a manually created manifest - > but I think automating this to reduce the chance of errors from > manually keying in is worth the trade off. > > Niall > >> 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] > > > -- View this message in context: http://www.nabble.com/Osgifing-Tomcat-tp16830131p16930383.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]
