2013/3/20 Paul Benedict :
> Ah, well, the only unfortunate problem with calling it 2.5 is that you
> already have a 2.3. No one is going to realize you intend it as a half-jump
> release (like Tomcat 5.0 and 5.5). There will likely be confusion why a
> point release dropped so much support, but if
Ah, well, the only unfortunate problem with calling it 2.5 is that you
already have a 2.3. No one is going to realize you intend it as a half-jump
release (like Tomcat 5.0 and 5.5). There will likely be confusion why a
point release dropped so much support, but if we advertise in big bold
letters t
2013/3/19 Paul Benedict :
> Don't you think it will raise questions (and eyebrows) why Struts 3 has a
> struts 2 package name?
That's why we should call it S2.5, in other words when package name
remains unchanged it shouldn't be called S3 ;)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.
Don't you think it will raise questions (and eyebrows) why Struts 3 has a
struts 2 package name?
Paul
On Tue, Mar 19, 2013 at 4:29 PM, Lukasz Lenart wrote:
> 2013/3/19 :
> > My thoughts its a good way to keep a separate package name ? One
> question Do the S3 architecture will change ?
>
> No
2013/3/19 :
> My thoughts its a good way to keep a separate package name ? One question Do
> the S3 architecture will change ?
No, it will be the same as S2. The plan is ti just remove deprecated
parts and cleanup the code base
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
-
Reply-To: "Struts Developers List"
Subject: Re: Struts 3 package name
Using the Shade plugin is an option as long as I can shade everything
appropriately. I don't know if that's a really good choice as opposed to a
separate package name.
Paul
On Mon, Mar 18, 2013 at 12:48 PM
Good point! If it is that easy, then sure.
On Tue, Mar 19, 2013 at 10:11 AM, Lukasz Lenart wrote:
> 2013/3/19 Paul Benedict :
> > It's a good thought, but if you do that, then there's no incremental
> > migration path between S2 and S3.
>
> I don't know if is needed, as we just said that the S3 s
2013/3/19 Paul Benedict :
> It's a good thought, but if you do that, then there's no incremental
> migration path between S2 and S3.
I don't know if is needed, as we just said that the S3 should be
better S2 - migrating between them should be easy.
Regards
--
Łukasz
+ 48 606 323 122 http://www.
It's a good thought, but if you do that, then there's no incremental
migration path between S2 and S3.
On Tue, Mar 19, 2013 at 10:02 AM, Lukasz Lenart wrote:
> 2013/3/19 Paul Benedict :
> > If we name the Java package "org.apache.struts3", we will keep a
> migration
> > path open for *both* S1 an
2013/3/19 Paul Benedict :
> If we name the Java package "org.apache.struts3", we will keep a migration
> path open for *both* S1 and S2. The perspective we should have, I think, is
> that we are one of many front-end technologies and it's *necessary* for
> multiple versions of Struts to be used at
If we name the Java package "org.apache.struts3", we will keep a migration
path open for *both* S1 and S2. The perspective we should have, I think, is
that we are one of many front-end technologies and it's *necessary* for
multiple versions of Struts to be used at the same time. Even if it is not
n
2013/3/18 Paul Benedict :
> I professionally work on a huge project where S1 is used everywhere. The
> best upgrade path for us is to put S2 in the web container, write new
> actions in S2, and convert the old S1 actions during maintenance. This
> scheme is only possible because S2 uses a different
Using the Shade plugin is an option as long as I can shade everything
appropriately. I don't know if that's a really good choice as opposed to a
separate package name.
Paul
On Mon, Mar 18, 2013 at 12:48 PM, Maurizio Cucchiara
wrote:
> Before reading Lukasz's message [1], probably I would have sa
Before reading Lukasz's message [1], probably I would have said that
changing the package name to struts3 would have been a good idea.
After all, many Apache Commons projects have chosen this schema.
As you know, you can use two versions of commons lang without experiencing
any problem.
However, I
I professionally work on a huge project where S1 is used everywhere. The
best upgrade path for us is to put S2 in the web container, write new
actions in S2, and convert the old S1 actions during maintenance. This
scheme is only possible because S2 uses a different package name.
If S3 is going to
15 matches
Mail list logo
