Bug#426259: ITP: springframework -- layered Java/J2EE application framework

[Andreas Schildbach <andreas@schildbach.de>]

Hi Damien,

thanks for your update.

> 1) You can observe I'm using glassfish-javaee instead of libservlet2.4-
> java+libgnumail-java because glassfish-javaee include many more api (JTA, JSP, 
> Activation, EJB3, JMS, etc...)

This is what I am doing, too. Have you looked at (hacks to) build.xml?
This file is kind of documenting for each dependency from where it is
currently included (no more broad patterns for now).

However, with Servlet API included in Glassfish I had an API
incompatibility (compile error) to somewhere in the tiger build. This is
why I am including Servlet 2.4 as well.

> 2) I'm currently packaging libvelocity-tools-java (ITP #497436) and libtiles-
> java (ITP #497437). I've set them as blocker for this bug.

Actually, Tiles1 included with Struts is sufficient to compile.

> > Unfortunately, there are still loads of dependencies not in the archive,
> > some of which probably never will (e.g. SUN licence, does it permit
> > redistribution at all?)
> 
> You're right. We have to strip some part of springframework until someone re-
> licence them under a DFSG licence (for example Sun JSF + Portlet API, 
> Websphere, OC4J, etc...).

I will setup a rule in d-r that automates the stripping. However, for
the Spring source filed, I'd prefer to exclude them from the build,
rather than delete them from the orig's.

I will also setup one of the patch systems (dpatch or quilt) - I guess
we should prepare one patch per library removed. So if a library becomes
available under a free license, we just have to remove the patch.

Maybe we should also use a version control system. I was thinking about
Subversion, because I know it very well. And I have a server at hand.
What do you think?

Best regards,

Andreas