Osgifing Tomcat

[hgomez]

>  I'm actually working in sandbox, and I plan to propose stuff for the
>  trunk - and thus  become active ( I'm very slow  those days - I don't have a lot of free time ).

Ditto.

I don't have a lot of free time, but I willing to take on my spare
time for OSGIfying Tomcat.

More all contributions, ideas, codes (Hi Jonas), are welcome.

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

[Remy Maucherat]

On Wed, 2008-04-23 at 16:00 +0200, Florent.BENOIT wrote:
> Also, for OSGi, as all is done by package (import/export) the first step
> is to be sure that API and Implementation are never in the same package
> name. So we can export APIs and keep private the implementation.

I think the first main problem with these frameworks is how intrusive
they are, esp compared with whet they provide :( I suppose there's no
problem with doing a tomcat-osgi in the sandbox if people want to. As I
said I really don't care.

Rémy



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

[Costin Manolache-2]

Well, adding OSGI-compatible manifests to the existing jars is not
that intrusive,
and could be easily done in the trunk. AFAIK an Activator is not required - i.e.
if you don't need the BundleContext or to add services, you can have a bundle
that just imports/exports packages.

I agree with Remy that any 'intrusive' part of OSGI should be avoided
and certainly
not be done in trunk - changing existing packaging shouldn't be done
just because
OSGI requires a separate bundle for API and impl.

Now - the really interesting part is not how to package tomcat to be
used inside OSGI,
but how to have tomcat use OSGI modules ( and package webaps as bundles ), and
how to do this in a non-intrusive way. It looks like felix has a
'programmatic'/embedded
mode, it would be interesting to see if it can be used, so all
configuration stays inside
web.xml/server.xml.

Costin

On Wed, Apr 23, 2008 at 7:49 AM, Remy Maucherat <remm@...> wrote:

> On Wed, 2008-04-23 at 16:00 +0200, Florent.BENOIT wrote:
>  > Also, for OSGi, as all is done by package (import/export) the first step
>  > is to be sure that API and Implementation are never in the same package
>  > name. So we can export APIs and keep private the implementation.
>
>  I think the first main problem with these frameworks is how intrusive
>  they are, esp compared with whet they provide :( I suppose there's no
>  problem with doing a tomcat-osgi in the sandbox if people want to. As I
>  said I really don't care.
>
>  Rémy
>
>
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

[hgomez]

> Well, adding OSGI-compatible manifests to the existing jars is not
>  that intrusive,
>  and could be easily done in the trunk. AFAIK an Activator is not required - i.e.
>  if you don't need the BundleContext or to add services, you can have a bundle
>  that just imports/exports packages.
>
>  I agree with Remy that any 'intrusive' part of OSGI should be avoided
>  and certainly
>  not be done in trunk - changing existing packaging shouldn't be done
>  just because
>  OSGI requires a separate bundle for API and impl.
>
>  Now - the really interesting part is not how to package tomcat to be
>  used inside OSGI,
>  but how to have tomcat use OSGI modules ( and package webaps as bundles ), and
>  how to do this in a non-intrusive way. It looks like felix has a
>  'programmatic'/embedded
>  mode, it would be interesting to see if it can be used, so all
>  configuration stays inside
>  web.xml/server.xml.
>
>  Costin

Silly question, but did experiments with OSGI could be done, first, in
tomcatlight ?

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

[Costin Manolache-3]

On Wed, Apr 23, 2008 at 8:36 AM, Henri Gomez <henri.gomez@...> wrote:
>
>  Silly question, but did experiments with OSGI could be done, first, in
>  tomcatlight ?
>

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.

The first part ( adding manifests to existing tomcat ) seems to have
support so could be done in the trunk.

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.

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.

Costin

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

[hgomez]

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

Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed here

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

[benoitf]

Henri Gomez wrote:
> Indeed
>
> I'll try to spend some time on mavenize tomcatlight first and how it
> could be done then for tomcat trunk.
>
> Next how to OSGIfy the mavenized tomcats, experiences and advices welcomed here
>
>  
Once Tomcat has been mavenized, with maven-bundle-plugin you can produce
bundles by specifying the import/export/private/etc. package in a
specific file or in the maven pom.xml file.
This plugin can analyze the existing classes (with BND tool) and may do
a lot of work for you to detect the packages that you want to
import/export/etc.

After that, you may begin to start to use OSGi Declarative Services,
Apache Felix iPOJO, etc.

Florent


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

[Johnny Kewl]

----- Original Message -----
From: "Henri Gomez" <henri.gomez@...>
To: "Tomcat Developers List" <dev@...>
Sent: Wednesday, April 23, 2008 2:24 PM
Subject: Re: Osgifing Tomcat


>>    Yes, the modular aspect is for sure a better choice. So we can have a
>> smaller Tomcat (by only using few bundles) or bundles loaded on demand.
>
> +1
>
> And select which part of the engine to be used.

I dont know about the whole OSGI thing, to be honest I fall asleep just
after the introduction to the thing ;) and ok a cell phone wants it so it
can do a form of plug and play, but then I cant see microsoft adding that to
their service manager, so for me its neither here nor there.

In my pragmatic user view, what I think would be nice is a "brainless"
interface to embedded.
So something like this... tomcat user uses full tomcat, gets all the XML
configured, webapps tested and running.... and then "presses a button" so to
speak, and that creates a little embedded source code example, the xml is
translated into a property file, the webapps placed in a "loadme folder", if
clustering is not needed, those libs fall out, and TC's remnants are stuck
in a lib folder... ie the user just needs to compile the template for their
first embedded app.

Something like that I think would be good for TC, and I think it would
result in a more modular tomcat.
From "that" embedded program, the "user" has the choice of OSGIenabling, or
not, OSGI may even be an add on at that level. So you morphing TC not
bulking it, kind of idea.

If TC did have a "push my button to embed me" kind of utility... I think,
big sales.
A kind of "use the big tomcat"... "and we'll make the little one for you"...
thing.
I mention it because TC is definitely losing "sales" on embedded... the user
actually assumes it works a little like the "press my button" analogy... and
its nothing like it... lost sale.

I think TC's popularity comes from being fairly easy to use, and its out of
the box up and running... good theme to follow... maybe ;)


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

