You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Lukasz Lenart <lu...@apache.org> on 2012/11/22 09:11:31 UTC
Plan for Struts 3
Hi,
I've prepared a simple plan to start working on Struts 3 which is
available here [1]
Request Git repo from INFRA
Import project
Remove deprecated plugins
Remove deprecated APIs
Switch to Java 1.6
Rename XWork packages to org.apache.struts.xwork
Rename Struts 2 packages to org.apache.struts ?
Prepare the first release
[1] https://cwiki.apache.org/confluence/display/WW/Struts+3
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Paul Benedict <pb...@apache.org>.
No, I support dropping the plugin. I was only echoing the previous point,
which was the S1 plugin gives you very limited S1 reuse -- you get the
actions but not the taglibs.
On Tue, Nov 27, 2012 at 2:56 PM, Lukasz Lenart <lu...@apache.org>wrote:
> 2012/11/27 Paul Benedict <pb...@apache.org>:
> > Lukasz, you can... but the S1 plugin allows people to forgo the S1 jar.
> You
> > don't gain much in terms of the presentation layer since you can't use
> the
> > S1 taglibs anymore, but the S1 action can still be called.
>
> So you mean we should keep support for S1 in S3 ? And use
> org.apache.struts3 ? I don't think we can keep support for S1 and use
> org.apache.struts as a base package name
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/27 Paul Benedict <pb...@apache.org>:
> Lukasz, you can... but the S1 plugin allows people to forgo the S1 jar. You
> don't gain much in terms of the presentation layer since you can't use the
> S1 taglibs anymore, but the S1 action can still be called.
So you mean we should keep support for S1 in S3 ? And use
org.apache.struts3 ? I don't think we can keep support for S1 and use
org.apache.struts as a base package name
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Paul Benedict <pb...@apache.org>.
Lukasz, you can... but the S1 plugin allows people to forgo the S1 jar. You
don't gain much in terms of the presentation layer since you can't use the
S1 taglibs anymore, but the S1 action can still be called.
Paul
On Tue, Nov 27, 2012 at 12:44 AM, Lukasz Lenart <lu...@apache.org>wrote:
> 2012/11/26 Dave Newton <da...@gmail.com>:
> > I have no problem with that. (Obviously ;)
> >
> > IMO the S1 plugin was never anything more than a stopgap measure;
> > since JSPs had to be rewritten anyway it was more of a temporary
> > solution during migration.
>
> Really? I thought you can run S1 application with S2 just out of the
> box, without any changes to it. It doesn't make sense to support S1,
> though.
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/26 Dave Newton <da...@gmail.com>:
> I have no problem with that. (Obviously ;)
>
> IMO the S1 plugin was never anything more than a stopgap measure;
> since JSPs had to be rewritten anyway it was more of a temporary
> solution during migration.
Really? I thought you can run S1 application with S2 just out of the
box, without any changes to it. It doesn't make sense to support S1,
though.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/26 Ken McWilliams <ke...@gmail.com>:
> How hard would it be to "allow for" struts run time configuration? In
> allowing for I mean having a registry for the configuration of interceptor
> stacks, packages, actions... which the framework will allow for querying
> and in the default case would be immutable but would allow us to substitute
> in mutable managers for these configuration services? One use-case is to
> produce a struts2(struts3) IDE which runs in a browser.
I don't know what you mean by "allow for" - there is already runtime
configuration build from xml, annotation and convention. You can view
it with the Config Browser plugin, in DevMode if something changes,
the configuration will be reloaded automatically.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Ken McWilliams <ke...@gmail.com>.
How hard would it be to "allow for" struts run time configuration? In
allowing for I mean having a registry for the configuration of interceptor
stacks, packages, actions... which the framework will allow for querying
and in the default case would be immutable but would allow us to substitute
in mutable managers for these configuration services? One use-case is to
produce a struts2(struts3) IDE which runs in a browser.
On Mon, Nov 26, 2012 at 1:24 PM, Dave Newton <da...@gmail.com> wrote:
> I have no problem with that. (Obviously ;)
>
> IMO the S1 plugin was never anything more than a stopgap measure;
> since JSPs had to be rewritten anyway it was more of a temporary
> solution during migration.
>
> Dave
>
> On Mon, Nov 26, 2012 at 3:21 PM, Lukasz Lenart <lu...@apache.org>
> wrote:
> > 2012/11/22 Lukasz Lenart <lu...@apache.org>:
> >> 2012/11/22 Dave Newton <da...@gmail.com>:
> >>> How useful is the Struts 1 plugin?
> >>
> >> It's mentioned as a migration way for S1 projects, but we can drop
> >> support for S1 in S3
> >
> > Any thoughts? I'm almost sure that we should drop support for S1 in S3
> > and used org.apache.struts as a base package name.
> >
> >
> > Regards
> > --
> > Łukasz
> > + 48 606 323 122 http://www.lenart.org.pl/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
>
> --
> e: davelnewton@gmail.com
> m: 908-380-8699
> s: davelnewton_skype
> t: @dave_newton
> b: Bucky Bits
> g: davelnewton
> so: Dave Newton
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Plan for Struts 3
Posted by Dave Newton <da...@gmail.com>.
I have no problem with that. (Obviously ;)
IMO the S1 plugin was never anything more than a stopgap measure;
since JSPs had to be rewritten anyway it was more of a temporary
solution during migration.
Dave
On Mon, Nov 26, 2012 at 3:21 PM, Lukasz Lenart <lu...@apache.org> wrote:
> 2012/11/22 Lukasz Lenart <lu...@apache.org>:
>> 2012/11/22 Dave Newton <da...@gmail.com>:
>>> How useful is the Struts 1 plugin?
>>
>> It's mentioned as a migration way for S1 projects, but we can drop
>> support for S1 in S3
>
> Any thoughts? I'm almost sure that we should drop support for S1 in S3
> and used org.apache.struts as a base package name.
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
e: davelnewton@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton
b: Bucky Bits
g: davelnewton
so: Dave Newton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/22 Lukasz Lenart <lu...@apache.org>:
> 2012/11/22 Dave Newton <da...@gmail.com>:
>> How useful is the Struts 1 plugin?
>
> It's mentioned as a migration way for S1 projects, but we can drop
> support for S1 in S3
Any thoughts? I'm almost sure that we should drop support for S1 in S3
and used org.apache.struts as a base package name.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Rene Gielen <rg...@apache.org>.
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
problems arise that have existed in the first place when we chose the
magic 2 both for package naming and branding.
That said, I'd vote for the following interpretation: From a higher
level, Struts 2 is a brand with the 2 pointing to an architectural
level. One could argue that we will be releasing version 3.x of the
Struts 2 architecture. That said, it won't be too confusing if struts2
stays as part of the package naming where it was used so far. And if it
isn't confusing people, I see no real need to change it. Without an
obvious need to change naming, we should not do it and intentionally
break our users' code.
With XWork it is way around. Since XWork is now part of the Struts
project, com.opensymphony package names are really confusing. Though I
hate breaking changes as much as most of us do, I'm all for doing it
right now with the advent of Struts 3.x - that is, renaming it to
org.apache.struts.xwork. The clarification here is arguably worth the
pain we will cause users migrating to Struts 3.x.
- René
Am 27.11.12 23:59, schrieb Matt Raible:
> If it breaks backwards-compatibility, I'd suggest not doing it. I've always been impressed with projects like Spring that've maintained backwards compatibility w/o making a breaking change such as this.
>
> On Nov 27, 2012, at 3:54 PM, Jeff Black <je...@yahoo.com> wrote:
>
>> Never mind.
>>
>> I suppose it makes sense to some extent; however I'm with Dave when it comes to incorporating the version number in the package name.
>>
>> Just my two cents.
>>
>>
>>
>> ________________________________
>> From: Jeff Black <je...@yahoo.com>
>> To: Struts Developers List <de...@struts.apache.org>
>> Sent: Tuesday, November 27, 2012 4:50 PM
>> Subject: Re: Plan for Struts 3
>>
>> Is it really necessary to alter the package name?
>>
>>
>>
>> ________________________________
>> From: Lukasz Lenart <lu...@apache.org>
>> To: Struts Developers List <de...@struts.apache.org>
>> Sent: Thursday, November 22, 2012 5:35 AM
>> Subject: Re: Plan for Struts 3
>>
>> 2012/11/22 Dave Newton <da...@gmail.com>:
>>> How useful is the Struts 1 plugin?
>>
>> It's mentioned as a migration way for S1 projects, but we can drop
>> support for S1 in S3
>>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
René Gielen
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Rene Gielen <rg...@apache.org>.
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 and CDI plugins.
As for internal injection, the question is not so much whether we would
want to switch to JSR 330 but rather to what actual injector
implementation. That is, stay with the baked in pre-release Guice code
or switch to an externally maintained framework such as Guice 3. If we'd
go for that, we'd automatically introduce JSR 330 into our internal
injection mechanism.
If we go for replacing the internal injector, there isn't actually too
much choice - Guice or Guice seem to be the options - or, if we feel
adventurous enough, maybe Dagger :) Spring as most widely used
alternative is too heavy-weight. Also, since our internal framework *is*
actually early Guice, some core concepts of how things are implemented
now would have a natural mapping.
I've looked into this task for quite some time now and I can confirm
that this is not trivial. The internal injector is not easy to fiddle
out and replace, but I'm all for giving it a try once we have started
creating the 3.0 code base. As for the Struts 2.x line, the risk was way
too high to touch the injection mechanism while keeping the framework
stable. Only now there is a chance to get hands dirty on this one :)
Am 28.11.12 07:43, schrieb Paul Benedict:
> What about dropping XWork injection support for JSR 330 (Commons DI)?
>
> On Wed, Nov 28, 2012 at 12:41 AM, Lukasz Lenart <lu...@apache.org>wrote:
>
>> I've updated the plan :-)
>>
>> Request Git repo from INFRA
>> Import project
>> Remove deprecated plugins
>> Drop support for Struts 1 (remove plugin)
>> Remove deprecated APIs
>> Switch to Java 1.6
>> Rename XWork packages to org.apache.struts.xwork
>> Rename Struts 2 packages to org.apache.struts
>> Prepare the first release
>>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
--
René Gielen
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Rene Gielen <gi...@it-neering.net>.
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 with javax.inject support within my
actions or interceptors.
Am 28.11.12 16:58, schrieb Paul Benedict:
> 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 <gi...@it-neering.net> wrote:
>> 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 me ages. The fix actually was a three
>> liner, but understanding the possible impact and evaluating the risks
>> was ... let's put it that way ... an experience.
>>
>> For that reason improvements on the DI abstraction layer are hard as
>> well. Modern containers such as Weld / CDI have more sophistiocated
>> lifecycle models which we could support in our abstraction layer, if
>> only we were able to map it to the underlying mechanism. I see hard work
>> coming up to advance on that topic with the current hand-rolled injector.
>>
>> But nevertheless - it works, fair enough. To decide whether we are doing
>> something worthy with a switch to Guice we need to give it a try (and of
>> course volunteers willing to give it a try). The 3.x fork would be the
>> perfect playground I guess.
>>
>> - René
>>
>> Am 28.11.12 16:39, schrieb 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.
>>>
>>> Dave
>>> On Nov 28, 2012 10:27 AM, "Jeff Black" <je...@yahoo.com> wrote:
>>>
>>>> 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 <gi...@it-neering.net>
>>>> To: Struts Developers List <de...@struts.apache.org>
>>>> Sent: Wednesday, November 28, 2012 3:58 AM
>>>> Subject: 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 injection, integrating Guice would be the
>>>> option to go. Your points about the limits of class bound annotations
>>>> are valid, and that is why we have to decide for a concrete DI
>>>> implementation rather than a standard (though it is nice if it
>>>> introduces a standard on it's back). This is why Guice would make sense,
>>>> since it would support our mechanism of offering configuration options
>>>> apart from classes, via property injection and binding configuration
>>>> done in struts.xml, so without the need for DI framework specific
>>>> configuration files besides our own config.
>>>>
>>>> - René
>>>>
>>>> Am 28.11.12 09:01, schrieb Konstantin Priblouda:
>>>>> 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.
>>>>>
>>>>> Just EUR 0.02 from picocontainer developer.
>>>>>
>>>>> regadrs,
>>>>>
>>>>> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
>>>>> JTec quality components: http://www.pribluda.de/projects/
>>>>>
>>>>>
>>>>> ________________________________
>>>>> From: Paul Benedict <pb...@apache.org>
>>>>> To: Struts Developers List <de...@struts.apache.org>
>>>>> Sent: Wednesday, November 28, 2012 8:31 AM
>>>>> Subject: Re: Plan for Struts 3
>>>>>
>>>>> Well I know that XWork had its only dependency injection support, but now
>>>>> that Java has a standard dependency injection mechanism, we should
>>>>> definitely go with that. Also it keeps on getting developed with each new
>>>>> EE so it's something we should support as a first-class citizen.
>>>>>
>>>>> On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lukaszlenart@apache.org
>>>>> wrote:
>>>>>
>>>>>> 2012/11/28 Paul Benedict <pb...@apache.org>:
>>>>>>> What about dropping XWork injection support for JSR 330 (Commons DI)?
>>>>>>
>>>>>> You mean what we have now and use Guice as an internal DI mechanism ?
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> --
>>>>>> Łukasz
>>>>>> + 48 606 323 122 http://www.lenart.org.pl/
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> René Gielen
>>>> IT-Neering.net
>>>> Saarstrasse 100, 52062 Aachen, Germany
>>>> Tel: +49-(0)241-4010770
>>>> Fax: +49-(0)241-4010771
>>>> Cel: +49-(0)163-2844164
>>>> http://twitter.com/rgielen
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>> --
>> René Gielen
>> IT-Neering.net
>> Saarstrasse 100, 52062 Aachen, Germany
>> Tel: +49-(0)241-4010770
>> Fax: +49-(0)241-4010771
>> Cel: +49-(0)163-2844164
>> http://twitter.com/rgielen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)163-2844164
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Paul Benedict <pb...@apache.org>.
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 <gi...@it-neering.net> wrote:
> 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 me ages. The fix actually was a three
> liner, but understanding the possible impact and evaluating the risks
> was ... let's put it that way ... an experience.
>
> For that reason improvements on the DI abstraction layer are hard as
> well. Modern containers such as Weld / CDI have more sophistiocated
> lifecycle models which we could support in our abstraction layer, if
> only we were able to map it to the underlying mechanism. I see hard work
> coming up to advance on that topic with the current hand-rolled injector.
>
> But nevertheless - it works, fair enough. To decide whether we are doing
> something worthy with a switch to Guice we need to give it a try (and of
> course volunteers willing to give it a try). The 3.x fork would be the
> perfect playground I guess.
>
> - René
>
> Am 28.11.12 16:39, schrieb 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.
>>
>> Dave
>> On Nov 28, 2012 10:27 AM, "Jeff Black" <je...@yahoo.com> wrote:
>>
>>> 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 <gi...@it-neering.net>
>>> To: Struts Developers List <de...@struts.apache.org>
>>> Sent: Wednesday, November 28, 2012 3:58 AM
>>> Subject: 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 injection, integrating Guice would be the
>>> option to go. Your points about the limits of class bound annotations
>>> are valid, and that is why we have to decide for a concrete DI
>>> implementation rather than a standard (though it is nice if it
>>> introduces a standard on it's back). This is why Guice would make sense,
>>> since it would support our mechanism of offering configuration options
>>> apart from classes, via property injection and binding configuration
>>> done in struts.xml, so without the need for DI framework specific
>>> configuration files besides our own config.
>>>
>>> - René
>>>
>>> Am 28.11.12 09:01, schrieb Konstantin Priblouda:
>>>> 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.
>>>>
>>>> Just EUR 0.02 from picocontainer developer.
>>>>
>>>> regadrs,
>>>>
>>>> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
>>>> JTec quality components: http://www.pribluda.de/projects/
>>>>
>>>>
>>>> ________________________________
>>>> From: Paul Benedict <pb...@apache.org>
>>>> To: Struts Developers List <de...@struts.apache.org>
>>>> Sent: Wednesday, November 28, 2012 8:31 AM
>>>> Subject: Re: Plan for Struts 3
>>>>
>>>> Well I know that XWork had its only dependency injection support, but now
>>>> that Java has a standard dependency injection mechanism, we should
>>>> definitely go with that. Also it keeps on getting developed with each new
>>>> EE so it's something we should support as a first-class citizen.
>>>>
>>>> On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lukaszlenart@apache.org
>>>> wrote:
>>>>
>>>>> 2012/11/28 Paul Benedict <pb...@apache.org>:
>>>>>> What about dropping XWork injection support for JSR 330 (Commons DI)?
>>>>>
>>>>> You mean what we have now and use Guice as an internal DI mechanism ?
>>>>>
>>>>>
>>>>> Regards
>>>>> --
>>>>> Łukasz
>>>>> + 48 606 323 122 http://www.lenart.org.pl/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>
>>> --
>>> René Gielen
>>> IT-Neering.net
>>> Saarstrasse 100, 52062 Aachen, Germany
>>> Tel: +49-(0)241-4010770
>>> Fax: +49-(0)241-4010771
>>> Cel: +49-(0)163-2844164
>>> http://twitter.com/rgielen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> --
> René Gielen
> IT-Neering.net
> Saarstrasse 100, 52062 Aachen, Germany
> Tel: +49-(0)241-4010770
> Fax: +49-(0)241-4010771
> Cel: +49-(0)163-2844164
> http://twitter.com/rgielen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/28 Chris Pratt <th...@gmail.com>:
> 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 taking up twice the memory to do the same thing.
Probably yes, but I'm not sure - that's the another concern I have
regarding introducing new internal DI (Guice)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Chris Pratt <th...@gmail.com>.
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 taking up twice the memory to do the same thing.
(*Chris*)
On Wed, Nov 28, 2012 at 7:53 AM, Rene Gielen <gi...@it-neering.net> wrote:
> 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 me ages. The fix actually was a three
> liner, but understanding the possible impact and evaluating the risks
> was ... let's put it that way ... an experience.
>
> For that reason improvements on the DI abstraction layer are hard as
> well. Modern containers such as Weld / CDI have more sophistiocated
> lifecycle models which we could support in our abstraction layer, if
> only we were able to map it to the underlying mechanism. I see hard work
> coming up to advance on that topic with the current hand-rolled injector.
>
> But nevertheless - it works, fair enough. To decide whether we are doing
> something worthy with a switch to Guice we need to give it a try (and of
> course volunteers willing to give it a try). The 3.x fork would be the
> perfect playground I guess.
>
> - René
>
> Am 28.11.12 16:39, schrieb 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.
> >
> > Dave
> > On Nov 28, 2012 10:27 AM, "Jeff Black" <je...@yahoo.com> wrote:
> >
> >> 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 <gi...@it-neering.net>
> >> To: Struts Developers List <de...@struts.apache.org>
> >> Sent: Wednesday, November 28, 2012 3:58 AM
> >> Subject: 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 injection, integrating Guice would be the
> >> option to go. Your points about the limits of class bound annotations
> >> are valid, and that is why we have to decide for a concrete DI
> >> implementation rather than a standard (though it is nice if it
> >> introduces a standard on it's back). This is why Guice would make sense,
> >> since it would support our mechanism of offering configuration options
> >> apart from classes, via property injection and binding configuration
> >> done in struts.xml, so without the need for DI framework specific
> >> configuration files besides our own config.
> >>
> >> - René
> >>
> >> Am 28.11.12 09:01, schrieb Konstantin Priblouda:
> >>> 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.
> >>>
> >>> Just EUR 0.02 from picocontainer developer.
> >>>
> >>> regadrs,
> >>>
> >>> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> >>> JTec quality components: http://www.pribluda.de/projects/
> >>>
> >>>
> >>> ________________________________
> >>> From: Paul Benedict <pb...@apache.org>
> >>> To: Struts Developers List <de...@struts.apache.org>
> >>> Sent: Wednesday, November 28, 2012 8:31 AM
> >>> Subject: Re: Plan for Struts 3
> >>>
> >>> Well I know that XWork had its only dependency injection support, but
> now
> >>> that Java has a standard dependency injection mechanism, we should
> >>> definitely go with that. Also it keeps on getting developed with each
> new
> >>> EE so it's something we should support as a first-class citizen.
> >>>
> >>> On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <
> lukaszlenart@apache.org
> >>> wrote:
> >>>
> >>>> 2012/11/28 Paul Benedict <pb...@apache.org>:
> >>>>> What about dropping XWork injection support for JSR 330 (Commons DI)?
> >>>>
> >>>> You mean what we have now and use Guice as an internal DI mechanism ?
> >>>>
> >>>>
> >>>> Regards
> >>>> --
> >>>> Łukasz
> >>>> + 48 606 323 122 http://www.lenart.org.pl/
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>
> >> --
> >> René Gielen
> >> IT-Neering.net
> >> Saarstrasse 100, 52062 Aachen, Germany
> >> Tel: +49-(0)241-4010770
> >> Fax: +49-(0)241-4010771
> >> Cel: +49-(0)163-2844164
> >> http://twitter.com/rgielen
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> --
> René Gielen
> IT-Neering.net
> Saarstrasse 100, 52062 Aachen, Germany
> Tel: +49-(0)241-4010770
> Fax: +49-(0)241-4010771
> Cel: +49-(0)163-2844164
> http://twitter.com/rgielen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Plan for Struts 3
Posted by Rene Gielen <gi...@it-neering.net>.
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 me ages. The fix actually was a three
liner, but understanding the possible impact and evaluating the risks
was ... let's put it that way ... an experience.
For that reason improvements on the DI abstraction layer are hard as
well. Modern containers such as Weld / CDI have more sophistiocated
lifecycle models which we could support in our abstraction layer, if
only we were able to map it to the underlying mechanism. I see hard work
coming up to advance on that topic with the current hand-rolled injector.
But nevertheless - it works, fair enough. To decide whether we are doing
something worthy with a switch to Guice we need to give it a try (and of
course volunteers willing to give it a try). The 3.x fork would be the
perfect playground I guess.
- René
Am 28.11.12 16:39, schrieb 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.
>
> Dave
> On Nov 28, 2012 10:27 AM, "Jeff Black" <je...@yahoo.com> wrote:
>
>> 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 <gi...@it-neering.net>
>> To: Struts Developers List <de...@struts.apache.org>
>> Sent: Wednesday, November 28, 2012 3:58 AM
>> Subject: 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 injection, integrating Guice would be the
>> option to go. Your points about the limits of class bound annotations
>> are valid, and that is why we have to decide for a concrete DI
>> implementation rather than a standard (though it is nice if it
>> introduces a standard on it's back). This is why Guice would make sense,
>> since it would support our mechanism of offering configuration options
>> apart from classes, via property injection and binding configuration
>> done in struts.xml, so without the need for DI framework specific
>> configuration files besides our own config.
>>
>> - René
>>
>> Am 28.11.12 09:01, schrieb Konstantin Priblouda:
>>> 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.
>>>
>>> Just EUR 0.02 from picocontainer developer.
>>>
>>> regadrs,
>>>
>>> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
>>> JTec quality components: http://www.pribluda.de/projects/
>>>
>>>
>>> ________________________________
>>> From: Paul Benedict <pb...@apache.org>
>>> To: Struts Developers List <de...@struts.apache.org>
>>> Sent: Wednesday, November 28, 2012 8:31 AM
>>> Subject: Re: Plan for Struts 3
>>>
>>> Well I know that XWork had its only dependency injection support, but now
>>> that Java has a standard dependency injection mechanism, we should
>>> definitely go with that. Also it keeps on getting developed with each new
>>> EE so it's something we should support as a first-class citizen.
>>>
>>> On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lukaszlenart@apache.org
>>> wrote:
>>>
>>>> 2012/11/28 Paul Benedict <pb...@apache.org>:
>>>>> What about dropping XWork injection support for JSR 330 (Commons DI)?
>>>>
>>>> You mean what we have now and use Guice as an internal DI mechanism ?
>>>>
>>>>
>>>> Regards
>>>> --
>>>> Łukasz
>>>> + 48 606 323 122 http://www.lenart.org.pl/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>
>> --
>> René Gielen
>> IT-Neering.net
>> Saarstrasse 100, 52062 Aachen, Germany
>> Tel: +49-(0)241-4010770
>> Fax: +49-(0)241-4010771
>> Cel: +49-(0)163-2844164
>> http://twitter.com/rgielen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)163-2844164
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/12/19 <um...@gmail.com>:
> By support for bean validation did you mean to provide it with core or by some sort of plugin.
Plugin is a better option as always :-)
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by um...@gmail.com.
By support for bean validation did you mean to provide it with core or by some sort of plugin.
Sent from BlackBerry® on Airtel
-----Original Message-----
From: Lukasz Lenart <lu...@apache.org>
Date: Wed, 19 Dec 2012 15:28:09
To: Struts Developers List<de...@struts.apache.org>
Reply-To: "Struts Developers List" <de...@struts.apache.org>
Subject: Re: Plan for Struts 3
This is already done with new filters
https://cwiki.apache.org/confluence/display/S2WIKI/Better+filter+strategy
Regarding OSGi there is a plugin already which fills the requirements,
but it seems to be not used, just one issues was requested as I
remember
https://cwiki.apache.org/confluence/display/S2WIKI/Struts+2.5+Based+on+OSGi
Have support for Bean Validation Spec would be nice and also use Guice
3.0 as an internal DI
https://cwiki.apache.org/confluence/display/S2WIKI/2.1+to+2.5+Roadmap
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
This is already done with new filters
https://cwiki.apache.org/confluence/display/S2WIKI/Better+filter+strategy
Regarding OSGi there is a plugin already which fills the requirements,
but it seems to be not used, just one issues was requested as I
remember
https://cwiki.apache.org/confluence/display/S2WIKI/Struts+2.5+Based+on+OSGi
Have support for Bean Validation Spec would be nice and also use Guice
3.0 as an internal DI
https://cwiki.apache.org/confluence/display/S2WIKI/2.1+to+2.5+Roadmap
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Umesh Awasthi <um...@gmail.com>.
I was looking for this page from some time, since read about *Reworked
localization* there
Do any one have idea about it?
Thanks
Umesh
On Thu, Nov 29, 2012 at 3:58 PM, Christian Grobmeier <gr...@gmail.com>wrote:
> On Thu, Nov 29, 2012 at 11:14 AM, Lukasz Lenart <lu...@apache.org>
> wrote:
> > Hi,
> >
> > I found that [1], what do think about the proposed proposals ?
> >
> > [1] https://cwiki.apache.org/confluence/display/S2WIKI/Proposals
>
> Definitely the OSGi thing would draw some attraction. I like this
> proposal. If users are not *forced* to use OSGi, this might be cool.
> But to be honest, I am not an OSGi expert. I followed a talk at
> ApacheCon EU which left me divided. It looked so easy, but I think it
> isn't.
> Another thought, we have Apache Felix and Karaf. We could look at
> Apache Sling. That might help us, or not.
>
> Besides all the OSGi things - deploying just a JAR file at runtime
> without pain is definitely something I would love for my app. On the
> other hand, an App restart (in my case) is pretty quick.
>
> Cheers
> Christian
>
> >
> >
> > Regards
> > --
> > Łukasz
> > + 48 606 323 122 http://www.lenart.org.pl/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
With Regards
Umesh Awasthi
http://www.travellingrants.com/
Re: Plan for Struts 3
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, Nov 29, 2012 at 11:14 AM, Lukasz Lenart <lu...@apache.org> wrote:
> Hi,
>
> I found that [1], what do think about the proposed proposals ?
>
> [1] https://cwiki.apache.org/confluence/display/S2WIKI/Proposals
Definitely the OSGi thing would draw some attraction. I like this
proposal. If users are not *forced* to use OSGi, this might be cool.
But to be honest, I am not an OSGi expert. I followed a talk at
ApacheCon EU which left me divided. It looked so easy, but I think it
isn't.
Another thought, we have Apache Felix and Karaf. We could look at
Apache Sling. That might help us, or not.
Besides all the OSGi things - deploying just a JAR file at runtime
without pain is definitely something I would love for my app. On the
other hand, an App restart (in my case) is pretty quick.
Cheers
Christian
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
Hi,
I found that [1], what do think about the proposed proposals ?
[1] https://cwiki.apache.org/confluence/display/S2WIKI/Proposals
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Christian Grobmeier <gr...@gmail.com>.
On Wed, Nov 28, 2012 at 4:39 PM, Dave Newton <da...@gmail.com> 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 Onami:
http://onami.incubator.apache.org
It is focusing on Guice components - I see some synergy here. And a
few of the components are really cool.
Cheers
Christian
> Dave
> On Nov 28, 2012 10:27 AM, "Jeff Black" <je...@yahoo.com> wrote:
>
>> 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 <gi...@it-neering.net>
>> To: Struts Developers List <de...@struts.apache.org>
>> Sent: Wednesday, November 28, 2012 3:58 AM
>> Subject: 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 injection, integrating Guice would be the
>> option to go. Your points about the limits of class bound annotations
>> are valid, and that is why we have to decide for a concrete DI
>> implementation rather than a standard (though it is nice if it
>> introduces a standard on it's back). This is why Guice would make sense,
>> since it would support our mechanism of offering configuration options
>> apart from classes, via property injection and binding configuration
>> done in struts.xml, so without the need for DI framework specific
>> configuration files besides our own config.
>>
>> - René
>>
>> Am 28.11.12 09:01, schrieb Konstantin Priblouda:
>> > 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.
>> >
>> > Just EUR 0.02 from picocontainer developer.
>> >
>> > regadrs,
>> >
>> > ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
>> > JTec quality components: http://www.pribluda.de/projects/
>> >
>> >
>> > ________________________________
>> > From: Paul Benedict <pb...@apache.org>
>> > To: Struts Developers List <de...@struts.apache.org>
>> > Sent: Wednesday, November 28, 2012 8:31 AM
>> > Subject: Re: Plan for Struts 3
>> >
>> > Well I know that XWork had its only dependency injection support, but now
>> > that Java has a standard dependency injection mechanism, we should
>> > definitely go with that. Also it keeps on getting developed with each new
>> > EE so it's something we should support as a first-class citizen.
>> >
>> > On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lukaszlenart@apache.org
>> >wrote:
>> >
>> >> 2012/11/28 Paul Benedict <pb...@apache.org>:
>> >>> What about dropping XWork injection support for JSR 330 (Commons DI)?
>> >>
>> >> You mean what we have now and use Guice as an internal DI mechanism ?
>> >>
>> >>
>> >> Regards
>> >> --
>> >> Łukasz
>> >> + 48 606 323 122 http://www.lenart.org.pl/
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>>
>> --
>> René Gielen
>> IT-Neering.net
>> Saarstrasse 100, 52062 Aachen, Germany
>> Tel: +49-(0)241-4010770
>> Fax: +49-(0)241-4010771
>> Cel: +49-(0)163-2844164
>> http://twitter.com/rgielen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/28 Dave Newton <da...@gmail.com>:
> 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 to use a substantially
> more-mature DI implementation, which more support of more
> functionality than the old, half-baked and hacked one we're using now?
There is one already [1], but again it's another external dependency.
The current internal DI is well mature, just one problem for several
years is not so bad IMHO ;-) Anyway I'm a bit terrify if the new Guice
allow us for all that magic we have right now - and at least keep the
current configuration files to be in line with a new DI.
[1] http://code.google.com/p/guice-xml-config/
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Dave Newton <da...@gmail.com>.
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 more support of more
functionality than the old, half-baked and hacked one we're using now?
Dave
On Wed, Nov 28, 2012 at 2:50 PM, Lukasz Lenart <lu...@apache.org> wrote:
> 2012/11/28 Dave Newton <da...@gmail.com>:
>> 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 pre-Guice with Guice - the current version of Guice misses
> alot of features (eg. no support for xml based configuration). Other
> issue is that the S3 will depend on external library- if there will be
> a bug / feature request we will have to wait for some externals to
> solve that (see Ognl and Javassist).
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
e: davelnewton@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton
b: Bucky Bits
g: davelnewton
so: Dave Newton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/28 Dave Newton <da...@gmail.com>:
> 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 pre-Guice with Guice - the current version of Guice misses
alot of features (eg. no support for xml based configuration). Other
issue is that the S3 will depend on external library- if there will be
a bug / feature request we will have to wait for some externals to
solve that (see Ognl and Javassist).
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Dave Newton <da...@gmail.com>.
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" <je...@yahoo.com> wrote:
> 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 <gi...@it-neering.net>
> To: Struts Developers List <de...@struts.apache.org>
> Sent: Wednesday, November 28, 2012 3:58 AM
> Subject: 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 injection, integrating Guice would be the
> option to go. Your points about the limits of class bound annotations
> are valid, and that is why we have to decide for a concrete DI
> implementation rather than a standard (though it is nice if it
> introduces a standard on it's back). This is why Guice would make sense,
> since it would support our mechanism of offering configuration options
> apart from classes, via property injection and binding configuration
> done in struts.xml, so without the need for DI framework specific
> configuration files besides our own config.
>
> - René
>
> Am 28.11.12 09:01, schrieb Konstantin Priblouda:
> > 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.
> >
> > Just EUR 0.02 from picocontainer developer.
> >
> > regadrs,
> >
> > ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> > JTec quality components: http://www.pribluda.de/projects/
> >
> >
> > ________________________________
> > From: Paul Benedict <pb...@apache.org>
> > To: Struts Developers List <de...@struts.apache.org>
> > Sent: Wednesday, November 28, 2012 8:31 AM
> > Subject: Re: Plan for Struts 3
> >
> > Well I know that XWork had its only dependency injection support, but now
> > that Java has a standard dependency injection mechanism, we should
> > definitely go with that. Also it keeps on getting developed with each new
> > EE so it's something we should support as a first-class citizen.
> >
> > On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lukaszlenart@apache.org
> >wrote:
> >
> >> 2012/11/28 Paul Benedict <pb...@apache.org>:
> >>> What about dropping XWork injection support for JSR 330 (Commons DI)?
> >>
> >> You mean what we have now and use Guice as an internal DI mechanism ?
> >>
> >>
> >> Regards
> >> --
> >> Łukasz
> >> + 48 606 323 122 http://www.lenart.org.pl/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
>
> --
> René Gielen
> IT-Neering.net
> Saarstrasse 100, 52062 Aachen, Germany
> Tel: +49-(0)241-4010770
> Fax: +49-(0)241-4010771
> Cel: +49-(0)163-2844164
> http://twitter.com/rgielen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Jeff Black <je...@yahoo.com>.
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 <gi...@it-neering.net>
To: Struts Developers List <de...@struts.apache.org>
Sent: Wednesday, November 28, 2012 3:58 AM
Subject: 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 injection, integrating Guice would be the
option to go. Your points about the limits of class bound annotations
are valid, and that is why we have to decide for a concrete DI
implementation rather than a standard (though it is nice if it
introduces a standard on it's back). This is why Guice would make sense,
since it would support our mechanism of offering configuration options
apart from classes, via property injection and binding configuration
done in struts.xml, so without the need for DI framework specific
configuration files besides our own config.
- René
Am 28.11.12 09:01, schrieb Konstantin Priblouda:
> 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.
>
> Just EUR 0.02 from picocontainer developer.
>
> regadrs,
>
> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> JTec quality components: http://www.pribluda.de/projects/
>
>
> ________________________________
> From: Paul Benedict <pb...@apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Sent: Wednesday, November 28, 2012 8:31 AM
> Subject: Re: Plan for Struts 3
>
> Well I know that XWork had its only dependency injection support, but now
> that Java has a standard dependency injection mechanism, we should
> definitely go with that. Also it keeps on getting developed with each new
> EE so it's something we should support as a first-class citizen.
>
> On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lu...@apache.org>wrote:
>
>> 2012/11/28 Paul Benedict <pb...@apache.org>:
>>> What about dropping XWork injection support for JSR 330 (Commons DI)?
>>
>> You mean what we have now and use Guice as an internal DI mechanism ?
>>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)163-2844164
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Rene Gielen <gi...@it-neering.net>.
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 injection, integrating Guice would be the
option to go. Your points about the limits of class bound annotations
are valid, and that is why we have to decide for a concrete DI
implementation rather than a standard (though it is nice if it
introduces a standard on it's back). This is why Guice would make sense,
since it would support our mechanism of offering configuration options
apart from classes, via property injection and binding configuration
done in struts.xml, so without the need for DI framework specific
configuration files besides our own config.
- René
Am 28.11.12 09:01, schrieb Konstantin Priblouda:
> 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.
>
> Just EUR 0.02 from picocontainer developer.
>
> regadrs,
>
> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> JTec quality components: http://www.pribluda.de/projects/
>
>
> ________________________________
> From: Paul Benedict <pb...@apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Sent: Wednesday, November 28, 2012 8:31 AM
> Subject: Re: Plan for Struts 3
>
> Well I know that XWork had its only dependency injection support, but now
> that Java has a standard dependency injection mechanism, we should
> definitely go with that. Also it keeps on getting developed with each new
> EE so it's something we should support as a first-class citizen.
>
> On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lu...@apache.org>wrote:
>
>> 2012/11/28 Paul Benedict <pb...@apache.org>:
>>> What about dropping XWork injection support for JSR 330 (Commons DI)?
>>
>> You mean what we have now and use Guice as an internal DI mechanism ?
>>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)163-2844164
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Konstantin Priblouda <kp...@yahoo.com>.
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.
Just EUR 0.02 from picocontainer developer.
regadrs,
----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/
________________________________
From: Paul Benedict <pb...@apache.org>
To: Struts Developers List <de...@struts.apache.org>
Sent: Wednesday, November 28, 2012 8:31 AM
Subject: Re: Plan for Struts 3
Well I know that XWork had its only dependency injection support, but now
that Java has a standard dependency injection mechanism, we should
definitely go with that. Also it keeps on getting developed with each new
EE so it's something we should support as a first-class citizen.
On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lu...@apache.org>wrote:
> 2012/11/28 Paul Benedict <pb...@apache.org>:
> > What about dropping XWork injection support for JSR 330 (Commons DI)?
>
> You mean what we have now and use Guice as an internal DI mechanism ?
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Plan for Struts 3
Posted by Paul Benedict <pb...@apache.org>.
Well I know that XWork had its only dependency injection support, but now
that Java has a standard dependency injection mechanism, we should
definitely go with that. Also it keeps on getting developed with each new
EE so it's something we should support as a first-class citizen.
On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lu...@apache.org>wrote:
> 2012/11/28 Paul Benedict <pb...@apache.org>:
> > What about dropping XWork injection support for JSR 330 (Commons DI)?
>
> You mean what we have now and use Guice as an internal DI mechanism ?
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/28 Paul Benedict <pb...@apache.org>:
> What about dropping XWork injection support for JSR 330 (Commons DI)?
You mean what we have now and use Guice as an internal DI mechanism ?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Paul Benedict <pb...@apache.org>.
What about dropping XWork injection support for JSR 330 (Commons DI)?
On Wed, Nov 28, 2012 at 12:41 AM, Lukasz Lenart <lu...@apache.org>wrote:
> I've updated the plan :-)
>
> Request Git repo from INFRA
> Import project
> Remove deprecated plugins
> Drop support for Struts 1 (remove plugin)
> Remove deprecated APIs
> Switch to Java 1.6
> Rename XWork packages to org.apache.struts.xwork
> Rename Struts 2 packages to org.apache.struts
> Prepare the first release
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
I've updated the plan :-)
Request Git repo from INFRA
Import project
Remove deprecated plugins
Drop support for Struts 1 (remove plugin)
Remove deprecated APIs
Switch to Java 1.6
Rename XWork packages to org.apache.struts.xwork
Rename Struts 2 packages to org.apache.struts
Prepare the first release
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/28 Dave Newton <da...@gmail.com>:
> Part of the question regarded org.apache.struts v. org.apache.struts2.
>
> I don't know how many (if any) conflicts there are.
>
> I'm not a fan of embedding version info in package names. I'd hate to
> see org.apache.struts3, and IMO it'd be confusing to have Struts 3
> have a struts2 package name component.
Dave is right, that's the main case - package naming and as a side
effect is support for S1 in S3
And I think we agreed to drop support for S1 (remove the plugin) and
rename packages to org.apache.struts
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Dave Newton <da...@gmail.com>.
Part of the question regarded org.apache.struts v. org.apache.struts2.
I don't know how many (if any) conflicts there are.
I'm not a fan of embedding version info in package names. I'd hate to
see org.apache.struts3, and IMO it'd be confusing to have Struts 3
have a struts2 package name component.
Dave
On Tue, Nov 27, 2012 at 6:12 PM, Paul Benedict <pb...@apache.org> wrote:
> Perhaps I don't understand, but you can run Struts 1 and Struts 2
> simultaneously. They have different Maven artifacts and Java package names.
>
> The discussion was about whether to continue supporting the Struts 1 Plugin
> in S3. I am of the opinion "no" because it provides such limited
> capabilities. It doesn't really help since all you get is the Action layer,
> not the taglib. Anyone who built an S1 app still has to rewrite their
> presentation layer in S2/S3 -- so might as go all the way and port it all
> to S3.
>
> Paul
>
> On Tue, Nov 27, 2012 at 5:09 PM, Martin Gainty <mg...@hotmail.com> wrote:
>
>>
>> Matt makes a good pointone of the primary reasons to select Struts MVC
>> Framework over Spring is the ability of Struts2 to work with previous
>> Struts versions (Struts1)
>> +1 for Matt
>>
>> Martin
>> ______________________________________________
>> Please do not alter or disrupt this transmission...Thank You
>> > Subject: Re: Plan for Struts 3
>> > From: matt@raibledesigns.com
>> > Date: Tue, 27 Nov 2012 15:59:51 -0700
>> > To: dev@struts.apache.org; jeffrey.black@yahoo.com
>> >
>> > If it breaks backwards-compatibility, I'd suggest not doing it. I've
>> always been impressed with projects like Spring that've maintained
>> backwards compatibility w/o making a breaking change such as this.
>> >
>> > On Nov 27, 2012, at 3:54 PM, Jeff Black <je...@yahoo.com> wrote:
>> >
>> > > Never mind.
>> > >
>> > > I suppose it makes sense to some extent; however I'm with Dave when it
>> comes to incorporating the version number in the package name.
>> > >
>> > > Just my two cents.
>> > >
>> > >
>> > >
>> > > ________________________________
>> > > From: Jeff Black <je...@yahoo.com>
>> > > To: Struts Developers List <de...@struts.apache.org>
>> > > Sent: Tuesday, November 27, 2012 4:50 PM
>> > > Subject: Re: Plan for Struts 3
>> > >
>> > > Is it really necessary to alter the package name?
>> > >
>> > >
>> > >
>> > > ________________________________
>> > > From: Lukasz Lenart <lu...@apache.org>
>> > > To: Struts Developers List <de...@struts.apache.org>
>> > > Sent: Thursday, November 22, 2012 5:35 AM
>> > > Subject: Re: Plan for Struts 3
>> > >
>> > > 2012/11/22 Dave Newton <da...@gmail.com>:
>> > >> How useful is the Struts 1 plugin?
>> > >
>> > > It's mentioned as a migration way for S1 projects, but we can drop
>> > > support for S1 in S3
>> > >
>> > >
>> > > Regards
>> > > --
>> > > Łukasz
>> > > + 48 606 323 122 http://www.lenart.org.pl/
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>>
--
e: davelnewton@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton
b: Bucky Bits
g: davelnewton
so: Dave Newton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Paul Benedict <pb...@apache.org>.
Perhaps I don't understand, but you can run Struts 1 and Struts 2
simultaneously. They have different Maven artifacts and Java package names.
The discussion was about whether to continue supporting the Struts 1 Plugin
in S3. I am of the opinion "no" because it provides such limited
capabilities. It doesn't really help since all you get is the Action layer,
not the taglib. Anyone who built an S1 app still has to rewrite their
presentation layer in S2/S3 -- so might as go all the way and port it all
to S3.
Paul
On Tue, Nov 27, 2012 at 5:09 PM, Martin Gainty <mg...@hotmail.com> wrote:
>
> Matt makes a good pointone of the primary reasons to select Struts MVC
> Framework over Spring is the ability of Struts2 to work with previous
> Struts versions (Struts1)
> +1 for Matt
>
> Martin
> ______________________________________________
> Please do not alter or disrupt this transmission...Thank You
> > Subject: Re: Plan for Struts 3
> > From: matt@raibledesigns.com
> > Date: Tue, 27 Nov 2012 15:59:51 -0700
> > To: dev@struts.apache.org; jeffrey.black@yahoo.com
> >
> > If it breaks backwards-compatibility, I'd suggest not doing it. I've
> always been impressed with projects like Spring that've maintained
> backwards compatibility w/o making a breaking change such as this.
> >
> > On Nov 27, 2012, at 3:54 PM, Jeff Black <je...@yahoo.com> wrote:
> >
> > > Never mind.
> > >
> > > I suppose it makes sense to some extent; however I'm with Dave when it
> comes to incorporating the version number in the package name.
> > >
> > > Just my two cents.
> > >
> > >
> > >
> > > ________________________________
> > > From: Jeff Black <je...@yahoo.com>
> > > To: Struts Developers List <de...@struts.apache.org>
> > > Sent: Tuesday, November 27, 2012 4:50 PM
> > > Subject: Re: Plan for Struts 3
> > >
> > > Is it really necessary to alter the package name?
> > >
> > >
> > >
> > > ________________________________
> > > From: Lukasz Lenart <lu...@apache.org>
> > > To: Struts Developers List <de...@struts.apache.org>
> > > Sent: Thursday, November 22, 2012 5:35 AM
> > > Subject: Re: Plan for Struts 3
> > >
> > > 2012/11/22 Dave Newton <da...@gmail.com>:
> > >> How useful is the Struts 1 plugin?
> > >
> > > It's mentioned as a migration way for S1 projects, but we can drop
> > > support for S1 in S3
> > >
> > >
> > > Regards
> > > --
> > > Łukasz
> > > + 48 606 323 122 http://www.lenart.org.pl/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
RE: Plan for Struts 3
Posted by Martin Gainty <mg...@hotmail.com>.
Matt makes a good pointone of the primary reasons to select Struts MVC Framework over Spring is the ability of Struts2 to work with previous Struts versions (Struts1)
+1 for Matt
Martin
______________________________________________
Please do not alter or disrupt this transmission...Thank You
> Subject: Re: Plan for Struts 3
> From: matt@raibledesigns.com
> Date: Tue, 27 Nov 2012 15:59:51 -0700
> To: dev@struts.apache.org; jeffrey.black@yahoo.com
>
> If it breaks backwards-compatibility, I'd suggest not doing it. I've always been impressed with projects like Spring that've maintained backwards compatibility w/o making a breaking change such as this.
>
> On Nov 27, 2012, at 3:54 PM, Jeff Black <je...@yahoo.com> wrote:
>
> > Never mind.
> >
> > I suppose it makes sense to some extent; however I'm with Dave when it comes to incorporating the version number in the package name.
> >
> > Just my two cents.
> >
> >
> >
> > ________________________________
> > From: Jeff Black <je...@yahoo.com>
> > To: Struts Developers List <de...@struts.apache.org>
> > Sent: Tuesday, November 27, 2012 4:50 PM
> > Subject: Re: Plan for Struts 3
> >
> > Is it really necessary to alter the package name?
> >
> >
> >
> > ________________________________
> > From: Lukasz Lenart <lu...@apache.org>
> > To: Struts Developers List <de...@struts.apache.org>
> > Sent: Thursday, November 22, 2012 5:35 AM
> > Subject: Re: Plan for Struts 3
> >
> > 2012/11/22 Dave Newton <da...@gmail.com>:
> >> How useful is the Struts 1 plugin?
> >
> > It's mentioned as a migration way for S1 projects, but we can drop
> > support for S1 in S3
> >
> >
> > Regards
> > --
> > Łukasz
> > + 48 606 323 122 http://www.lenart.org.pl/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
Re: Plan for Struts 3
Posted by Matt Raible <ma...@raibledesigns.com>.
If it breaks backwards-compatibility, I'd suggest not doing it. I've always been impressed with projects like Spring that've maintained backwards compatibility w/o making a breaking change such as this.
On Nov 27, 2012, at 3:54 PM, Jeff Black <je...@yahoo.com> wrote:
> Never mind.
>
> I suppose it makes sense to some extent; however I'm with Dave when it comes to incorporating the version number in the package name.
>
> Just my two cents.
>
>
>
> ________________________________
> From: Jeff Black <je...@yahoo.com>
> To: Struts Developers List <de...@struts.apache.org>
> Sent: Tuesday, November 27, 2012 4:50 PM
> Subject: Re: Plan for Struts 3
>
> Is it really necessary to alter the package name?
>
>
>
> ________________________________
> From: Lukasz Lenart <lu...@apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Sent: Thursday, November 22, 2012 5:35 AM
> Subject: Re: Plan for Struts 3
>
> 2012/11/22 Dave Newton <da...@gmail.com>:
>> How useful is the Struts 1 plugin?
>
> It's mentioned as a migration way for S1 projects, but we can drop
> support for S1 in S3
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Jeff Black <je...@yahoo.com>.
Never mind.
I suppose it makes sense to some extent; however I'm with Dave when it comes to incorporating the version number in the package name.
Just my two cents.
________________________________
From: Jeff Black <je...@yahoo.com>
To: Struts Developers List <de...@struts.apache.org>
Sent: Tuesday, November 27, 2012 4:50 PM
Subject: Re: Plan for Struts 3
Is it really necessary to alter the package name?
________________________________
From: Lukasz Lenart <lu...@apache.org>
To: Struts Developers List <de...@struts.apache.org>
Sent: Thursday, November 22, 2012 5:35 AM
Subject: Re: Plan for Struts 3
2012/11/22 Dave Newton <da...@gmail.com>:
> How useful is the Struts 1 plugin?
It's mentioned as a migration way for S1 projects, but we can drop
support for S1 in S3
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Jeff Black <je...@yahoo.com>.
Is it really necessary to alter the package name?
________________________________
From: Lukasz Lenart <lu...@apache.org>
To: Struts Developers List <de...@struts.apache.org>
Sent: Thursday, November 22, 2012 5:35 AM
Subject: Re: Plan for Struts 3
2012/11/22 Dave Newton <da...@gmail.com>:
> How useful is the Struts 1 plugin?
It's mentioned as a migration way for S1 projects, but we can drop
support for S1 in S3
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/22 Dave Newton <da...@gmail.com>:
> How useful is the Struts 1 plugin?
It's mentioned as a migration way for S1 projects, but we can drop
support for S1 in S3
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Dave Newton <da...@gmail.com>.
How useful is the Struts 1 plugin?
I'm not a big fan of the package name versioning.
Dave
(pardon brevity, typos, and top-quoting; on cell)
On Nov 22, 2012 4:45 AM, "Lukasz Lenart" <lu...@apache.org> wrote:
> 2012/11/22 Christian Grobmeier <gr...@gmail.com>:
> > Plugins would probably break. But they could break even when we stick
> > with o.a.struts, at runtime (more worse).
> > That said I would prefer a.o.struts3, even when it is more work.
>
> Yeah, o.a.struts probably will disallow to use the Struts 1 plugin as
> packages and classes will clash
>
>
> Regards
>
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/22 Christian Grobmeier <gr...@gmail.com>:
> Plugins would probably break. But they could break even when we stick
> with o.a.struts, at runtime (more worse).
> That said I would prefer a.o.struts3, even when it is more work.
Yeah, o.a.struts probably will disallow to use the Struts 1 plugin as
packages and classes will clash
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, Nov 22, 2012 at 10:36 AM, Lukasz Lenart <lu...@apache.org> wrote:
> 2012/11/22 Lukasz Lenart <lu...@apache.org>:
>> Rename Struts 2 packages to org.apache.struts ?
>
> I have only one concern - how to name packages :\
>
> Right now there is org.apache.struts2, org.apache.struts is used by
> Struts 1 - so the right direction would be named them
> org.apache.struts3 but is it the good one ?
Plugins would probably break. But they could break even when we stick
with o.a.struts, at runtime (more worse).
That said I would prefer a.o.struts3, even when it is more work.
Cheers
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/22 Lukasz Lenart <lu...@apache.org>:
> Rename Struts 2 packages to org.apache.struts ?
I have only one concern - how to name packages :\
Right now there is org.apache.struts2, org.apache.struts is used by
Struts 1 - so the right direction would be named them
org.apache.struts3 but is it the good one ?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Johannes Geppert <jo...@apache.org>.
+1 Great Plan!
Johannes
#################################################
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep
2012/11/22 Lukasz Lenart <lu...@apache.org>
> st
Re: Git (Was: Plan for Struts 3)
Posted by Lukasz Lenart <lu...@apache.org>.
2012/12/6 Christian Grobmeier <gr...@gmail.com>:
> There are some minor things I found:
>
> - the develop branch needs to be used in CI. Not a big deal, but somehow we
> need to tell it the CI
Yes, you can - there is option branches to build
> - what about feature branches? Should they all go remote? When are they
> merged into develop?
No, you can push it remote but if it's a small change it can stay
local. You merge them when you finished ;-)
> Example: I make a feature A, on lokal. When done I merge it into develop
> and push it to remote, where everybody can access it.
> Now lets say I develop the internal guice upgrade. Its something many
> people want to do. Git lets me push my feature branch to remote, like:
> *
> http://www.mariopareja.com/blog/archive/2010/01/11/how-to-push-a-new-local-branch-to-a-remote.aspx
>
> - use of git rebase. this is a feature which I really don't like or don't
> understand. For me history is sacred. When I do a feature A, i might have 5
> commits. Now when I am pushing this, there are some people who say: nobody
> is interested in the commit-mess. They say, I should do a rebase, and my 5
> commits become one visible.
You perform those five commits to your feature branch, when you have
done, switch to develop and merge
git merge --no-ff myfeature
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, Dec 6, 2012 at 12:43 PM, Rene Gielen <rg...@apache.org> wrote:
> great and comprehensive writeup. Which brings me to what is really good
> about not being the first time mover - being able to profit from other's
> experiences.
>
>
Unfortunately I have not so much more experience with GIT :-|
Well, I tried the proposed workflow in another project and it looks good so
far.
There are some minor things I found:
- the develop branch needs to be used in CI. Not a big deal, but somehow we
need to tell it the CI
- what about feature branches? Should they all go remote? When are they
merged into develop?
Example: I make a feature A, on lokal. When done I merge it into develop
and push it to remote, where everybody can access it.
Now lets say I develop the internal guice upgrade. Its something many
people want to do. Git lets me push my feature branch to remote, like:
*
http://www.mariopareja.com/blog/archive/2010/01/11/how-to-push-a-new-local-branch-to-a-remote.aspx
- use of git rebase. this is a feature which I really don't like or don't
understand. For me history is sacred. When I do a feature A, i might have 5
commits. Now when I am pushing this, there are some people who say: nobody
is interested in the commit-mess. They say, I should do a rebase, and my 5
commits become one visible.
Thanks for the other links below; I will surely read through them the next
days.
Surely they will include some wisdom
Cheers
Christian
> A nice glance into some Git-related discussions over at Incubator:
> http://markmail.org/message/6f7l3fjksjeem6li
>
> Wicket has fully moved to Git, we might want to peek a bit:
> http://markmail.org/message/5rnmtklofv2w7lsv
> http://markmail.org/message/6f7l3fjksjeem6li
> https://issues.apache.org/jira/browse/INFRA-4204
> https://wicket.apache.org/contribute/release.html
>
> Maven obviously had a bit more to plan...
> https://cwiki.apache.org/MAVEN/git-migration.html
> https://issues.apache.org/jira/browse/INFRA-5266
>
> Cloudstack was the prototype project for Git@Apache
> https://cwiki.apache.org/CLOUDSTACK/git.html
> https://cwiki.apache.org/CLOUDSTACK/working-with-cloudstack-code.html
>
> - René
>
>
> Am 06.12.12 11:53, schrieb Christian Grobmeier:
> > On Thu, Dec 6, 2012 at 11:44 AM, Lukasz Lenart <lu...@apache.org>
> wrote:
> >> 2012/12/6 Christian Grobmeier <gr...@gmail.com>:
> >>> Would be glad to look at your repos on github.
> >>>
> >>> One question: are we going to fix issues in Struts 2.x on SVN or are
> >>> we going to have everything on GIT then?
> >>> In the git-brnaching-model link I see one development branch. I think
> >>> we would need a develop2x, develop3x etc branches, right?
> >>
> >> I thought to leave S2 on SVN and only support it in case of security
> >> fixes and really important (performance) fixes, on Git just have S3
> >
> > Works for me. Its much safer until we all have the necessary
> > experience and a workflow has become natural.
> >
> > We can incoperate fixes from S2 (svn) into S3 (git). I once wrote
> > something in that direction for Apache Logging:
> > http://wiki.apache.org/logging/UsingGitWithLogging
> >
> > I took changes from GIT and pushed it to SVN
> >
> > Cheers
> > Christian
> >
> >
> >>
> >> Regards
> >> --
> >> Łukasz
> >> + 48 606 323 122 http://www.lenart.org.pl/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >
> >
> >
> > --
> > http://www.grobmeier.de
> > https://www.timeandbill.de
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> --
> René Gielen
> http://twitter.com/rgielen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
http://www.grobmeier.de
https://www.timeandbill.de
Re: Git (Was: Plan for Struts 3)
Posted by Rene Gielen <rg...@apache.org>.
Christian,
great and comprehensive writeup. Which brings me to what is really good
about not being the first time mover - being able to profit from other's
experiences.
A nice glance into some Git-related discussions over at Incubator:
http://markmail.org/message/6f7l3fjksjeem6li
Wicket has fully moved to Git, we might want to peek a bit:
http://markmail.org/message/5rnmtklofv2w7lsv
http://markmail.org/message/6f7l3fjksjeem6li
https://issues.apache.org/jira/browse/INFRA-4204
https://wicket.apache.org/contribute/release.html
Maven obviously had a bit more to plan...
https://cwiki.apache.org/MAVEN/git-migration.html
https://issues.apache.org/jira/browse/INFRA-5266
Cloudstack was the prototype project for Git@Apache
https://cwiki.apache.org/CLOUDSTACK/git.html
https://cwiki.apache.org/CLOUDSTACK/working-with-cloudstack-code.html
- René
Am 06.12.12 11:53, schrieb Christian Grobmeier:
> On Thu, Dec 6, 2012 at 11:44 AM, Lukasz Lenart <lu...@apache.org> wrote:
>> 2012/12/6 Christian Grobmeier <gr...@gmail.com>:
>>> Would be glad to look at your repos on github.
>>>
>>> One question: are we going to fix issues in Struts 2.x on SVN or are
>>> we going to have everything on GIT then?
>>> In the git-brnaching-model link I see one development branch. I think
>>> we would need a develop2x, develop3x etc branches, right?
>>
>> I thought to leave S2 on SVN and only support it in case of security
>> fixes and really important (performance) fixes, on Git just have S3
>
> Works for me. Its much safer until we all have the necessary
> experience and a workflow has become natural.
>
> We can incoperate fixes from S2 (svn) into S3 (git). I once wrote
> something in that direction for Apache Logging:
> http://wiki.apache.org/logging/UsingGitWithLogging
>
> I took changes from GIT and pushed it to SVN
>
> Cheers
> Christian
>
>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
René Gielen
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, Dec 6, 2012 at 11:44 AM, Lukasz Lenart <lu...@apache.org> wrote:
> 2012/12/6 Christian Grobmeier <gr...@gmail.com>:
>> Would be glad to look at your repos on github.
>>
>> One question: are we going to fix issues in Struts 2.x on SVN or are
>> we going to have everything on GIT then?
>> In the git-brnaching-model link I see one development branch. I think
>> we would need a develop2x, develop3x etc branches, right?
>
> I thought to leave S2 on SVN and only support it in case of security
> fixes and really important (performance) fixes, on Git just have S3
Works for me. Its much safer until we all have the necessary
experience and a workflow has become natural.
We can incoperate fixes from S2 (svn) into S3 (git). I once wrote
something in that direction for Apache Logging:
http://wiki.apache.org/logging/UsingGitWithLogging
I took changes from GIT and pushed it to SVN
Cheers
Christian
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Lukasz Lenart <lu...@apache.org>.
2012/12/6 Christian Grobmeier <gr...@gmail.com>:
> Would be glad to look at your repos on github.
>
> One question: are we going to fix issues in Struts 2.x on SVN or are
> we going to have everything on GIT then?
> In the git-brnaching-model link I see one development branch. I think
> we would need a develop2x, develop3x etc branches, right?
I thought to leave S2 on SVN and only support it in case of security
fixes and really important (performance) fixes, on Git just have S3
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Lukasz Lenart <lu...@apache.org>.
2012/12/6 Rene Gielen <rg...@apache.org>:
> For migrating current SVN repo content to Git, Infra prefers to
> completely move an existing Git mirror repo. As I see it, we should
> migrate struts2.git and arguably struts-sandbox.git and let the other
> parts reside in SVN with Git morring only.
I didn't think about that :-) We can migrate Struts2, try out how to
use Git and start development of S3 after all :-)
But we should call the repo struts.git ;-)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Rene Gielen <rg...@apache.org>.
This is an excellent question and part of the discussion I wanted to
start (but wasn't able to follow up so far in the last busy days)
Given that we decide for Git:
As for me, it makes absolutely no sense to have a common origin codebase
split up into two repositories. If we vote for developing S3 based on a
Git repository and workflow, we should move *the full* Struts 2
development to Git. Developing a new major version takes time, and we
will have to deal with a lot of commits that need to be ported from 2.x
to 3.x branch and vice versa. Having S3 in Git an S2 in subversion makes
absolutely no sense to me then.
What I don't see is moving the S1, site, maven etc. parts of our
Subversion repo. A good way to start planning for chainsawing is having
a look at our Git mirror repos at http://git.apache.org. Currently there
are 5 repos:
struts1.git
struts2.git
struts-sandbox.git
struts-maven.git
struts-site.git
For migrating current SVN repo content to Git, Infra prefers to
completely move an existing Git mirror repo. As I see it, we should
migrate struts2.git and arguably struts-sandbox.git and let the other
parts reside in SVN with Git morring only.
- René
Am 06.12.12 11:32, schrieb Christian Grobmeier:
> On Thu, Dec 6, 2012 at 11:13 AM, Lukasz Lenart <lu...@apache.org> wrote:
>> 2012/11/28 Dave Newton <da...@gmail.com>:
>>> 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.
>>
>> The idea looks pretty nice, as we don't have a Git repo yet, I'm going
>> to fork struts2 on the GitHub and try to play a bit - especially with
>> release process
>
> Would be glad to look at your repos on github.
>
> One question: are we going to fix issues in Struts 2.x on SVN or are
> we going to have everything on GIT then?
> In the git-brnaching-model link I see one development branch. I think
> we would need a develop2x, develop3x etc branches, right?
>
> Cheers
> Christian
>
>
>>
>>
>> Regards
>> --
>> Łukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
René Gielen
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, Dec 6, 2012 at 11:13 AM, Lukasz Lenart <lu...@apache.org> wrote:
> 2012/11/28 Dave Newton <da...@gmail.com>:
>> 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.
>
> The idea looks pretty nice, as we don't have a Git repo yet, I'm going
> to fork struts2 on the GitHub and try to play a bit - especially with
> release process
Would be glad to look at your repos on github.
One question: are we going to fix issues in Struts 2.x on SVN or are
we going to have everything on GIT then?
In the git-brnaching-model link I see one development branch. I think
we would need a develop2x, develop3x etc branches, right?
Cheers
Christian
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Lukasz Lenart <lu...@apache.org>.
2012/12/6 Lukasz Lenart <lu...@apache.org>:
> The idea looks pretty nice, as we don't have a Git repo yet, I'm going
> to fork struts2 on the GitHub and try to play a bit - especially with
> release process
Updated the plan with links about Git flow
https://cwiki.apache.org/confluence/display/WW/Struts+3
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/28 Dave Newton <da...@gmail.com>:
> 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.
The idea looks pretty nice, as we don't have a Git repo yet, I'm going
to fork struts2 on the GitHub and try to play a bit - especially with
release process
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Dave Newton <da...@gmail.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Christian Grobmeier <gr...@gmail.com>.
On Wed, Nov 28, 2012 at 8:36 PM, Lukasz Lenart <lu...@apache.org> wrote:
> 2012/11/28 Rene Gielen <rg...@apache.org>:
>> 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 here are some first links
>> worth reading as a primer on on this topic:
>
> For me it is simple +1 as I'm using Git(Hub) on daily basis :-)
I am also +1, but for me it is more an adventure. While use Git daily,
unfortunately I do not use it with large teams and a (maybe) complex
build cycle.
That said, we are also migrating with log4php and try to utilize this
workflow (as already suggested):
http://nvie.com/posts/a-successful-git-branching-model/
Lets see how it deals out - worst case we'll learn a lot
Cheers
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Git (Was: Plan for Struts 3)
Posted by Lukasz Lenart <lu...@apache.org>.
2012/11/28 Rene Gielen <rg...@apache.org>:
> 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 here are some first links
> worth reading as a primer on on this topic:
For me it is simple +1 as I'm using Git(Hub) on daily basis :-)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Git (Was: Plan for Struts 3)
Posted by Rene Gielen <rg...@apache.org>.
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, hold breath, and dive into serious discussion about
that. I'm preparing a more detailed post, but here are some first links
worth reading as a primer on on this topic:
http://nvie.com/posts/a-successful-git-branching-model/
https://git-wip-us.apache.org
http://git.apache.org (list of our mirrored Git repos)
For a deep dive, feel free to read the one-stop Git reference this weekend:
http://git-scm.com/book/
- René
Am 22.11.12 09:11, schrieb Lukasz Lenart:
> Hi,
>
> I've prepared a simple plan to start working on Struts 3 which is
> available here [1]
>
> Request Git repo from INFRA
> Import project
> Remove deprecated plugins
> Remove deprecated APIs
> Switch to Java 1.6
> Rename XWork packages to org.apache.struts.xwork
> Rename Struts 2 packages to org.apache.struts ?
> Prepare the first release
>
> [1] https://cwiki.apache.org/confluence/display/WW/Struts+3
>
>
> Regards
>
--
René Gielen
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Plan for Struts 3
Posted by Christian Grobmeier <gr...@gmail.com>.
+1
Reads very cool!
On Thu, Nov 22, 2012 at 9:11 AM, Lukasz Lenart <lu...@apache.org> wrote:
> Hi,
>
> I've prepared a simple plan to start working on Struts 3 which is
> available here [1]
>
> Request Git repo from INFRA
> Import project
> Remove deprecated plugins
> Remove deprecated APIs
> Switch to Java 1.6
> Rename XWork packages to org.apache.struts.xwork
> Rename Struts 2 packages to org.apache.struts ?
> Prepare the first release
>
> [1] https://cwiki.apache.org/confluence/display/WW/Struts+3
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org