Inlining dependencies

[David Blevins <da...@visi.com>]

Hi Guys,

Really curious on what approach you used to inline all your 3rd party  
deps into org.apache.tomcat.util.  Curious if you took them as is, or  
trimmed them down to just what you need.  Were any tools used to  
help?  Any disadvantages that you have noticed other than having to  
port fixes on those libs in?

I've been wanting to do a similar thing in OpenEJB.  Any input is  
appreciated.

-David




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

Re: Inlining dependencies

["William L. Thomson Jr." <wl...@gentoo.org>]

On Tue, 2007-07-31 at 14:59 -0400, Yoav Shapira wrote:
> > It's all done in Ant tasks: look for how
> the Tomcat build handles Jakarta Commons DBCP for example.

I absolutely despise how that is built. It makes building that jar a
complete NIGHTMARE. Presently we do not offer than jar on Gentoo and I
have no plans to. Or worse potential ways to.

Because I will have to hack around our packaging system to even make an
attempt. Hard coding versions of a libraries sources within another
package, and not as a package dependency. But as additional sources for
Tomcat :(. Despite a newer version of those libraries already existing
on the system. Which also means they have downloaded a copy of that
packages sources, but might not have installed the sources.

It is the oldest bug wrt to Tomcat on Gentoo :(
http://bugs.gentoo.org/buglist.cgi?quicksearch=tomcat

It came up in the past here, where others also disliked the process of
how it was built. But so far has fallen on deaf ears. I have not had the
time or chance to address the issue and provide you all with a code work
around.
http://marc.info/?l=tomcat-dev&m=115808287528288&w=2

>   We don't
> trim them down AFAIK, nor do we have to do any porting because we
> re-grab the library (ideally from a known stable version) with every
> release.

I see there are some slight modifications. Other than the re-branding
and re-packaging. Which at the end of the day I really fail to see the
benefit to this approach. Verses just shipping collections, pool, and
dbcp. 

Not to mention many drivers have their own factories. But recently as a
user discovered. This is not a valid work around for Global resources.
As that is hard coded no matter what is configured in server.xml to use
tomcat-dbcp.jar.

-- 
William L. Thomson Jr.
Gentoo/Java

Re: Inlining dependencies

[Yoav Shapira <yo...@apache.org>]

Hey,

On 7/31/07, David Blevins <da...@visi.com> wrote:
> > IIRC we take a known version of a library and do a string replace on
> > package names, essentially.  It's all done in Ant tasks: look for how
> > the Tomcat build handles Jakarta Commons DBCP for example.  We don't
> > trim them down AFAIK, nor do we have to do any porting because we
> > re-grab the library (ideally from a known stable version) with every
> > release.
>
> That's really cool.  Thanks for the info.
>
> I'm just very impressed with how clean the result is and there's the
> obvious benefit of those library versions not conflicting with any
> apps deployed without the need for fancy classloader scoping.

I can't take credit for the idea or the impl (I believe Remy was the
one who put it in), but it's certainly a simple solution that's worked
well for us.

Yoav

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

Re: Inlining dependencies

[David Blevins <da...@visi.com>]

On Jul 31, 2007, at 11:59 AM, Yoav Shapira wrote:

> Hey,
>
> On 7/31/07, David Blevins <da...@visi.com> wrote:
>> Really curious on what approach you used to inline all your 3rd party
>> deps into org.apache.tomcat.util.  Curious if you took them as is, or
>> trimmed them down to just what you need.  Were any tools used to
>> help?  Any disadvantages that you have noticed other than having to
>> port fixes on those libs in?
>
> IIRC we take a known version of a library and do a string replace on
> package names, essentially.  It's all done in Ant tasks: look for how
> the Tomcat build handles Jakarta Commons DBCP for example.  We don't
> trim them down AFAIK, nor do we have to do any porting because we
> re-grab the library (ideally from a known stable version) with every
> release.

That's really cool.  Thanks for the info.

I'm just very impressed with how clean the result is and there's the  
obvious benefit of those library versions not conflicting with any  
apps deployed without the need for fancy classloader scoping.

-David




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

Re: Inlining dependencies

[Yoav Shapira <yo...@apache.org>]

Hey,

On 7/31/07, David Blevins <da...@visi.com> wrote:
> Really curious on what approach you used to inline all your 3rd party
> deps into org.apache.tomcat.util.  Curious if you took them as is, or
> trimmed them down to just what you need.  Were any tools used to
> help?  Any disadvantages that you have noticed other than having to
> port fixes on those libs in?

IIRC we take a known version of a library and do a string replace on
package names, essentially.  It's all done in Ant tasks: look for how
the Tomcat build handles Jakarta Commons DBCP for example.  We don't
trim them down AFAIK, nor do we have to do any porting because we
re-grab the library (ideally from a known stable version) with every
release.

Yoav

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