tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pkriens <Peter.Kri...@aQute.biz>
Subject Re: Osgifing Tomcat
Date Mon, 28 Apr 2008 08:01:44 GMT

> 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
> <devlists@hanik.com> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 
> 
> 

-- 
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message