Spring Webflow 2.3.0.RELEASE build problems

[smaines]

I'm starting a new project, and wanted to build the samples before I begin.

I've tried both spring-webflow-2.3.0.RELEASE-with-dependencies.zip and spring-webflow-2.3.0.RELEASE.zip. These only build if I disable bundlor, i.e.

$ cd build-spring-webflow
$ ant -Ddisable.bundlor=true

... though once built like this, they pass all tests.

[why disable.bundlor? this would entail discussion of
* getting NoSuchMethodException on org.objectweb.asm.ClassReader.accept(org.objectweb .asm.ClassVisitor, int)
* scanning all the asm jars, including my own JRE, establishing that 1.5.3 lacked the method, but 3.0+ had it
* eliminating 1.5.3 jars just in case that was causing the NoSuchMethod exception
* still getting NoSuchMethodException, suggesting that none were on the classpath
* availing myself of disable.bundlor flag found in offending artifact.xml
* wondering aloud what is a bundlor, anyway?
]

So I move on to spring-webflow-samples, and follow the instruction to package with mvn:

$ cd ../spring-webflow-samples/
$ mvn -U package

...this fails on trying to pull joda-time-jsptags-1.0.2.pom, so I try just going to the sample I want

$ cd booking-faces
$ mvn -U package

...which fails to pull org.primefaces:primefaces:jar:2.2.1.

As to my environment, I am running recent versions of everything...

$ ant -version
Apache Ant(TM) version 1.8.2 compiled on June 8 2011

$ java -version
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.4) (fedora-60.1.10.4.fc15-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)

$ mvn --version
Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /opt/maven-rigged
Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.41.10-3.fc15.x86_64", arch: "amd64", family: "unix"

Not sure whether I have tried hard enough to make this build work, but it seems to me it shouldn't be this nearly this hard to begin with. I also see that this has been out for a while, and Google doesn't return a mass outcry of similar build pain from others, so I can't help but think it is something I am missing.

Please Advise, and Thanks in Advance,

-SM

[Rossen Stoyanchev]

You don't need to run the main Ant build to build the samples. You can just use maven for those. As for the primefaces jar, you might need to tweak the version in the pom if the one it was originally built with is no longer available (or the repo has changed). Compare to the latest pom in github.

[smaines]

Actually, I had also cloned from https://github.com/SpringSource/spring-webflow.git and tried to build that, on the reasonable thought that the repository landscape may have shifted under the feet of 2.3.0.RELEASE. It still only builds with -Ddisable.bundlor=true, but the repositories seem OK. As the new visitor is presented with 2.3.0.RELEASE, rather than a release reflecting this new landscape, this undermines both the first impression and confidence in his own environment.

The example runs, if you know to append the name of the sample to the url, i.e. http:/localhost:8080/booking-faces, not simply http://localhost:8080/, which forwards to http://localhost:8080/spring/intro and returns a blank page (lending the appearance that it is trying to work, but is broken).

So, a few bits of strangeness to trap the unwary,

* As downloaded, 2.3.0.RELEASE does not build without tinkering
* Things only build with -Ddisable.bundlor=true (this was my original concern, and I still do not know the ramifications of this, if any)
* The forwarding behavior on viewing http://localhost:8080/ lends the appearance that it is broken
* There is this weird mix of ant and maven, which only works in certain points in the build, and fails in others, even when following readme instructions

I'll close by expressing my gratitude for all the coolness in Webflow, and Spring generally, and my hope that these builds might become more robustly maven, i.e., that it be possible to

$ unzip the-release.zip
$ cd to/the/example
$ mvn tomcat-or-jetty:run

...or...

$ git clone release-url
$ cd to/the/example
$ mvn tomcat-or-jetty:run

...and have all the right things happen. I'm encouraged that it already seems tantalizingly close to this now.

Best Regards,

-SM

[Rossen Stoyanchev]

Actually, I had also cloned from https://github.com/SpringSource/spring-webflow.git and tried to build that, on the reasonable thought that the repository landscape may have shifted under the feet of 2.3.0.RELEASE. It still only builds with -Ddisable.bundlor=true, but the repositories seem OK. As the new visitor is presented with 2.3.0.RELEASE, rather than a release reflecting this new landscape, this undermines both the first impression and confidence in his own environment.

I am not sure why you need to add disable.bundlor. What is the failure? There shouldn't be any implications unless you're using Web Flow in an OSGi environment.

The example runs, if you know to append the name of the sample to the url, i.e. http:/localhost:8080/booking-faces, not simply http://localhost:8080/, which forwards to http://localhost:8080/spring/intro and returns a blank page (lending the appearance that it is trying to work, but is broken).

Strange that entering http://localhost:8080/ for me results in a 404. The index.html page does do a relative forward to "spring/intro". However, to even reach that you need to specify the application context (i.e. /booking-faces). Do you know what's actually doing the forwarding? I.e. how does a request without an application context end up getting processed by the booking-faces web application?

I'll close by expressing my gratitude for all the coolness in Webflow, and Spring generally, and my hope that these builds might become more robustly maven, i.e., that it be possible to

$ unzip the-release.zip
$ cd to/the/example
$ mvn tomcat-or-jetty:run

...or...

$ git clone release-url
$ cd to/the/example
$ mvn tomcat-or-jetty:run

I think the only thing missing is a Tomcat/Jetty maven plugin in the pom.xml of individual samples. Feel free to open a JIRA ticket or even submit a pull request.

A couple more things to note is the samples will probably move out of the distribution and under github.com/SpringSource much like the spring-mvc-showcase. This should help with the above issue of being out of date.

The second thing to mention is that we'll be following up the move by the Spring Framework to switch to a Gradle based build. It should be very easy to build it similar to these instructions https://github.com/SpringSource/spri...mework#readme.

[smaines]

[Sorry, just saw your post today]

I got that disable.bundlor was an OSGi thing, and likely OK to disable: my point was simply that it did not work and seemed to hinge on somehow pulling in an old API- i.e. a build defect. The build somehow tries to compile an asm 3.0+ method call against an asm 1.5.3 jar, unless you define disable.bundlor. See first post. It occurs to me that maybe I didn't scan some jars which might contain the asm packages- bundled in, as it were. Nevertheless, it doesn't build. Perhaps a subtle consequence of a shift in repository topology.

As to the redirect, didn't notice what triggered it, only that it happened. It is probably easy to find. Could be an artifact of unconfigured tomcat/jetty.

Looking forward to your Gradle efforts,

-SM