Just read through it (slowly catching up with e-mails, sorry for all
struts related delays).
Looks good to me and the clean up of the website will be a great step
forwards. I always found it very confusing
Cheers!
On Sat, May 25, 2013 at 1:19 PM, Lukasz Lenart wrote:
> I have added a point about
I have added a point about Website cleanup with some explanation:
https://cwiki.apache.org/confluence/display/WW/Struts+Next
I thought we will be able to start with plan soon but right now the
main obstacle are recently discovered security vulnerabilities :\
Anyway, the plan is still valid :-)
The plan updated again :-)
https://cwiki.apache.org/confluence/display/WW/Struts+Next
Anyway I would like to stabilise the current 2.3.x branch, solve
security issue in pipeline and then start with the plan :-)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2013/4/26 Lukasz Lenar
Even I like the package structure .
I vote for it
Sent from My Blackberry® @ Tata Docomo
-Original Message-
From: Lukasz Lenart
Date: Fri, 26 Apr 2013 07:06:43
To:
Subject: Re: Plan for Struts 3
2013/4/18 Paul Benedict :
> I know it's a bit contentious, but I would really
2013/4/18 Paul Benedict :
> I know it's a bit contentious, but I would really like the package name to
> be org.apache.struts3 so that people migrate from struts 1 progressively. i
> am actually in the process of doing this now with struts 2.3 (1000 some
> actions) and it's a life-saver. It will ta
> Remove deprecated APIs
> Switch to Java 1.6
> Rename XWork packages to org.apache.struts.xwork
> Prepare the first release
>
> Plan for Struts 3:
> Rename Struts 2 packages to org.apache.struts
>
>
>
Good point!
Plan for Struts 2.5:
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
Prepare the first release
Plan for Struts 3:
Rename XWork packages to org.apache.struts.xwork
Rename Struts 2
> Rename XWork packages to org.apache.struts.xwork
> Prepare the first release
>
> Plan for Struts 3:
> Rename Struts 2 packages to org.apache.struts
What is the added value to expect Struts users to go through the pain of
package renaming two times within a foreseeable time period?
How about this big
Rename XWork packages to org.apache.struts.xwork
Prepare the first release
Plan for Struts 3:
Rename Struts 2 packages to org.apache.struts
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
-
To unsubscribe, e-mail
2013/4/18 Johannes Geppert :
> Hi,
>
>> Switch to Java 1.6
> when starting a new major release why not start with Java 7?
> I mean Java 6 is already in the end of life cycle. :-)
Good question :-) But I think there are users which migrated to Java 6
already and they don't have a plans to migrate t
plan :D
Plan for Struts 2.5:
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
Prepare the first release
Plan for Struts 3:
Rename Struts 2
: Thursday, April 18, 2013 8:46 AM
Subject: Re: Plan for Struts 3
Hi,
> Switch to Java 1.6
when starting a new major release why not start with Java 7?
I mean Java 6 is already in the end of life cycle. :-)
Johannes
#
web: http://www.jgeppert.
> A new plan :D
>
> Plan for Struts 2.5:
> 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
> Pr
A new plan :D
Plan for Struts 2.5:
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
Prepare the first release
Plan for Struts 3:
Rename Struts
2013/3/19 Rene Gielen :
> +1 for removing anything deprecated and unmaintained
Argh ... but can it be version 2.4.x/2.5.x? Or should we wait till 3.x ?
;-)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
-
To unsu
+1 for removing anything deprecated and unmaintained
Am 18.03.13 15:04, schrieb Paul Benedict:
> Yes, S3 should be a clean break from anything deprecated. Remove anything
> no longer supported.
>
> Paul
>
> On Mon, Mar 18, 2013 at 8:12 AM, Christian Grobmeier
> wrote:
>
>> On Mon, Mar 18, 2013
2013/3/18 Paul Benedict :
> Oh, I see what you mean. Sure, why support something you already have a
> replacement for? Just take it out of the build and move them to an "extras"
> distribution for others to get -- they should no longer come as part of the
> standard distribution.
Good point, extra
Oh, I see what you mean. Sure, why support something you already have a
replacement for? Just take it out of the build and move them to an "extras"
distribution for others to get -- they should no longer come as part of the
standard distribution.
BTW... Right now, the plugins are part of S2 releas
2013/3/18 Paul Benedict :
> Ah, that wouldn't be nice to Struts 2 users :-) Just let Struts 2 be as it
> is. Perhaps add notes to the documentation and call it quits for those
> plugins.
Yes I know, but with S2 versioning policy in place it should be
already S4. What I mean is that the plugin will
Ah, that wouldn't be nice to Struts 2 users :-) Just let Struts 2 be as it
is. Perhaps add notes to the documentation and call it quits for those
plugins.
Paul
On Mon, Mar 18, 2013 at 9:30 AM, Lukasz Lenart wrote:
> 2013/3/18 Paul Benedict :
> > Yes, S3 should be a clean break from anything depr
2013/3/18 Paul Benedict :
> Yes, S3 should be a clean break from anything deprecated. Remove anything
> no longer supported.
But I would like to do it before we start with S3, to be precise :-)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---
+1
On Mon, Mar 18, 2013 at 10:04 AM, Paul Benedict wrote:
> Yes, S3 should be a clean break from anything deprecated. Remove anything
> no longer supported.
>
> Paul
>
> On Mon, Mar 18, 2013 at 8:12 AM, Christian Grobmeier >wrote:
>
> > On Mon, Mar 18, 2013 at 9:46 AM, Lukasz Lenart
> > wrote:
Yes, S3 should be a clean break from anything deprecated. Remove anything
no longer supported.
Paul
On Mon, Mar 18, 2013 at 8:12 AM, Christian Grobmeier wrote:
> On Mon, Mar 18, 2013 at 9:46 AM, Lukasz Lenart
> wrote:
> > As S1 is going to be emeritus soon, what do you think about removing
> >
On Mon, Mar 18, 2013 at 9:46 AM, Lukasz Lenart wrote:
> As S1 is going to be emeritus soon, what do you think about removing
> the Struts 1 plugin from Struts 2? Also we could remove other
> deprecated plugins like Dojo, Zero Configuration and JSF?
+1
It was yesterday when I was looking at them
As S1 is going to be emeritus soon, what do you think about removing
the Struts 1 plugin from Struts 2? Also we could remove other
deprecated plugins like Dojo, Zero Configuration and JSF?
Thus would be covered in 2.4.x release and with cleaned a bit code
base we could switch to Git and start work
2013/3/6 Paul Benedict :
> Sorry, new STRUTS JIRA project.
Exactly :-)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: d
Sorry, new STRUTS JIRA project.
On Wed, Mar 6, 2013 at 2:53 PM, Paul Benedict wrote:
> I wouldn't want to archive the old struts 1 ticket (i.e., hide them in
> jira). But consider creating a new STRUTS JIRA ticket for 3 and forward,
> keep WW for 2.x, and STR 1.x
>
> Paul
>
>
> On Wed, Mar 6, 20
I wouldn't want to archive the old struts 1 ticket (i.e., hide them in
jira). But consider creating a new STRUTS JIRA ticket for 3 and forward,
keep WW for 2.x, and STR 1.x
Paul
On Wed, Mar 6, 2013 at 2:49 PM, Lukasz Lenart wrote:
> 2013/3/5 René Gielen :
> > The most important steps are to publ
2013/3/5 René Gielen :
> The most important steps are to publicly announce EOL and mark resources as
> attic.
Yes, we should say that this is the end and go forward. Basically I
would like to have just one project - Struts - as the website, in
JIRA, as a Twitter tag and so on. I think there is no
Fair enough, I'm hopeful as well that the docs will still be available. I
realize there hasn't been a release in ages, but I always assumed that if there
was a security issue that it would be patched. If someone wants to migrate
they could use some version of Struts2 2.? to slowly migrate piec
The most important steps are to publicly announce EOL and mark resources as
attic.
- René
Paul Benedict schrieb:
>That's good to know, Dave. I had some question on the meaning of
>"support"
>-- development, hosting, etc. If it's just stopping development, which
>was
>my hope, that's a fine c
That's good to know, Dave. I had some question on the meaning of "support"
-- development, hosting, etc. If it's just stopping development, which was
my hope, that's a fine choice.. But since there isn't any on-going
development of S1 anyway, stopping it is a benign task. :-)
On Tue, Mar 5, 20
I don't think anybody was talking about removing all traces of it, just
making the lack of support official.
Dave
Coincidentally, there is an active vote going on in Maven land to desupport
Maven 1. It won't be final until tomorrow, I believe, but it was gotten
overwhelming votes.
I don't think we need any announcement to desupport Struts 1. However, we
shouldn't wipe Struts 1 off the site. Every company I've
On Tue, Mar 5, 2013 at 3:29 PM, Brian Holzer wrote:
> Hi all,
>If you drop support for S1, what about those people still using S1?
> I'm guessing there are a lot of them out there.
I'd argue that it really hasn't been supported for some time now. I
suppose if there were some horrible securit
It seems to be quite obvious that we don't have enough volunteers
willing to support Struts 1 in an effective way. As long as this does
not change, we can't call Struts 1 a supported product any more.
That said, I'm aware that there are a lot of people out there still
using Struts 1. I think the c
On Tue, Mar 5, 2013 at 3:29 PM, Brian Holzer wrote:
>If you drop support for S1, what about those people still using S1?
> I'm guessing there are a lot of them out there.
>
There are, but there are very, very few releases of S1 at this point, and
few people with a need to upgrade past whateve
2013/3/5 Don Brown :
> All support for Struts 1 meant, afaik, is the ability to deploy
> side-by-side. We used a different Java package to allow the code to
> co-exist, however, the proposal as I understand it is to go back to
> org.apache.struts
Yes, just to have one package org.apache.struts an
2013/3/5 Brian Holzer :
> Hi all,
>If you drop support for S1, what about those people still using S1?
> I'm guessing there are a lot of them out there.
Truly said, S1 is dead, I don't know how to prepare a release, I don't
know the code base, there was no single commit since I have joined the
2013/3/5 Paul Benedict :
> Question on the fourth version point: I don't think the four points plays
> all that nicely with maven. They are strictly 3 with anything else being a
> lexicographic ordering. I know we created the 4th point for emergency patch
> releases, but in practice, how is it any
All support for Struts 1 meant, afaik, is the ability to deploy
side-by-side. We used a different Java package to allow the code to
co-exist, however, the proposal as I understand it is to go back to
org.apache.struts
Don
On Tue, Mar 5, 2013 at 1:29 PM, Brian Holzer wrote:
> Hi all,
>If y
Hi all,
If you drop support for S1, what about those people still using S1?
I'm guessing there are a lot of them out there.
Brian
>>> Lukasz Lenart 3/5/2013 2:22 PM >>>
Hi,
I have few additional thoughts about S3 and the future. First with
should drop support of S1 and use simple Struts as
I have no problem with dropping support for S1. :-)
Question on the fourth version point: I don't think the four points plays
all that nicely with maven. They are strictly 3 with anything else being a
lexicographic ordering. I know we created the 4th point for emergency patch
releases, but in prac
Hi,
I have few additional thoughts about S3 and the future. First with
should drop support of S1 and use simple Struts as a project name - no
more Struts2, Struts3, Struts4, ... Simple Struts and version 3.0.1,
4.1.0.1, etc. We should just keep support for one version back, so
when we release 3.x,
2012/12/19 :
> 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-
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
Date: Wed, 19 Dec 2012 15:28:09
To: Struts Developers List
Reply-To: "Struts Developers List"
Subject: Re
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/displa
2012/12/6 Christian Grobmeier :
> 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 the
On Thu, Dec 6, 2012 at 12:43 PM, Rene Gielen 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 t
2012/12/6 Rene Gielen :
> 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
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 full
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 S
On Thu, Dec 6, 2012 at 11:44 AM, Lukasz Lenart wrote:
> 2012/12/6 Christian Grobmeier :
>> 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
2012/12/6 Christian Grobmeier :
> 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, d
On Thu, Dec 6, 2012 at 11:13 AM, Lukasz Lenart wrote:
> 2012/11/28 Dave Newton :
>> 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'
2012/12/6 Lukasz Lenart :
> 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
2012/11/28 Dave Newton :
> 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 l
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 wrote:
> On Thu, Nov 29, 2012 at 11:14 AM, Lukasz Lenart
> wrote:
> > Hi,
> >
> > I found that [1], what d
On Thu, Nov 29, 2012 at 11:14 AM, Lukasz Lenart 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
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-un
__
>> From: Rene Gielen
>> To: Struts Developers List
>> 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 ou
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
On Wed, Nov 28, 2012 at 8:36 PM, Lukasz Lenart wrote:
> 2012/11/28 Rene Gielen :
>> Moving development to the Git infrastructure ASF / Infra now provides is
>> *not* a no-brainer, and it requires a little bit more than just a few +1s :)
>>
>> Let's step back, hold breath, and dive into serious dis
2012/11/28 Chris Pratt :
> Would it be possible to write the internal code to use the JSR-330 API and
> supply Guice as the default, rather than tying the system directly to
> Guice? It seems like there would be an advantage to allowing the internal
> and external injections to potentially share a
2012/11/28 Dave Newton :
> We'll always rely on external libraries--and as has been mentioned,
> our core competency isn't DI frameworks, nor should it be.
Always something new :-)
> I'm not sure an XML config layer would be that difficult to build, but
> even if it is, wouldn't it be preferable
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
> >>
> >>
> >> _
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
2012/11/28 Dave Newton :
> IMO I'd rather see the internal mechanism be able to evolve and make use of
> vetted improvements instead of remaining in the land of Guice of 5+ years
> ago. Newer Guice has more capabilities.
I thought (and still do) a lot about that and I'm not convinced to
replace pr
2012/11/28 Rene Gielen :
> Moving development to the Git infrastructure ASF / Infra now provides is
> *not* a no-brainer, and it requires a little bit more than just a few +1s :)
>
> Let's step back, hold breath, and dive into serious discussion about
> that. I'm preparing a more detailed post, but
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
>>
>>>> Perhaps I am too old and have been in the consulting business too long,
>>>> but to change the internal DI facility -- which is working beautifully --
>>>> merely for the sake of changing seems to be an unnecessary risk.
>>>>
>>>>
>
>
>>>
>>> My two cents.
>>>
>>> Jeff
>>>
>>>
>>>
>>> From: Rene Gielen
>>> To: Struts Developers List
>>> Sent: Wednesday, November 28, 2012 3:58 AM
>>> Subjec
ess 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
>>
>>
>> ________
>&g
: Rene Gielen
> To: Struts Developers List
> 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 pos
: Struts Developers List
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
___
> From: Paul Benedict
> To: Struts Developers List
> 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 dependen
You have to differentiate between XWork's internal injection and the
injection abstraction towards user code to support pluggable dependency
injection implementations. The latter one we surely would not want to
drop, and as a matter of fact we are already supporting JSR 330 with the
Spring, Guice a
'm with Dave when it comes
>> to incorporating the version number in the package name.
>>
>> Just my two cents.
>>
>>
>>
>> ____________
>> From: Jeff Black
>> To: Struts Devel
, 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 su
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, 20
2012/11/28 Paul Benedict :
> 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/
What about dropping XWork injection support for JSR 330 (Commons DI)?
On Wed, Nov 28, 2012 at 12:41 AM, Lukasz Lenart 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 API
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 releas
2012/11/28 Dave Newton :
> 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
>
he 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: m...@raibledes
rupt this transmission...Thank You
> > Subject: Re: Plan for Struts 3
> > From: m...@raibledesigns.com
> > Date: Tue, 27 Nov 2012 15:59:51 -0700
> > To: dev@struts.apache.org; jeffrey.bl...@yahoo.com
> >
> > If it breaks backwards-compatibility, I'd suggest
You
> Subject: Re: Plan for Struts 3
> From: m...@raibledesigns.com
> Date: Tue, 27 Nov 2012 15:59:51 -0700
> To: dev@struts.apache.org; jeffrey.bl...@yahoo.com
>
> If it breaks backwards-compatibility, I'd suggest not doing it. I've always
> been impressed wi
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
> To: Struts Developers List
> Sent: Thursday, November 22, 2012 5:35 AM
>
50 PM
Subject: Re: Plan for Struts 3
Is it really necessary to alter the package name?
From: Lukasz Lenart
To: Struts Developers List
Sent: Thursday, November 22, 2012 5:35 AM
Subject: Re: Plan for Struts 3
2012/11/22 Dave Newton :
> How useful is the Struts
Is it really necessary to alter the package name?
From: Lukasz Lenart
To: Struts Developers List
Sent: Thursday, November 22, 2012 5:35 AM
Subject: Re: Plan for Struts 3
2012/11/22 Dave Newton :
> How useful is the Struts 1 plugin?
It's mentio
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 wrote:
> 2012/11/27 Paul Benedict :
> > Lukasz, you can... but the S1 plugin
2012/11/27 Paul Benedict :
> 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 u
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 wrote:
> 2012/11/26 Dave Newton :
2012/11/26 Dave Newton :
> 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
2012/11/26 Ken McWilliams :
> 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 bu
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 mu
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 wrote:
> 2012/11/22 Lukasz Lenart :
>> 201
2012/11/22 Lukasz Lenart :
> 2012/11/22 Dave Newton :
>> 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 pack
2012/11/22 Dave Newton :
> 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 unsubscrib
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" wrote:
> 2012/11/22 Christian Grobmeier :
> > Plugins would probably break. But they could break even when we sti
1 - 100 of 106 matches
Mail list logo
