Summary: | dev-java/spring-framework - build simple, portable, fast and flexible JVM-based systems and applications | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Josh Nichols (RETIRED) <nichoj> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | alonbl, eric225125, java, mgorny, wizardedit |
Priority: | Normal | Keywords: | EBUILD, InOverlay |
Version: | 2005.0 | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://spring.io/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 96751, 96906, 97005, 97007, 97008, 97009, 97011, 97012, 97720, 97756, 203076, 203080, 263636 | ||
Bug Blocks: | 177517, 237562, 259673, 487280, 582012 | ||
Attachments: |
spring-framework-1.2.1.ebuild
ebuild for the framework fixes hardcoded version number in build.xml dev-java:spring-context-3.2.4:20131024-205518.log spring-context-3.2.4.ebuild spring-context-3.2.4-build.xml |
Description
Josh Nichols (RETIRED)
![]() Created attachment 61890 [details]
spring-framework-1.2.1.ebuild
This ebuild utilizes patches/ebuilds from dependent bugs.
I've said this a couple time (in fewer words) in #gentoo-java, but will repeat
it here:
Spring framework has a number of features. A lot of jars are needed to build
the framework. However, some jars are only necessary for some features at
runtime for that particular feature. For example, hibernate2 jars are needed
when using Spring's Hibernate 2.1.x support.
So, I suggest that we replace jars where we can, and leave the rest until their
dependencies can be filled. In addition, make a notice that some features will
not work at runtime because their runtime dependencies haven't packaged yet.
If we don't do this, I suspect that it will be a _very_ long time before all
the dependencies can be packaged ie, geronimo is a dependency of one of the
dependencies.
Now maintained in the experimental overlay: https://gentooexperimental.org/svn/java/gentoo-java-experimental/dev-java/spring-framework/ The spring-framework ebuild is not out of date. So this bug will reflect the efforts to produce a ebuild for the 2.5 (and up) versions of spring. (In reply to comment #3) > The spring-framework ebuild is not out of date. So this bug will reflect the > efforts to produce a ebuild for the 2.5 (and up) versions of spring. > Still at it? Will attach an updated ebuild for the spring-framework. Any thoughts? Created attachment 183195 [details]
ebuild for the framework
There is still a long way to go to build it from source code only.
Created attachment 183197 [details, diff]
fixes hardcoded version number in build.xml
I'm working on the ebuilds for the various spring-* components in the last-hope overlay https://github.com/ercpe/lh-overlay/tree/master/dev-java as spring-core and spring-beans are dependencies of dependencies of .. for ganttproject (#119276). The modules spring-core, spring-beans, spring-aop and spring-expression from the 3.2.4 version are now in the tree: + 18 Oct 2013; Johann Schmitz <ercpe@gentoo.org> +metadata.xml, + +spring-core-3.2.4.ebuild: + Ebuild for the core module of the spring framework (wrt #97004) Needed + standalone and as a dependency of multiple packages. + 18 Oct 2013; Johann Schmitz <ercpe@gentoo.org> +metadata.xml, + +spring-beans-3.2.4.ebuild: + Ebuild for the beans module of the spring-framework (wrt #97004) + 18 Oct 2013; Johann Schmitz <ercpe@gentoo.org> +metadata.xml, + +spring-aop-3.2.4.ebuild: + Ebuild for the aop (aspect-oriented programming) module of the spring + framework (#97004) + 18 Oct 2013; Johann Schmitz <ercpe@gentoo.org> +metadata.xml, + +spring-expression-3.2.4.ebuild: + Ebuild for the expression module of the spring framework (#97004) I'm will package the other modules at some point, but first i want to finally finish some other packages which depend on the above named modules. If someone wants to finish the other modules in the meantime, here are some notes: - The source tarball is the same for all modules. The ebuilds use the renaming functionality to avoid downloading it multiple times. I skipped the idea of one big ebuild because some modules (e.g. spring-web) have a pretty large dependency tree. - The ant build scripts are custom build and are downloaded from my dev space (http://dev.gentoo.org/~ercpe/distfiles/dev-java/spring-framework/). The content of the tarball follows the directory structure in the source tarball because there are some dependencies when building and running the test suites (see below). - The spring-core ebuild bundles asm and cglib (taken from the jar installed by the ebuilds in the tree). Technically it's possible to unbundle it, but it would require a lot of work to patch the source code of the other spring modules. The - The test code of the other spring modules require some portions of the spring-core/spring-beans test code. These two build scripts have a special target for building these bits which gets called the other build scripts via antcall. The target roughly excludes the junit tests and builds only the test utility classes. (In reply to Johann Schmitz (ercpe) from comment #8) > - The spring-core ebuild bundles asm and cglib (taken from the jar installed > by the ebuilds in the tree). Technically it's possible to unbundle it, but > it would require a lot of work to patch the source code of the other spring > modules. The Will that help? http://pkgs.fedoraproject.org/cgit/springframework.git/tree/springframework-dont-rebundle-asm.patch?h=f20 Created attachment 361834 [details]
dev-java:spring-context-3.2.4:20131024-205518.log
Almost finished on spring-context, still needs hibernate-validator which appears to have a build.xml with quite some ivy instructions present; either needs quite some patching or the use of java-pkg-simple. And indeed, the other part of the errors seem like those can be fixed by the patch you have linked.
Created attachment 361836 [details]
spring-context-3.2.4.ebuild
Created attachment 361838 [details]
spring-context-3.2.4-build.xml
Yet another 10 years old bug. So many of these "ancient" bugs in Bugzilla.. amazing. Anyway. A quick glance at http://projects.spring.io/spring-framework/ shows us that the version Gentoo package is way out of date (not even listed anymore). @Java: Spring is a recurring issue we should sort out at some point or it will ever and again get back at us and bite our backs. I have masked the Spring Framework packages we have for the time being because they're old, vulnerable, and we're not likely to update them any time soon. Hopefully we can revisit it when the Maven stuff works out. Going to mark WONTFIX after removal of Spring packages. Feel free to reopen if someone wants to work on it again. |