The test referenced classes that had moved, with a little juggling, I got
it all to work.
On Mon, Dec 29, 2014 at 6:03 AM, Lance Java
wrote:
> Educated stab in the dark here but does ClasspathScannerImpl assume each
> package is contained within a single jar?
>
> I'm guessing Thiago's changes in
Educated stab in the dark here but does ClasspathScannerImpl assume each
package is contained within a single jar?
I'm guessing Thiago's changes involved splitting a single package across 2
(maybe 3) jars to maintain backwards compatibility.
On 23 Dec 2014 23:00, "Howard Lewis Ship" wrote:
> I'm
I'm doing a build of latest, currently. Seeing one oddity:
ioc.specs.ClasspathScannerImplSpec > can locate classes inside a
subpackage, inside an extracted JAR file FAILED
org.spockframework.runtime.ConditionNotSatisfiedError at
ClasspathScannerImplSpec.groovy:40
708 tests completed, 1 faile
I have to admit that I didn't have a chance to look into the changes you
made yet, and probably, I won't get to doing that until 2015.
But a new beta would be a good way to make more people (including me) give
them a try in the near future, so I'd say, just go ahead. :-)
On Sun, 07 Dec 2014 00:49:23 -0200, Thiago H de Paula Figueiredo
wrote:
All this work was done on the 'beanmodel-split' branch. I invite
everyone to take a look and all feedback, constructive or destructive,
will be most welcome. If no one objects in the next couple of weeks,
I'll merge
interesting. I think if we had access to Gradle and Git longer in the past,
we would have seen Tapestry as more small libraries in the first place.
Certainly that's the approach I've been taking in my Clojure efforts.
On Saturday, December 6, 2014, Thiago H de Paula Figueiredo <
thi...@arsmachina.
Hi!
As I've mentioned some time ago, I realized the BeanModel classes from
tapestry-core would an awesome, easy-to-use, fast Java property reflection
library if it was a library of its own, specially POJO mapping and binding
ones like JAXB or Jackson. That's what I did today. ;)
All this