[Filip Hanik - Dev Lists]

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


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

[hgomez]

So nobody object for some experimentation around mavenizing Tomcat 6 ?

Of course no commit just testing on my own eclipse/m2 workspace.

>2008/4/23 Filip Hanik - Dev Lists <devlists@...>:
>
> 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: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
> >
> >
> >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

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

[Filip Hanik - Dev Lists]

hi Henri,

Henri Gomez wrote:
> So nobody object for some experimentation around mavenizing Tomcat 6 ?
>  
no one can object what you do on your own time. It's your given right.
However, if you look at the previous discussions around the Maven topic,
you will see it is highly unlikely that the Tomcat community as it is
today will adapt Maven anytime soon, if ever. No one has yet produced a
viable reason for us to do so, and the OSGi-fying features of Maven, are
not good at all, and one can produce a much better and cleaner manifest
manually or simple package scanners with tools like jarjar.

Filip

> Of course no commit just testing on my own eclipse/m2 workspace.
>
>  
>> 2008/4/23 Filip Hanik - Dev Lists <devlists@...>:
>>
>> 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: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>>
>>>
>>>
>>>      
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscribe@...
>>  For additional commands, e-mail: dev-help@...
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>  

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

[Costin Manolache-2]

First define 'mavenizing' please :-)

If you mean exporting tomcat components in maven repository - fine with me.

If you mean building tomcat with maven instead of ant - the opposite,
absolutely not fine.
Maintaining a separate maven build file - unofficial, i.e. the default
build instructions still point to
ant - maybe.


Costin

On Wed, Apr 23, 2008 at 12:52 PM, Filip Hanik - Dev Lists
<devlists@...> wrote:

