Bug#426259: ITP: springframework -- layered Java/J2EE application framework
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please consider joining the Debian Java team [1] and putting your work in the our svn repository [2]. It will be easier for other developers to work on the packages. [1] http://pkg-java.alioth.debian.org/ [2] http://svn.debian.org/wsvn/pkg-java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki+lToACgkQXjXn6TzcAQnAKACbB3nHU76aeeeSFvNTKRKwtNqo eVQAoPopdlvg/YK7YconHt41ipbMZEVe =KVWN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426259: ITP: springframework -- layered Java/J2EE application framework
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426259: Bug #426259: ITP: springframework -- layered Java/J2EE application framework
Hi, Le Saturday 30 August 2008 12:48:53 Torsten Werner, vous avez écrit : reopen 426259 retitle 426259 ITP: springframework -- layered Java/J2EE application framework owner 426259 Andreas Schildbach [EMAIL PROTECTED] thanks Andreas is willing to help with the package. I recently had a look to Springframework and I think it's a really big package for one man alone : 1600+ Java source file and 80+ Build-Depends. I'm willing to help too, could we make a team to work on this package ? Cheers, -- Damien Raude-Morvan / www.drazzib.com signature.asc Description: This is a digitally signed message part.
Bug#426259: Bug #426259: ITP: springframework -- layered Java/J2EE application framework
Hi Damien, I'm willing to help too, could we make a team to work on this package ? Glad you are asking. I have already uploaded a very rough first version of the Debian package to mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libspring-2.5-java - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libspring-2.5-java/libspring-2.5-java_2.5.5-1.dsc I have identified most - if not all - build/runtime dependencies that are already included in the Debian archive (see debian/control). 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?) But those that can be packaged should probably be packaged soon. Maybe you want to take this task? I will compile a list and attach it to this task. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426259: ITP: springframework -- layered Java/J2EE application framework
Le Monday 01 September 2008 22:07:31 Andreas Schildbach, vous avez écrit : Hi Damien, Hi Andreas, I'm willing to help too, could we make a team to work on this package ? Glad you are asking. I have already uploaded a very rough first version of the Debian package to mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libspring-2.5-java - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libspring-2.5-java/libspring-2 .5-java_2.5.5-1.dsc I have identified most - if not all - build/runtime dependencies that are already included in the Debian archive (see debian/control). I had a look at your package and I've compared your B-D field with my homemade listing. Here is the diff : +antlr +aspectj +bsh +glassfish-javaee +glassfish-mail +junit +junit4 +libcglib2.1-java +libcommons-beanutils-java +libcommons-codec-java +libcommons-dbcp-java +libcommons-digester-java +libcommons-discovery-java +libcommons-io-java +libcommons-lang-java +libcommons-validator-java +libeasymock-java +libehcache-java -libgnumail-java +libhibernate3-java +libhsqldb-java +libibatis-java +libjarjar-java +libjaxen-java -libservlet2.4-java +libmx4j-java +libqdox-java +libquartz-java +libslf4j-java +libtiles-java +libvelocity-tools-java +libwsdl4j-java Has you can see, I'm trying to build every single module of spring 2.5 source code :) 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...) 2) I'm currently packaging libvelocity-tools-java (ITP #497436) and libtiles- java (ITP #497437). I've set them as blocker for this bug. 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...). Here is my list of removed JAR due to licencing problems : - commonj-twm.jar - websphere_uow_api.jar - portlet-api.jar - oc4j-clapi.jar So that, I've removed the following files/directories from orig.tar.gz : org/springframework/web/portlet org/springframework/transaction/jta - WebSphereUowTransactionManager.java - WebSphereTransactionManagerFactoryBean.java - JotmFactoryBean.java org/springframework/scheduling/commonj org/springframework/jdbc/support/nativejdbc/XAPoolNativeJdbcExtractor.java I've also patched org/springframework/scripting/support/ScriptFactoryPostProcessor.java to use import org.objectweb.asm.Type instead of net.sf.cglib.asm.Type But those that can be packaged should probably be packaged soon. Maybe you want to take this task? I will compile a list and attach it to this task. I'm currently working on libvelocity-tools-java, libtiles-java, bnd, jasperreports. Cheers, -- Damien Raude-Morvan / www.drazzib.com signature.asc Description: This is a digitally signed message part.
Processed: Bug #426259: ITP: springframework -- layered Java/J2EE application framework
Processing commands for [EMAIL PROTECTED]: reopen 426259 Bug#426259: RFP: springframework -- layered Java/J2EE application framework Bug reopened, originator not changed. retitle 426259 ITP: springframework -- layered Java/J2EE application framework Bug#426259: RFP: springframework -- layered Java/J2EE application framework Changed Bug title to `ITP: springframework -- layered Java/J2EE application framework' from `RFP: springframework -- layered Java/J2EE application framework'. owner 426259 Andreas Schildbach [EMAIL PROTECTED] Bug 426259 [wnpp] ITP: springframework -- layered Java/J2EE application framework Owner recorded as Andreas Schildbach [EMAIL PROTECTED]. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426259: ITP: springframework -- layered Java/J2EE application framework
On 5/27/07, Torsten Werner [EMAIL PROTECTED] wrote: * Package name: springframework Hourra! :-D -- Arnaud Vandyck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426259: ITP: springframework -- layered Java/J2EE application framework
Package: wnpp Severity: wishlist Owner: Torsten Werner [EMAIL PROTECTED] * Package name: springframework Version : 2.0.5 Upstream Author : Interface21 * URL : http://www.springframework.org/ * License : Apache 2.0 Programming Lang: Java Description : layered Java/J2EE application framework Springs mission are: - J2EE should be easier to use. - It's best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero. - JavaBeans offer a great way of configuring applications. - OO design is more important than any implementation technology, such as J2EE. - Checked exceptions are overused in Java. A framework shouldn't force you to catch exceptions you're unlikely to be able to recover from. - Testability is essential, and a framework such as Spring should help make your code easier to test. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
