No Tiger specific jar file [SPR-850]

[spring-projects-issues]

matthew inger opened SPR-850 and commented

Currently, there is no way to seperate the "tiger" specific features from the rest of spring. If the tiger jvm is being used to run ant/maven, then it simply compiles the tiger classes and includes them in spring.jar.

This prevents users who want a 1.4 version from using the same jar file which contains the tiger code. Ideally, the majority of the code should be compiled with source/target of 1.4, and packaged up, and the tiger code should be compiled with 1.5, and put in it's own jar file.

I'm not sure what implications this has on spring.jar, since alot of users will simply want a single jar that has everything in it. But i think it's worth re-examining, and at least creating two versions of spring.jar:

spring-full-1.2.jar (contains all spring 1.4 compatible classes) spring-full-tiger-1.2.jar (contains all spring classes)

and having a tiger specific jar file (much like spring-aop, etc..)

spring-tiger-1.2.jar

---

Affects: 1.2 RC1

[spring-projects-issues]

Juergen Hoeller commented

I don't think that it makes sense to factor out the Tiger support classes into a separate jar file. After all, they are very small and fit nicely into the existing functionality-oriented jar files (alongside the transaction and JMX support, respectively).

You might have a misunderstanding regarding the build: If you build on JDK 1.5, you do get jar files including the Tiger support. However, everything but the Tiger support is still compiled with "-target 1.3"; only the classes in the "tiger" directory are compiled with "-target 1.5". This means that a full spring.jar that includes the Tiger support still runs nicely on JDK 1.3 and 1.4 (with the exception of the actual Tiger support classes, of course).

Juergen

[spring-projects-issues]

matthew inger commented

Also, ANT build should have version numbers in the produced jar files. Finally, the project.xml and maven.xml are not up to date for 1.2.

[spring-projects-issues]

Juergen Hoeller commented

Well-spotted: the Maven build needs to be brought up-to-date. This is already known, but none of the core developers actually uses the Maven build... We've even considered removing the Maven build completely, only providing the Ant build script.

Regarding version numbers in jar file names: This is an eternal debate that we've already had several times. Some people prefer "spring-1.2.jar" (in particular Maven users), some prefer "spring.jar" (to keep lib history in version control, etc).

We've started without version numbers, and haven't decided to switch yet. Hibernate hasn't switched either, BTW: they still ship a hibernate3.jar, without exact version number. Of course, everyone can rename such jar files easily...

Note that our jar files contain manifest entries with the exact version number. So if in doubt about the version number, you can open spring.jar with a zip tool and have a look at the manifest file.

Juergen