> hi Henri,
>
>
>  Henri Gomez wrote:
>
> > So nobody object for some experimentation around mavenizing Tomcat 6 ?
> >
> >
>  no one can object what you do on your own time. It's your given right.
>  However, if you look at the previous discussions around the Maven topic,
> you will see it is highly unlikely that the Tomcat community as it is today
> will adapt Maven anytime soon, if ever. No one has yet produced a viable
> reason for us to do so, and the OSGi-fying features of Maven, are not good
> at all, and one can produce a much better and cleaner manifest manually or
> simple package scanners with tools like jarjar.
>
>  Filip
>
>
>
> > Of course no commit just testing on my own eclipse/m2 workspace.
> >
> >
> >
> > > 2008/4/23 Filip Hanik - Dev Lists <devlists@...>:
> > >
> > > 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: dev-unsubscribe@...
> > > > For additional commands, e-mail: dev-help@...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >  ---------------------------------------------------------------------
> > >  To unsubscribe, e-mail: dev-unsubscribe@...
> > >  For additional commands, e-mail: dev-help@...
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
> >
> >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

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

[hgomez]

> First define 'mavenizing' please :-)

Yes

>  If you mean exporting tomcat components in maven repository - fine with me.

It's allready done (by hand) ?

>  If you mean building tomcat with maven instead of ant - the opposite,
>  absolutely not fine.

it was the idea.

>  Maintaining a separate maven build file - unofficial, i.e. the default
>  build instructions still point to ant - maybe.

To modularise we should use modules layout ie :

pom.xml

-- catalina
    pom.xml

-- catalina-ant
    pom.xml

-- catalina-ha
    pom.xml

-- jasper
    pom.xml

-- jasper-jdt
    pom.xml

....

So some changes in the actual source layout.

we could also provide ant scripts to build also from this new layout.

Could you comment why maven is not the welcome here, ASF JackRabbit or
ApacheDS are pretty large projects and allready use it.

I don't want to start a pros/cons maven, but it will ease :

- build TC from scratch

- upload artifact to maven repos

- fit finelly with IC tools, like Hudson or TeamCity

- maven tools like maven-bundle-plugin will ease the OSGI bundle stuff

Cheers

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

[Costin Manolache-3]

On Wed, Apr 23, 2008 at 1:17 PM, Henri Gomez <henri.gomez@...> wrote:

> > First define 'mavenizing' please :-)
>
>  Yes
>
>
>  >  If you mean exporting tomcat components in maven repository - fine with me.
>
>  It's allready done (by hand) ?
>
>
>  >  If you mean building tomcat with maven instead of ant - the opposite,
>  >  absolutely not fine.
>
>  it was the idea.

Sorry, -1 from me ( again ).

>
>
>  >  Maintaining a separate maven build file - unofficial, i.e. the default
>  >  build instructions still point to ant - maybe.
>
>  To modularise we should use modules layout ie :
>
>  pom.xml
>
>  -- catalina
>     pom.xml

>  So some changes in the actual source layout.

And that would be the reason for -1.
If a build system requires intrusive changes and forces a particular code
organization - it shouldn't be used.

>  Could you comment why maven is not the welcome here, ASF JackRabbit or
>  ApacheDS are pretty large projects and allready use it.

It is a choice each project can make, some people  like intrusive tools :-)

I think it is great to have alternative build files - as long as the
build system plays
nicely with others and doesn't set conditions on how we should organize code.
In particular - we have eclipse build support, it would be great to
add idea/netbeans
if anyone can support them - and if you can add maven in the same way ( i.e.
just maven files in a separate dir, without changes to source layout
just because
maven needs them) - no problem with me.

Costin

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

[hgomez]

>  >  it was the idea.
>
>  Sorry, -1 from me ( again ).

Sic...

>  And that would be the reason for -1.
>  If a build system requires intrusive changes and forces a particular code
>  organization - it shouldn't be used.

that's maven phylosophy, not so bad.

>  It is a choice each project can make, some people  like intrusive tools :-)

Intrusive ? Nope, just maven convention.

