This is how most frameworks do it, with continuations. This is essentially
trying to do client side storage on the server. The reason it stores
information like that is because of the Back/Forward buttons and multiple
windows. All of which are client side interactions without a server-side
logging API because we wanted to keep that boundary
between the app and the framework. Sometimes, strict boundaries are a
very good thing.
Don
On Wed, Dec 9, 2009 at 4:38 AM, Brian Pontarelli br...@pontarelli.com wrote:
Why do you say that and do you have specific examples? JCatapult uses
places that have the Container
instance injected, as they need to query it directly. JSR 330 is too
narrowly scoped to fully abstract DI, as folks like Gavin have been
quick to point out.
Don
On Wed, Dec 9, 2009 at 2:47 PM, Brian Pontarelli br...@pontarelli.com wrote:
I believe
On Dec 9, 2009, at 2:47 PM, Wes Wannemacher wrote:
Don,
I started another thread to talk about the API issue, but for this I
want to give you my take. The Managed Beans JSR I started reading
the other day does offer a few useful features that we don't have. One
is the conversation scope,
of change could be too big for a 2.x release I think
musachy
On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli
br...@pontarelli.com wrote:
We could probably make a list and verify. I think the API should be
pretty comprehensive about a lot of those things.
-bp
On Dec 1, 2009, at 11
JSR 299 is EE while 330 is SE.
-bp
On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote:
I've been loosely following the thread. It sounds like three DI
projects are being/will be supported:
* XWork
* Guice
* JSR-299/JSR-330
Why three? I can understand the last because it's EE, but the
, Paul Benedict wrote:
Then what was the point of getting the IP for XWork?
On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com wrote:
JSR 299 is EE while 330 is SE.
-bp
On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote:
I've been loosely following the thread
to continue such support. Split in
two, this would hopefully also address Don's concern of the code base
being too big.
Lastly, because Bob Lee is a Struts committer, you should get pretty
good support from him on.
Paul
On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli br...@pontarelli.com wrote
It looks like this code is against the JEE WebBeans injection stuff (299). The
JSR that Guice will be implementing is 330, which is a JSE injection model.
-bp
On Dec 7, 2009, at 9:35 AM, Wes Wannemacher wrote:
Is this 299 or 330? I have been meaning to read the spec, and this
confused me...
I'd suggest using Guice trunk and the JSR annotations rather than the Guice
annotations. I'd also make the injector pluggable so that people can plug in
Spring/Guice/etc easily.
-bp
On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote:
I have talked to a couple of people before and everyone
and in maven central? which is usually a pain point when it
comes to Sun APIs.
musachy
On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote:
I'd suggest using Guice trunk and the JSR annotations rather than the Guice
annotations. I'd also make the injector pluggable
1, 2009 at 10:21 AM, Brian Pontarelli
br...@pontarelli.comwrote:
They'll be part of the Guice distribution and under ASLv2 since Guice uses
that.
The real question is how to setup the Injector's. I tend to think this
layout would be best:
Base
on Struts.
(*Chris*)
On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli
br...@pontarelli.comwrote:
They'll be part of the Guice distribution and under ASLv2 since Guice uses
that.
The real question is how to setup the Injector's. I tend to think this
layout would be best
what we need, which I am
not sure if it is in the spec or not (havent read it), like:
* create/inject objects and statics (duh)
* lookup all implementation by type
that's all I can think off the top of my head.
musachy
On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com
I still think that the simplest approach is still to do nothing except
for EL and let the view technology do it all (JSP, FTL, VM, etc.). The
only time you need anything remotely similar to EL is for getting and
setting values out of beans. This is generally not EL handling, but
basic
get some folks to look at it. With the parameters problem solved,
the rest is not *that* hard.
On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli br...@pontarelli.com
wrote:
I still think that the simplest approach is still to do nothing
except for
EL and let the view technology do it all (JSP
I was never big on the Servlet or Filter models. It seems to me that
Struts2 is moving heavily towards conventions and the more things are
just pluggable the easier it will be for users. I feel that the best
approach would be for Struts2 to discover SiteMesh in the class path
and wire it
)! If the convention of Struts is to
configure and deploy everything, including JSP dispatcher, etc. then
I love the idea!
-- Christian
On Oct 23, 2009, at 11:13 AM, Brian Pontarelli wrote:
I was never big on the Servlet or Filter models. It seems to me
that Struts2 is moving heavily
On Oct 23, 2009, at 10:10 AM, Christian Stone wrote:
On Oct 23, 2009, at 12:01 PM, Brian Pontarelli wrote:
I've done some work with it and it looks to be completely
pluggable. I do this same thing in JCatapult with other libraries.
Essentially, I define a workflow chain
From my conversations with Joe, integration will be much simpler with
the next version. I'm looking at using the next version so that all
the templates are FreeMarker and I will be able to create my own
FreeMarker root context. It also looked like everything was going to
be extendable or
I just finished a massive license audit for some internal things. It
is an enormous pain. GPL is incompatible with ASL because of the
redistribution portions of the licenses. ASL lets you redistribute
without any restrictions. This allows commercial software to ship ASL
Jar files inside
Actually, I think this is in regards to the JSF validation attributes
yo can specify on the JSF tags. I believe that this either does some
serialization magic or some session magic to connect the attributes
specified on the tags with the server-side validator. I think it looks
like:
Does this plugin provide for executing the JSPs in unit tests?
Embedding is really nice, but unit testing is even better.
-bp
On Aug 13, 2009, at 12:27 PM, Wes Wannemacher wrote:
I think it is a good idea, as much as I dislike JSP (because it is so
non-portable, which this very plugin
Except the API changes. Remember that any API change that breaks
someone should be a major release. That's why people work so hard on
keeping old APIs around.
Sent from my iPhone
On Aug 12, 2009, at 3:45 PM, Wendy Smoak wsm...@gmail.com wrote:
On Wed, Aug 12, 2009 at 2:36 PM, Paul
On Aug 10, 2009, at 11:52 PM, Don Brown wrote:
On Tue, Aug 11, 2009 at 3:38 PM, Paul Benedictpbened...@apache.org
wrote:
On Tue, Aug 11, 2009 at 12:22 AM, Don Brown
donald.br...@gmail.com wrote:
By forking XWork, we can a) bring core Struts 2 code into the
project
where it belongs and
Personally, I feel that struts top to bottom should be web centric and
not try to abstract out JEE. This makes life cumbersome and difficult
in many cases. Often this also leads to hacking interfaces or writing
tricky new semantics on top of more general interfaces in order to get
access
I'm all for this ;) (http://markmail.org/message/nykgr354ts4hlkif)
-bp
On Aug 5, 2009, at 11:12 PM, Don Brown wrote:
XWork was left at OpenSymphony, because at the time, there were a
number of WebWork developers still around and we wanted to continue to
work together. Today, WebWork
I would say the reason you don't want to dive into 233 would be
primarily because of performance. You'd either need to have a compiled
statement cache or pre-compile. Most of the scripting frameworks that
comply with 233 are full blow languages (Groovy, JavaScript, etc) and
have pretty
I sorta figured it would be pretty slow. You might also run into some
issues with the APIs depending on how you want to handle type
conversion stuff.
The JCatapult EL is mostly decoupled from the rest of the framework
except that I use the JCatapult ObjectFactory to create instances of
Yeah, same here. Everything broke down when it came to two use cases:
- The difference between a user type conversion error (user puts in
'a' in a text box that is mapped to an Integer field property) and a
developer type conversion error (developer didn't specify the date
format for a
-
From: Brian Pontarelli [mailto:br...@pontarelli.com]
Sent: 10 April 2009 16:12
To: Struts Developers List
Subject: Re: Google App Engine support?
Interesting. On the Guice list there is another thread about GAE.
You should
submit a bug for Sitemesh to Google and to the Sitemesh
maintainers
Interesting. On the Guice list there is another thread about GAE. You
should submit a bug for Sitemesh to Google and to the Sitemesh
maintainers. Google seems to be up for fixing some of these issues.
This one looks like either a JNDI bug or JNDI security measure (my
guess is the later).
() {
return start.toDate();
}
public void setStartDate(Date start) {
this.start = new DateTime( start) ;
}
Si quieres ser más positivo, pierde un electrón
Miguel Ruiz Velasco S.
On Wed, Dec 17, 2008 at 09:46, Brian Pontarelli
br...@pontarelli.com wrote
Date is pretty much deprecated except for a way to carry a long
primitive around because of the TZ and conversions it lacks. It fails
in some cases and most of the core API on Date is deprecated. Most
folks should be using Calendar for date and time correctness if they
don't want to use
Anyone that had contacted Garrett about MSDN subscriptions, I talked
with MSDN support the other day and it looks like the subscriptions
were created on 10/31, just not activated and associated with each
persons account. I sent Garrett an email this morning to inquire and
I'll let you
* OGNL - Is is staying? Is it going? Can it be secure? Is it fast
enough?
I say drop it completely. No more evaluation in the JSPs or FTL files
at all and use MVEL for the parameters interceptor. FTL has a good
enough language and you have Java in JSPs if you need it. OGNL in
there is
talk.
Brian Pontarelli wrote:
Not sure I follow. If I compile an expression, how can I reuse the
compiled version? I would assume it would need to be in a cache where
the key is the expression String and the value is the compiled
version. Correct me if I'm wrong.
-bp
P.S. based on your knowledge
.
Compiled performance was: 5.8ms to 34.2ms in favor of MVEL too.
So I would err on the side of performance here. If that doesn't cut
it for
web applications, I guess that's fine. I don't really target MVEL
towards
web applications, really.
Brian Pontarelli wrote:
Taking a brief look
efficient sliding-window parser.
Brian Pontarelli wrote:
Right, but you can receive similar or better performance using a
linear runtime evaluation if the language is simple enough and tuned
for the web. And as you and I say, MVEL and most other languages
aren't targeted to the web and have many extra
Brock wrote:
Well, I'd like to see an actual comparison. I somehow doubt your
parser,
which I note is using StringTokenizer will perform as well as MVEL's
parser,
which is a much more computationally efficient sliding-window parser.
Brian Pontarelli wrote:
Right, but you can receive similar
not generic, and a bit of a pain
in the
butt to test in isolation.
Brian Pontarelli wrote:
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and
let
me know what you get. StringTokenizer is obviously quite fast
to test in isolation.
Brian Pontarelli wrote:
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and
let
me know what you get. StringTokenizer is obviously quite fast, and I
could easily remove it if it would mean sub
);
long start = System.currentTimeMillis();
for (int i = 0; i iterations; i++) {
MVEL.executeExpression(s, entityObj);
}
System.out.println(compiled time: + (System.currentTimeMillis()-
start));
Brian Pontarelli wrote:
Send me code for MVEL and I'll run both. It will be much easier for
you
Sure. But OGNL will return similar results with 50 tests. Yet
people have
run into performance problems. The issue is that you're not looking
at
performance in terms of resource contention, and in terms of aggregate
resource usage.
I'd say that for web application expressions OGNL and
, or JEXL. This is actually, from an
architectural
perspective what makes MVEL stand apart from these technologies.
Brian Pontarelli wrote:
Sure. But OGNL will return similar results with 50 tests. Yet
people have
run into performance problems. The issue is that you're not looking
the conditions of this.
Brian Pontarelli wrote:
Sure. But OGNL will return similar results with 50 tests. Yet
people have
run into performance problems. The issue is that you're not looking
at
performance in terms of resource contention, and in terms of
aggregate
resource usage.
I'd say
. Since it's
source-from-many in it's design, you can easily design converters that
perform as much introspection as necessary to determine formatting,
etc.
Brian Pontarelli wrote:
Yeah. That's good. The last thing I would toss in as criteria is a
good type conversion interface. In JCatapult, I
information, and
provide
automatic coercion and verification accordingly. MVEL's type
verifier will
always extrapolate whatever type data is available.
Brian Pontarelli wrote:
This is not quite the same unless it can detect generics while
setting
values and creating values. An example
+Mode
Brian Pontarelli wrote:
On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
Just to muddy the EL/templating waters:
http://mvel.codehaus.org/Performance+of+MVEL
(v. OGNL)
Not sure about MVEL or OGNL at this point, but everything was lacking
in support for generics, collections and arrays
On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
Just to muddy the EL/templating waters:
http://mvel.codehaus.org/Performance+of+MVEL
(v. OGNL)
Not sure about MVEL or OGNL at this point, but everything was lacking
in support for generics, collections and arrays. I wrote my own for
the
As I'm never a big fan of relying solely on the fact that technologies
have been used, I'd compare feature sets. Here's what I like from GXP:
- Pre-compile for performance
- Type safe
- Injectable
- White space reduction
- l10n and i18n support (although difficult to determine exactly how
IJ 8.0 has built in FTL support. EAPs are currently available.
-bp
On Jul 27, 2008, at 8:36 AM, Rene Gielen wrote:
I Like it very much, from what I can tell from a first glance. In
addition to the interesting features, it should be nice to work with
an
IDE like IDEA (which still lacks fm
I wrote my own for the JCatapult MVC and it does most of the parameter
setting stuff that OGNL does and a few other things like handling
generics correctly and completely. It also has a pretty solid type
conversion API. Took about 3 days to write, test and complete. Feel
free to grab the
I think we both agree that configuration is best. In fact I think you
even support environment awareness in configuration system. So, from
that perspective we are solid. The rest is just debating personal
style and developer freedom. I will answer a few things below, but I
think we can
, but it should be
up to the environment manager to manage the configuration, and not
up to the developer to dictate what is correct.
Al.
Brian Pontarelli wrote:
Wow. This got way off topic, but I'm compelled to answer. ;)
Your assumption about QA being the only problem is incorrect
short-sighted in my opinion.
-bp
Al.
Brian Pontarelli wrote:
I've written code that uses environment. Of course, I mainly write
frameworks, so it probably makes more sense there, but I have used
environment to dictate code rules. Eager singletons versus on-
demand singletons, class
I've kind of lost track of the original point anyway :/
Al mentioned that adding environment awareness to JSF makes people
lazy. I jumped in and stated I disagreed and that adding this just
allows people that need it to use it. From what I've gathered thus far
(Al correct me if I'm
the same WAR file that was accepted by the quality
assurance group into production and let the configuration take care
of
itself.
I've often thought of creating a Google Code project to open source
it, but wasn't sure if there would be enough interest.
(*Chris*)
On Fri, Jun 27, 2008 at 1:38 PM, Brian
a lazy solution to me, whats needed is
better QA, not a solution which makes people sloppy because they
think that the code will catch their mistakes.
Al.
Brian Pontarelli wrote:
I think this is an over-simplification of a complex problem. Here
are a few examples from orbitz.com
Yeah, I found that environment resolution was a key feature for any
large application. At Orbitz we could deploy the same bundle to any
server and the bundle would figure out where it was and configure
itself for that environment. Worked really well.
I have also provided this type of
Al Sutton wrote:
Brian,
Dependencies can be reduced to simple ordered lists unless there is a
requirement for two plugins to be run in parallel (which is pretty
rare), or you have a circular dependency. Reduction of dependency
graphs is something I've come accros dependency declaration
the UnknowHandler
problem calls for an easy solution, and over-architecturing the whole
thing would be bad. BTW, specifying the order in which plugins will be
loaded wouldn't solved the UnknowHandler problem.
my 2 pesos :)
musachy
On Tue, Jun 3, 2008 at 11:37 AM, Brian Pontarelli
[EMAIL PROTECTED] wrote:
I
to be able to specify an order.
Al.
Musachy Barroso wrote:
I like Dusty's suggestion, or something like it:
unknown-handlers
unknown-handler name=UH1 /
unknown-handler name=UH2 /
/unknown-handlers
musachy
On Mon, Jun 2, 2008 at 2:36 PM, Brian Pontarelli
[EMAIL PROTECTED] wrote
Musachy Barroso wrote:
For those of you ignoring the spam on the Convention vote thread :). I
mentioned that the framework should support more than one
UnknownHandler, which would eventually make Convention and Codebehind
compatible, as well as other plugins in the future. The bad side
effect is
type of integer based indexing for each Workflow, but these all
seem pretty lame.
-bp
Musachy Barroso wrote:
Do you have an implementation of this already?
musachy
On Mon, Jun 2, 2008 at 1:21 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Musachy Barroso wrote:
For those of you
Secondly, I was wondering about the advantages of having fewer
dependencies, especially in this maven era. If something's really
great, it's fine to depend on it, surely?
And there is still a large number of folks using Ant, Ivy and Savant.
-bp
Just a quick question. How did you modify ClasFinder to check for
implementation of the XWork Action interface? Doesn't this need to parse
up the inheritance chain as well as the implementation chain? It didn't
look like ClassFinder currently did that, unless I missed it.
-bp
Musachy
is one of them
musachy
On Thu, May 29, 2008 at 11:47 AM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Just a quick question. How did you modify ClasFinder to check for
implementation of the XWork Action interface? Doesn't this need to parse up
the inheritance chain as well as the implementation chain
it's all Apache license and only 3 classes so we could just pull it into
XWork and manage it there.
On Wed, May 28, 2008 at 3:24 PM, dusty [EMAIL PROTECTED] wrote:
If you already have it working, then great! I don't know anything about
it,
so my question is only how likely are the authors
The plugin will scan the entire classpath, but that's not to large of an
issue and pretty fast (considering). The issue is when it starts loading
classes into the perm space to determine if the class is in fact an
Action or not. This is the part where your perm space can become full
and then
BTW, I'd like to thank Musachy for taking charge of this. Having started
my own company in Feb. I have barely had time for anything open source.
Hopefully this can make it over and users can jump on board with it. It
really makes Struts2 development so much simpler and JCatapult is
+1
Here are the goals of this plugin. Any movement to integrate plugins and
make all things compatible (which I gracefully disagree with) MUST
satisfy these goals:
- Simple API that is fixed and will not change anytime soon
- Usable with absolutely no configuration or annotations
-
, does this plugin effectively make codebehind and
smarturls obsolete?
Thanks again.
--
From: Brian Pontarelli [EMAIL PROTECTED]
Sent: Wednesday, April 23, 2008 10:20 AM
To: Struts Developers List
this plugin effectively make codebehind and
smarturls obsolete?
Thanks again.
--
From: Brian Pontarelli [EMAIL PROTECTED]
Sent: Wednesday, April 23, 2008 10:20 AM
To: Struts Developers List dev@struts.apache.org
assignee's. All is well now.
-bp
Musachy Barroso wrote:
Done
On Tue, May 13, 2008 at 10:58 AM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Agreed.
Musachy Barroso wrote:
Another thing is that the convention plugin is using
java.util.logging.*. I think we should stick to what we have
Musachy Barroso wrote:
I think FilterDispatcher should be changed to allow other
implementations to lookup static resources and be more flexible in
general. As it stands right now, static resources cannot be served
from plugins unless you put them in org.apache.struts2.static in a jar
loaded by
Jeromy Evans wrote:
Putting aside the technology for a moment:
- ability to deploy new actions/replace actions and pages without a
container restart: highly desirable
Only at development stage right? There are tools that use JDPA and other
methods to do this with Struts and other frameworks.
be
solved by a tool. This problem is a compile time problem that needs to
be handled by developers. OSGi is a runtime dynamic loader, not a
compile time dynamic method binder or a runtime dynamic method
invocation layer.
-bp
Don
On Sat, Apr 26, 2008 at 3:45 AM, Brian Pontarelli [EMAIL PROTECTED
Here's a few things I think about when considering API versioning:
1. How many implementors are there? It sounds like there will be one -
Struts2
2. Do you want to allow implementors to implement multiple APIs? Sounds
like yes.
3. How much is shared between APIs? Probably a lot.
From what it
with Brian that
there will be a burden on s2 to provide the necessary features for all
APIs, but I think it's less of a burden in this layout.
/Ian
Brian Pontarelli wrote:
Here's a few things I think about when considering API versioning:
1. How many implementors are there? It sounds like
of compatibility and something I feel Struts
needs to start ensuring.
-bp
/Ian
Brian Pontarelli wrote:
Yours and mine are the same because you still have implementations
inside Struts for some of the API interfaces. For example,
org.apache.struts2.config.PackageProvider (yeah, I did move
Bob Tiernay wrote:
Anyone know what the status of the Convention plugin is? Is there
anyways we can get it out of the sandbox and into a formal release?
I'm willing to help out :)
The plugin is stable and running in production. It can probably be moved
out of the sandbox whenever we want. At
You can definitely inject from any of the XWork files,
struts-default.properties, struts.properties, struts.xml,
struts-default.xml, struts-plugin.xml. These are all configured in the
Dispatcher when the Container is created (I think).
-bp
Musachy Barroso wrote:
I tried that, I think the
Yeah, I was hoping to have time to get the convention plugin into the
main repository, but I just haven't had anytime at all. It will have to
wait until 2.2 unless someone else wants to move it over. At this point
I can't even recall the outstanding issues and design changes that were
being
Haroon Rafique wrote:
On Yesterday at 11:37am, BP=Brian Pontarelli [EMAIL PROTECTED] wrote:
BP
BP BTW, some of the JetBrains folks said that FreeMarker support will be
BP in 8 and should be available in EAP soon! This will definitely help
BP move me farther away from JSPs. :)
BP
BP -bp
BTW, some of the JetBrains folks said that FreeMarker support will be in
8 and should be available in EAP soon! This will definitely help move me
farther away from JSPs. :)
-bp
Jeromy Evans wrote:
Jonathan Revusky wrote:
Thanks for the detailed argument Jonathon.
Jeromy Evans wrote:
- Overhaul message passing so that action errors and action messages
could be persisted through redirects with no user configuration or
validation issues.
Scopes plugin works pretty well from what I've heard.
- Overhaul zero configuration to allow results to be defined at method
level
Here's my list:
- Collapse XWork into Struts
- Rewrite XWork to be a servlet workflow engine and less abstract (i.e.
remove thread locals and contexts)
- Fix nasty circular XWork injections and setter injections
- Generics
- Update all public APIs no matter how infrequently used and then hard
Can someone that has a lot of experience with ValueStack evaluation help
me get a test working? The test in question is currently commented out
at the bottom of the UIBeanTest.
The purpose is to verify that if the 'key' attribute contains any single
quotes they are correctly escaped prior to
There are two discussions going on here that could probably be split:
1. OGNL vs. JUEL
2. Taglibs
#1 has already come up a number of times and I believe that there is
enough support to move the JUEL plugin forward and start removing OGNL
once a roadmap is clear. The wiki page Dale pointed to
Correct me if I'm wrong but I believe that restricts the map to only
accepting values that are exactly Object. It will not allow things
that extend Object, only Object themselves. You could use:
MapString,? extends Object
Which is just a long-hand way of saying:
MayString,?
You can't
David Durham, Jr. wrote:
On Thu, Mar 6, 2008 at 2:42 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
You can't put things into Maps that have wildcards. The compiler
complains because Object really isn't '?'. Although most language
pragmatist would tell you it is. But the language zealots
Dale Newfield wrote:
Chris Pratt wrote:
The proposed flow (with rtexprvaluefalse/rtexprvalue):
The bit you're missing is that if you have a tag attribute with
rtexprvalue set to false that contains what the container thinks is an
EL expression (i.e., ${foo}), the jsp compilation will fail,
Wendy Smoak wrote:
On Sun, Feb 24, 2008 at 1:04 AM, Don Brown [EMAIL PROTECTED] wrote:
Unfortunately, my computer is experiencing severe stability problems,
so the Struts 2.1.1 build will be delayed. I'm hoping to give it a
shot next weekend. Of course, anyone is free to give it a go in
Before you start such a discussion, I would suggest that you take the time
to look back, in the archives, through the several years worth of
discussions in that got us to the point we're at today, so that you _fully_
understand the context and the reasoning behind the scheme that we have now.
I
Al Sutton wrote:
Just so we're all on the same page, can I put forward the following as
a version numbering plan which would seem to reflect most peoples views;
2.0.x - New releases shouldn't alter the public API unless absolutley
neccessary (e.g. something is a security risk).
2.1.x
Antonio Petrelli wrote:
Wow what a long thread and all in the night :-) (well, at least for Europe).
Sincerely I don't see the problem of changing the name of Struts 2.1.x to
Struts 3.0.x. It's just a version name change.
IMHO if you change the API (read: public, protected and package-friendly
Al Sutton wrote:
Antonio,
I see where you're coming from, but I really don't think the leap from
S2.0 to the current S2.1 is anywhere near the leap from S1 to S2,
hence why I'm in favour of the 2.1 because I feel it reflects that
although there are some changes, many of the core concepts are
Piero Sartini wrote:
Am Freitag, 22. Februar 2008 00:05:53 schrieb Don Brown:
Yes, you are missing my original point #2 - We need to be able to do
alpha releases to get new, experimental features into the community
for testing. I need a way to create an alpha release for 2.1 to hand
off to
, Feb 21, 2008 at 7:03 PM, Brian Pontarelli [EMAIL PROTECTED]
wrote:
Don Brown wrote:
Yes, you are missing my original point #2 - We need to be able to do
alpha releases to get new, experimental features into the community
for testing. I need a way to create an alpha release for 2.1
1 - 100 of 282 matches
Mail list logo
