tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Osgifing Tomcat
Date Wed, 23 Apr 2008 21:53:26 GMT
Niall Pemberton 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
>   
doesn't really matter what you wrap the Bnd tool in, if the tool 
produces poor data.
>   
>>  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.
>   
no, just the basic import/export.
one can still automate it, just do it smarter than Bnd tool does

Filip
> 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
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message