>  I think it is great to have alternative build files - as long as the
>  build system plays
>  nicely with others and doesn't set conditions on how we should organize code.
>  In particular - we have eclipse build support, it would be great to
>  add idea/netbeans
>  if anyone can support them - and if you can add maven in the same way ( i.e.
>  just maven files in a separate dir, without changes to source layout
>  just because
>  maven needs them) - no problem with me.

I use eclipse with m2eclipse and the support for multi modules is right.

Netbeans has a great maven support with mevenide (may be the best) and
some co-workers use IDEA and are very happy with its maven support.

From my experience a mavenized project is buildable from command line
and with majors IDEs.

I've got a decent experiences after converting more than 100 projects
from ant to maven and make them as confortable under Eclipse than
previously.

Using maven and keeping the actual layout will be possible, but will
complexify the mvn and poms.

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

[Filip Hanik - Dev Lists]

Henri Gomez wrote:

>> First define 'mavenizing' please :-)
>>    
>
> Yes
>
>  
>>  If you mean exporting tomcat components in maven repository - fine with me.
>>    
>
> It's allready done (by hand) ?
>
>  
>>  If you mean building tomcat with maven instead of ant - the opposite,
>>  absolutely not fine.
>>    
>
> it was the idea.
>  

This subject has been beaten do death, with the same outcome, I don't
think it does anyone any good going there again

Filip

>  
>>  Maintaining a separate maven build file - unofficial, i.e. the default
>>  build instructions still point to ant - maybe.
>>    
>
> To modularise we should use modules layout ie :
>
> pom.xml
>
> -- catalina
>     pom.xml
>
> -- catalina-ant
>     pom.xml
>
> -- catalina-ha
>     pom.xml
>
> -- jasper
>     pom.xml
>
> -- jasper-jdt
>     pom.xml
>
> ....
>
> So some changes in the actual source layout.
>
> we could also provide ant scripts to build also from this new layout.
>
> Could you comment why maven is not the welcome here, ASF JackRabbit or
> ApacheDS are pretty large projects and allready use it.
>
> I don't want to start a pros/cons maven, but it will ease :
>
> - build TC from scratch
>
> - upload artifact to maven repos
>
> - fit finelly with IC tools, like Hudson or TeamCity
>
> - maven tools like maven-bundle-plugin will ease the OSGI bundle stuff
>
> Cheers
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>  

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

[hgomez]

I grab jackrabbit and apacheds right now from eclipse :

- added their repositories to eclipse

- checkout maven project from SVN

- got the main project and modules in the eclipse workspace

- mvn package and voila it works !

Hard to be simpler :)

Just a note, I'm not a maven evangelist :)

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

[Niall Pemberton-2]

On Wed, Apr 23, 2008 at 6:56 PM, Filip Hanik - Dev Lists
<devlists@...> 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@...
For additional commands, e-mail: dev-help@...

[Filip Hanik - Dev Lists]

Niall Pemberton wrote:

> On Wed, Apr 23, 2008 at 6:56 PM, Filip Hanik - Dev Lists
> <devlists@...> 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@...
> For additional commands, e-mail: dev-help@...
>
>
>  

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

[Costin Manolache-2]

On Wed, Apr 23, 2008 at 1:38 PM, Henri Gomez <henri.gomez@...> wrote:

>  >  And that would be the reason for -1.
>  >  If a build system requires intrusive changes and forces a particular code
>  >  organization - it shouldn't be used.
>
>  that's maven phylosophy, not so bad.

The layout may be good ( by some people taste ) - the bad is imposing
it on others.
We need build tools, not philosophy.


>  >  It is a choice each project can make, some people  like intrusive tools :-)
>
>  Intrusive ? Nope, just maven convention.

If the maven convention is to move files around just to use a
particular tool - that's quite
intrusive IMO.


>  Using maven and keeping the actual layout will be possible, but will
>  complexify the mvn and poms.

That's maven's problem - I don't think there is any value in
continuing this discussion,
again - if you can support maven by adding a build/maven directory and
whatever files
inside - you have my +1, I'm all for making it easy to build - as long
as the tools are not
intrusive and don't force in their religion and arbitrary conventions.

Costin

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