Re: Using fluido once available

On Wed, Nov 28, 2012 at 8:57 PM, Lukasz Lenart wrote: > Do we have a place where we can deploy a pre-release version of site > to test it ? Maybe just to struts.a.o/next ? I think a people.a.o user directory would do the trick. Cheers Christian > > > Regards > -- > Łukasz > + 48 606 323 122 htt

Re: Plan for Struts 3

On Wed, Nov 28, 2012 at 4:39 PM, Dave Newton wrote: > IMO I'd rather see the internal mechanism be able to evolve and make use of > vetted improvements instead of remaining in the land of Guice of 5+ years > ago. Newer Guice has more capabilities. I would like to mention the new incubator project

Re: Git (Was: Plan for Struts 3)

On Wed, Nov 28, 2012 at 4:42 PM, Christian Grobmeier wrote: > http://nvie.com/posts/a-successful-git-branching-model/ https://github.com/nvie/gitflow Yeah, I like the workflow quite a bit, although I've only used it on a couple of smallish projects. Dave

Re: Git (Was: Plan for Struts 3)

On Wed, Nov 28, 2012 at 8:36 PM, Lukasz Lenart wrote: > 2012/11/28 Rene Gielen : >> Moving development to the Git infrastructure ASF / Infra now provides is >> *not* a no-brainer, and it requires a little bit more than just a few +1s :) >> >> Let's step back, hold breath, and dive into serious dis

Re: Plan for Struts 3

2012/11/28 Chris Pratt : > Would it be possible to write the internal code to use the JSR-330 API and > supply Guice as the default, rather than tying the system directly to > Guice? It seems like there would be an advantage to allowing the internal > and external injections to potentially share a

Re: Plan for Struts 3

2012/11/28 Dave Newton : > We'll always rely on external libraries--and as has been mentioned, > our core competency isn't DI frameworks, nor should it be. Always something new :-) > I'm not sure an XML config layer would be that difficult to build, but > even if it is, wouldn't it be preferable

Re: Plan for Struts 3

Would it be possible to write the internal code to use the JSR-330 API and supply Guice as the default, rather than tying the system directly to Guice? It seems like there would be an advantage to allowing the internal and external injections to potentially share an injection library rather than t

Re: Plan for Struts 3

We'll always rely on external libraries--and as has been mentioned, our core competency isn't DI frameworks, nor should it be. I'm not sure an XML config layer would be that difficult to build, but even if it is, wouldn't it be preferable to use a substantially more-mature DI implementation, which

Re: Using fluido once available

Hi, Do we have a place where we can deploy a pre-release version of site to test it ? Maybe just to struts.a.o/next ? Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@strut

Re: Plan for Struts 3

2012/11/28 Dave Newton : > IMO I'd rather see the internal mechanism be able to evolve and make use of > vetted improvements instead of remaining in the land of Guice of 5+ years > ago. Newer Guice has more capabilities. I thought (and still do) a lot about that and I'm not convinced to replace pr

Re: Git (Was: Plan for Struts 3)

2012/11/28 Rene Gielen : > Moving development to the Git infrastructure ASF / Infra now provides is > *not* a no-brainer, and it requires a little bit more than just a few +1s :) > > Let's step back, hold breath, and dive into serious discussion about > that. I'm preparing a more detailed post, but

Git (Was: Plan for Struts 3)

Folks, I think right at this point we should fork discussion on methodology (Git) from new features as in the rest of this thread. Moving development to the Git infrastructure ASF / Infra now provides is *not* a no-brainer, and it requires a little bit more than just a few +1s :) Let's step back

Re: Plan for Struts 3

Internal means everything consuming the c.o.xwork.Inject annotation and of course the providing mechanism for this one. As a user, even today I would never ever (ok, unless I really know what I'm doing) consume this annotation. And I don't have to, since Spring, Guice and CDI plugin provide me wit

Re: Plan for Struts 3

Can I get some clarification on "internal mechanism"? I may have misspoke; I would like Struts users to use Commons DI over XWork injection. That's something different than the way Struts wires up itself, right? On Wed, Nov 28, 2012 at 9:53 AM, Rene Gielen wrote: > Also I think our core competenc

Re: Plan for Struts 3

Also I think our core competence here at Struts is building web frameworks, not dependency injection frameworks. The original maintainers aren't active any more. The current code is in a state of "don't touch, it might blow up without warning". Fiddling out a memory leak in the DI code lately took

Re: Plan for Struts 3

IMO I'd rather see the internal mechanism be able to evolve and make use of vetted improvements instead of remaining in the land of Guice of 5+ years ago. Newer Guice has more capabilities. Dave On Nov 28, 2012 10:27 AM, "Jeff Black" wrote: > Perhaps I am too old and have been in the consulting

Re: Plan for Struts 3

Perhaps I am too old and have been in the consulting business too long, but to change the internal DI facility -- which is working beautifully -- merely for the sake of changing seems to be an unnecessary risk. My two cents. Jeff From: Rene Gielen To: Strut

Re: Build failed in Jenkins: Struts2-JDK5 » Struts 2 GXP Plugin #4

2012/11/28 Rene Gielen : > Does that mean that it won't be part of future releases? Then we should > be careful with commenting things out here... Yes, but with them project cannot be build on JDK5 EmbeddedJSP uses classes that are available as from JDK6 - there is no way to port it somehow to JD

Jenkins build is back to normal : Struts2-JDK6 #570

See - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org

Re: Plan for Struts 3

Konstantin, you make a valid point that JSR 330 by itself is no solution to our problems with internal injection. As I tried to explain in another post to this thread, we have to differentiate between internal injection and injection abstraction towards user side. As for how to evolve internal in

Re: Plan for Struts 3

You have to differentiate between XWork's internal injection and the injection abstraction towards user code to support pluggable dependency injection implementations. The latter one we surely would not want to drop, and as a matter of fact we are already supporting JSR 330 with the Spring, Guice a

Re: Plan for Struts 3

I have to second Matt here. Even though Struts 3.x is about introducing a platform for breaking changes, we should carefully consider what we actually break. The discussion seems to be a variation of "are we going for 2.5 or 3.0?". Since now there seems to be major support for going 3.0, all the p

Re: Build failed in Jenkins: Struts2-JDK5 » Struts 2 GXP Plugin #4

Does that mean that it won't be part of future releases? Then we should be careful with commenting things out here... Am 22.11.12 10:09, schrieb Lukasz Lenart: > 2012/11/22 Lukasz Lenart : >> Or I can comment them out in plugins pom.xml. > > After commenting out, build is stable. Is it the right

Re: Using fluido once available

Am 27.11.12 22:55, schrieb Johannes Geppert: > It looks there is a broad agreement related to the projects links and the > Roadmap FAQ. > So i have dropped it from the site. > > Also I have added a Facebook and G+ Integration beside the Twitter > Integration. > Looks like this is our current News

Re: Plan for Struts 3

Hi guys, JSR 330 is cool and shall be definitely supported  -   but you still need fallback metadata mechanism. Drawback of annotatioj is that it is class bound,   and thus you can not  have two of something without subclassing.  Neither can you  reconfigure classes coming as jar dependency.  J