Niall Pemberton 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
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
