Bug#426259: ITP: springframework -- layered Java/J2EE application framework
Le Tuesday 02 September 2008 09:52:28 Andreas Schildbach, vous avez écrit :
> 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).
Okay, I haven't see your patch to build.xml :)
> > > 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 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.
You can convert your debian diff.gz to patches using diff2patches and now use
dpatch to apply/unapply them (modifying debian/control and debian/rules).
> I will setup a rule in d-r that automates the stripping. However, for
> the Spring source file, I'd prefer to exclude them from the build,
> rather than delete them from the orig's.
You're right, we must exclude them from build. But we may strip JAR files from
orig.tar.gz : there is 43Mb of JAR which is really insane ;)
> 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?
I also think we need a version control system. Subversion is fine for me.
Cheers,
--
Damien Raude-Morvan / www.drazzib.com
Reply to: