Fix lift-archetype-jpa-basic #52

Closed
indrajitr opened this Issue Aug 24, 2009 · 11 comments

Projects

None yet

3 participants

@indrajitr
Member

Ref: http://groups.google.com/group/liftweb/browse_thread/thread/c932dd45c70094ca

Issues:

  1. Velocity is unhappy and spewing warnings
  2. mvn install fails after archetype being created

Diagnosis:

  1. #1 Happens because vm variables don't resolve appropriately during archetype:generate
  2. #2 Happens likely because scala.version is set to 2.7.4 in pom.xml (unlikely to be main reason).
  3. LiftRules.localeCalculator is now of type Box[HTTPRequest] => Locale in snapshot instead of Box[HttpServletRequest] => Locale in 1.1-M4

Solutions:
Fix archetype-resources to look like those in lift-archetype-basic.
Specifically:

  1. In ext.vm set(...) should be prepended with '#' to look like #set(...)
  2. Update pom.xml with the lines (somewhere at the top, before vm encounters ${} resolution)
    #set($sv = '${scala.version}')
    #parse('ext.vm')
  3. While at this, would be good to have the jetty version range fixed to [6.1.6,7.0)
  4. Either fix Boot.localeCalculator to honor the new signature in the SNAPSHOT or set lift-core dependency to 1.1-M4 in the lift-archetype-jpa-basic resource web/pom.xml in the interim till Boot.localeCalculator is fixed.
@timperrett
Collaborator

JPA archetypes updated and velocity no longer complains. Thanks for the comprehensive issue submission. I've also locked down the jetty version.

@indrajitr
Member

Umm, lift-archetype-basic has:
[6.1.6, 6.1.19)

whereas lift-archetype-jpa-basic has:
(6.1.6,6.1.19]

We probably don't mean both of them together :)

I haven't found the test cases to fail either with 6.1.6 or 6.1.9, so why exclude them? We should be fine with [6.1.6,7.0) so that all 6.x series is supported but none of 7.x is.

See: http://is.gd/2zokO for Maven's spec.

@timperrett
Collaborator

oops... corrected and committed.

@indrajitr
Member

Yay! Thanks Tim.
BTW, would love to know your/Lift team's though on the [6.1.6,7.0) part. Specifically, on excluding jetty 6.1.19 for testing.

@timperrett
Collaborator

What do you mean excluding jetty 6.1.19? Can you be a little more concise so I can understand what we need to talk about :-)

@indrajitr
Member

With the current setting [6.1.6, 6.1.19), the latest version 6.1.19 of jetty is not used. I was curious to know if there is any specific reason why jetty version 6.1.19 is excluded from the version range for test scope.

@indrajitr
Member

Tim, Just wondering if I could clarify myself ...

@timperrett
Collaborator

Hey, to be honest there is no real good answer or reason... from memory it was just something we decided on at the time when stuff started to break with jetty 7.0 and perhaps it was a miss-understanding of the maven version range configuration. Like I said... no real good answer! What are we loosing by inadvertently excluding 6.1.19? (im no jetty expert)

@indrajitr
Member

I think jetty 7.0 had to be excluded because the package has changed (org.eclipse.*). But in the process, the version range got bit more aggressive and excluded everything after 6.1.18 which might not have been necessary in the first place.

Practically speaking, nothing much is lost by excluding 6.1.19 in particular. But in effect we are missing out on the entire set of incremental versions on 6.x series (6.1.20, 6.1.21 etc.) as and when they appear. I don't know if that would make a big difference at a later point of time. But a flexible version range in frameworks help reduce 'downloading the internet syndrome' to an extent for maven :D

It's not a show stopper at the moment and there isn't any burning need for change. Just was curious if anything other than 7.0 breakage was the reason. Looks like there isn't.

@timperrett timperrett was assigned Mar 1, 2012
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment