Hi!
I spot that the apache-7.pom is defining it owns Maven release profile
called release-profile. Please correct me if I'm wrong, but I think
the Maven release profile should be removed from struts-parent.pom and
we should base on what was defined in apache-7.pom
The only reference I found is he
Hi all!
I forgot to remove staging and snapshot section from struts-parent.pom :-(
As I understand, I must rollback release, remove tag and clean up
people.a.o:/www/people.apache.org/builds/struts/2.2.0/ ?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010 ht
You should be congratulated on bringing the number of lines of Struts
source up to par with Microsoft Windows.
On Wed, Jun 23, 2010 at 11:01 AM, Lukasz Lenart
wrote:
> Still something wrong, this time with struts-2.2.0-source-release.zip
> - growths over 13 GB!!!
>
>
> Regards
> --
> Łukasz
> + 4
Still something wrong, this time with struts-2.2.0-source-release.zip
- growths over 13 GB!!!
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010 http://javarsovia.pl
-
To unsubscribe, e-mail:
I've got it :D
http://www.mail-archive.com/d...@felix.apache.org/msg09989.html
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010 http://javarsovia.pl
-
To unsubscribe, e-mail: dev-unsubscr...
On 6/23/10 8:43 AM, Lukasz Lenart wrote:
Input file does not exist:
target/maven-shared-archive-resources/META-INF/DEPENDENCIES~
target/maven-shared-archive-resources/META-INF/LICENSE~
target/maven-shared-archive-resources/META-INF/NOTICE~
Some editors save backup versions of files in "~"...is
I stuck with this issue during maven release:prepare:
ERROR] Error building bundle
org.apache.struts:struts2-osgi-admin-bundle:bundle:2.2.0 : Input file
does not exist:
target/maven-shared-archive-resources/META-INF/DEPENDENCIES~
[ERROR] Error building bundle
org.apache.struts:struts2-osgi
On 6/22/10 10:40 AM, Lukasz Lenart wrote:
I start Maven release process
Lukasz++ !
-Dale
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
As no one is complaining so I start Maven release process today
evening (as for GMT+1).
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010 http://javarsovia.pl
2010/6/20 Lukasz Lenart :
> Hi,
>
> I'm ready to make a new Maven release. Is there anything to che
Hi,
I'm ready to make a new Maven release. Is there anything to check /
look before ?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010 http://javarsovia.pl
-
To unsubscribe, e-mail: dev-uns
On Saturday 12 December 2009 00:24:41 Dale Newfield wrote:
> Gabriel Belingueres wrote:
> > built-in the web framework
>
> In order to do this we'd need to add in some information in the form and
> in every link leading from one page of the form to another so that it's
> constantly submitted to th
-
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>
>
--
View this message in context:
http://old.na
Alex:
Actually I've chosen the "conversations in web applications" subject
for my thesis, and I intended to demonstrate a working conversation
implementation using S2 as the code base (nice candidate framework
since it doesn't support them and I have some much experience with it
from my daily work.
Tom is the owner, he wrote it and gave me access. I was going to fix
it up for SWF 2, but after my struts project got shot down I never
touched it. If anyone wants to help with it let me know, I don't have
any plans to update it myself, but I could help.
musachy
On Tue, Dec 15, 2009 at 9:57 AM,
I have take a look at SWF plugin (http://code.google.com/p/struts2webflow/)
and it seems like that development stopped:
http://code.google.com/p/struts2webflow/issues/detail?id=19
Musachy, I see you in the "Project owners". Do you have any plans on that
plugin?
Gabriel, do you have a will to fix
That's what I said. I honestly don't see the point in reinventing the wheel :)
On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman wrote:
>
> Who would implement all of these features? So many work and potential bugs...
>
> Maybe it's the way easier to update SWF plugin to version 2?
>
> Gabriel Belingue
Who would implement all of these features? So many work and potential bugs...
Maybe it's the way easier to update SWF plugin to version 2?
Gabriel Belingueres-2 wrote:
>
> I also agree that implementing something similar to SWF2 is not very
> compelling.
>
> However having implemented conversa
I also agree that implementing something similar to SWF2 is not very compelling.
However having implemented conversations build it in the framework
have its advantages, mostly because I'm not sure if it can be
implemented/integrated very cleanly/easily writing a third party
plugin.
I was thinking
It would be a lot easier to fix the struts plugin to work with SWF 2.
Reinventing the wheel is evil.
musachy
On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield wrote:
> Gabriel Belingueres wrote:
>>
>> built-in the web framework
>
> In order to do this we'd need to add in some information in the for
Gabriel Belingueres wrote:
built-in the web framework
In order to do this we'd need to add in some information in the form and
in every link leading from one page of the form to another so that it's
constantly submitted to the server to keep the user associated with the
right conversation.
Seems like you are implementing continuations to me.
But the point I'm trying to make is that if it is already built-in the
web framework, you don't need to do it yourself, and there are
actually production ready frameworks with this kind of functionality.
Gabriel
2009/12/11 Alex Siman :
>
> I ha
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
noti
I have created such wizard:
- simple LRU cache based on HashMap with fixed capacity, say for 5 elems;
- each cache elem collects wizard data;
- this cache stored in user session;
- each request in wizard flow pass the ID - the key of element (wizard data)
in cache;
- when wizard get finished - the
I think this case is correctly handled in SWF: Each time a request
fires a state transition, SWF saves a "continuation" of the current
data (think the Memento pattern) Serialized for later use.
When the user right-click the "next" link opening a new window, the
state transition put the flow in a ne
On Thursday 10. December 2009 20.28.48 Musachy Barroso wrote:
> guys, can you start a different thread for this? :)
You have a point there, talk about hijacking a thread:-)
--
Andreas Joseph Krogh
Senior Software Developer / CTO
+-
On Thursday 10. December 2009 20.27.32 Gabriel Belingueres wrote:
> Granted, most people implement wizards this way, but the most
> compelling use of storing state in conversation scope (IMO) is to
> allow correct behavior when a user clones a browser window, and then
> allow better support for the
guys, can you start a different thread for this? :)
On Thu, Dec 10, 2009 at 11:27 AM, Gabriel Belingueres
wrote:
> Granted, most people implement wizards this way, but the most
> compelling use of storing state in conversation scope (IMO) is to
> allow correct behavior when a user clones a browse
Chris Pratt wrote:
That seems like a very imperfect fix for an almost impossible problem.
Having an extra parameter on the link won't stop a user from right clicking
on the link and saying "open in another window" and having 2 "conversations"
with the same conversation key.
If the link followed
That seems like a very imperfect fix for an almost impossible problem.
Having an extra parameter on the link won't stop a user from right clicking
on the link and saying "open in another window" and having 2 "conversations"
with the same conversation key. To my knowledge there's just no way to
acc
Granted, most people implement wizards this way, but the most
compelling use of storing state in conversation scope (IMO) is to
allow correct behavior when a user clones a browser window, and then
allow better support for the back button. Even with conversation
support the pages still need to pass
On Thursday 10. December 2009 17.37.04 Alex Siman wrote:
>
> What if application needs expirable and parallel (say 5 instances at a time)
> wizard?
The point is that you have to save the state using the session (or DB or other
persistent storage, but I assume that's more trouble than it's worth)
90 | |
> Fax:+47 24 15 38 91 | |
> Mobile: +47 909 56 963 | |
> +-+
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
>
> Wes Wannemacher wrote:
> >
> > "Everything is tied to either the request
> > or the session, I can't build wizard-style views"
> >
> Yeah, we need wizards sometimes.
I would argue that it would be nice to have, but not a must. Most
i
Wes Wannemacher wrote:
>
> "Everything is tied to either the request
> or the session, I can't build wizard-style views"
>
Yeah, we need wizards sometimes.
--
View this message in context:
http://old.nabble.com/struts-2.2-and-guice-tp26594350p26728156.html
Sent fr
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
On Tue, Dec 8, 2009 at 11:22 PM, Don Brown wrote:
> It isn't about needing a "struts-light", it is adding unnecessary
> bulk. When I was more active, I spent a lot of time trying to kick
> out dependencies, tighten up our weak API's, and overall simplify
> interactions with the framework. If you
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, which I think Struts 2 could really
benefit from. That's
First, injecting the Container (or Injector as it is called) is allowed in the
JSR and the API is abstracted well enough that it shouldn't cause major
concerns.
On the flip-side, I contend that those instances are broken and can be fixed.
I also don't agree that 330 is too narrow. It should s
ed to use Struts 2 on a project
>>>>> here, and was a bit shocked at the size of the jar nowadays...seems we
>>>>> went a bit crazy with the shading. I'd generally advise against
>>>>> adding more bulk without obvious gains.
>>>>>
>
Don,
> JSR 330 is not the magic bullet here.
Agreed, but I would have to say it would be foolish not to support it.
As companies perform internal tech evaluations, people will eventually
realize "standard" DI injection is not supported: "Oh, our company has
to learn XWork DI? What the heck is XWo
Remember, there are quite a few 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 wrote:
> I believe tha
adding more bulk without obvious gains.
>>>>
>>>> Don
>>>>
>>>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso wrote:
>>>>> I don't know about dropping Object factory, in this case it would just
>>>>> delegate to th
On Wed, Dec 9, 2009 at 11:34 AM, Paul Benedict wrote:
> Lastly, because Bob Lee is a Struts committer, you should get pretty
> good support from him on.
Don't count on it. Bob has moved on from Struts 2, so I would count
on anything beyond moral support. :)
Don
>
> Paul
>
> On Tue, Dec 8, 2009
lk without obvious gains.
>>>>
>>>> Don
>>>>
>>>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso wrote:
>>>>> I don't know about dropping Object factory, in this case it would just
>>>>> delegate to the jsr 3
I believe that the simplest route would be to collapse everything into a single
core JAR, which includes the workflow and other core APIs. This JAR would would
use the JSR 330 annotations and a provide a couple of Module implementations. I
would then have the Struts servlet filter wire everythin
Since the XWork code is now owned by Apache (right?), you could split
it into two jars (workflow and DI). Then deprecate the DI artifact
unless someone here as aspirations to continue such support. Split in
two, this would hopefully also address Don's concern of the code base
being too big.
Lastl
XWork is more than DI. If drives the workflow under the hoods of Struts. We
would need all of that code in addition to the DI. The idea is to drop the DI
part of XWork and replace it with Guice 2.1 (which should support JSR 330) and
just pull in the rest of it.
-bp
On Dec 8, 2009, at 4:32 PM,
Then what was the point of getting the IP for XWork?
On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli 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. It sounds like three DI
>> projects are being/w
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 th
what we are proposing/talking is to use only JSR 330, which is the
spec. The actual implementation (default) would be guice.
musachy
On Tue, Dec 8, 2009 at 3:12 PM, Paul Benedict wrote:
> I've been loosely following the thread. It sounds like three DI
> projects are being/will be supported:
> *
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 other
two are proprietary.
Paul
On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart
wrote:
> In my opin
In my opinion, current DI support is sufficient (it can be made more
readable, but that's it ;-), I really don't get it what's the problem with
double ObjectFactory issue???
Regards
--
Lukasz
http://www.lenart.org.pl/
will this mean that struts 2.2 will support MVP
or any idea to put GWT also :)
F
t;> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso wrote:
>>>> I don't know about dropping Object factory, in this case it would just
>>>> delegate to the jsr 330 implementation. But getting rid of the double
>>>> object factory problem would be very nice.
roblem would be very nice.
>>>>
>>>> On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen wrote:
>>>>> I'm a huge fan of moving to Guice 2 internally, although I'm not sure if
>>>>> we would want to drop the ObjectFactory abstraction for
ase it would just
>>>> delegate to the jsr 330 implementation. But getting rid of the double
>>>> object factory problem would be very nice.
>>>>
>>>> On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen wrote:
>>>>> I'm a huge fan of
len wrote:
>>>> I'm a huge fan of moving to Guice 2 internally, although I'm not sure if
>>>> we would want to drop the ObjectFactory abstraction for plain pluggable
>>>> JSR330 DI - as this would imply that Struts 2.2 would not integrate any
>>>>
d of the double
>> object factory problem would be very nice.
>>
>> On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen wrote:
>>> I'm a huge fan of moving to Guice 2 internally, although I'm not sure if
>>> we would want to drop the ObjectFactory abstraction for
would want to drop the ObjectFactory abstraction for plain pluggable
>> JSR330 DI - as this would imply that Struts 2.2 would not integrate any
>> more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do
>> we really expect every Struts2 user and his company will be
lly, although I'm not sure if
> we would want to drop the ObjectFactory abstraction for plain pluggable
> JSR330 DI - as this would imply that Struts 2.2 would not integrate any
> more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do
> we really expect every Struts
I'm a huge fan of moving to Guice 2 internally, although I'm not sure if
we would want to drop the ObjectFactory abstraction for plain pluggable
JSR330 DI - as this would imply that Struts 2.2 would not integrate any
more against Spring 2.x, Guice 1, Plexus, PicoContainer and what
I am reading the spec and I am rather impressed, I thought it would be
a simple thing but it is really comprehensive. I doubt we will have a
use case that won't be covered there.
musachy
On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso wrote:
> It is good that you brought this up, because the do
It is good that you brought this up, because the double object factory
is annoying and creates a lot of unexpected situations(problems with
class reloading and OSGi). Having just one container would make it
easier for everybody, users and s2 developers, if it can be pulled
off.
This kind of change
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:42 AM, Musachy Barroso wrote:
> ah I see what you mean. yes that would be a good idea, I think that
> would work as long as all the containers have wh
ah I see what you mean. yes that would be a good idea, I think that
would work as long as all the containers have 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 th
Because you don't want to use separate containers. In Guice you can have
child-parent injector relationships. My thought is to just have a single DI
container that builds everything. Struts no longer has any concept of an
ObjectFactory and doesn't create actions or anything like that. It would j
I have mixed feelings about it. making it pluggeable is not a priority
I would say. But if there are standard annotations for it now, then
there is no reason why we shouldn't use them. If the day comes when
guice is no longer supported (I don't really mean it crazybob :)), it
would be easier to fin
I was actually talking about expanding it out like Chris mentioned. I don't see
any reason why those who want to use the container that Struts is using
shouldn't be able to. Since the annotations and APIs will be standard across
Guice and Spring with the JSR, it seems like it would be possible t
On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso wrote:
> this is not related to the application itself, you can still use any
> IoC you want. This is for the IoC that is used internally to wire
> struts internals together, which at the moment is an old version of
> guice which is in xwork.
If it
I don't see a clear distinction between the Struts injector and the
App injector. One thing to keep in mind is that user often request how
to access struts internal stuff, like action mapping etc, which in
theory should not happen, but it does.
musachy
On Tue, Dec 1, 2009 at 10:21 AM, Brian Ponta
this is not related to the application itself, you can still use any
IoC you want. This is for the IoC that is used internally to wire
struts internals together, which at the moment is an old version of
guice which is in xwork.
On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt wrote:
> I wouldn't have
I wouldn't have a problem with it as long as I can still swap in my trusty
Spring IoC container, I can't see my team moving away from it any time soon,
but I still want to try to stay as current as possible on Struts.
(*Chris*)
On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli wrote:
> They'll
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
|
|
_
| |
| |
StrutsApp
good point Brian, that has came up also. I have a couple of concerns
about it, like what is the status of the jsr and will the API
(annotations) will be under a decent (read ASF compatible license)
license and in maven central? which is usually a pain point when it
comes to Sun APIs.
musachy
On T
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 s
I have talked to a couple of people before and everyone seems to agree
that using guice instead of our internal IoC container (guice pre 1.0
I think), would be a good idea. I don't have any experience with guice
2.0, but looking at the docs it seems like porting our stuff would not
be that hard. Le
We should include/improve a flash result/scope for 2.2:
https://issues.apache.org/struts/browse/WW-2635
an yes, we should start drafting some sort of roadmap.
musachy
On Fri, Apr 24, 2009 at 12:49 PM, Rene Gielen wrote:
> to add some ideas that came to my mind lately:
>
> Rework on i18n suppor
to add some ideas that came to my mind lately:
Rework on i18n support
1. create a TextProviderNextGen component that can easily be used and
injected
2. create a TextProvider interceptor which
- sets up a TextProvider
- sets it on an Action implementing TextProviderAware interface
- pushe
Obinna wrote:
Dave Newton updated the patch and applied/assigned to JIRA (
https://issues.apache.org/struts/browse/WW-3009).
All I did was put it into a file so it was usable. If it needs to be
updated then delete the old attachment and attach a new patch file.
Dave
---
I have actually been working slowly but steadily on the struts2-jquery
plugin that was discussed awhile back (
http://code.google.com/p/struts2-jquery-plugin). Sorry for the radio
silence. It's now fairly comprehensive and barring after a few TODOs (see
below) , probably ready for some very early-a
On Sunday 12 April 2009 14:43:44 Frans Thamura wrote:
> > Right now the plugin doesn't require the JSON plugin. It uses the
> > JSONValidationInterceptor to handle validation with AJAX form submission.
> > So, it only depends on core. I didn't want to be dependent on a
> > non-hosted plugin and fig
> Right now the plugin doesn't require the JSON plugin. It uses the
> JSONValidationInterceptor to handle validation with AJAX form submission. So,
> it only depends on core. I didn't want to be dependent on a non-hosted plugin
> and figured it was time to bring JSON into the core. I think Musachy
On Sunday 12 April 2009 14:32:31 Frans Thamura wrote:
> yours jquery will work on top of json plugins, isnt it?
>
> i am waiting the JSON-RPC implementation so we can make S2 as JSONRPC
> and REST producer
>
> F
>
Right now the plugin doesn't require the JSON plugin. It uses the
JSONValidationInt
yours jquery will work on top of json plugins, isnt it?
i am waiting the JSON-RPC implementation so we can make S2 as JSONRPC
and REST producer
F
On Mon, Apr 13, 2009 at 1:11 AM, Wes Wannemacher wrote:
> On Sunday 12 April 2009 14:08:48 you wrote:
>> > Once the plugin is moved over, I am planni
On Sunday 12 April 2009 14:08:48 you wrote:
> > Once the plugin is moved over, I am planning to pick the JQuery plugin
> > back up. Right now there is a datepicker, form submission with validation
> > (via AJAX)... Are there other features that anyone wants in particular?
> > My goal is
>
> love to
>
> Once the plugin is moved over, I am planning to pick the JQuery plugin back
> up. Right now there is a datepicker, form submission with validation (via
> AJAX)... Are there other features that anyone wants in particular? My goal is
love to hear this good news ;)
F
--
On Sunday 12 April 2009 13:24:51 Musachy Barroso wrote:
> We need for one of the contributors to fax in the CLA. Is that all we need
> Wes?
>
> musachy
>
> On Sun, Apr 12, 2009 at 12:40 PM, Frans Thamura wrote:
> > is it possible the JSON plugins as default bundle for S2 2.2
> >
> > F
Yes, I am w
We need for one of the contributors to fax in the CLA. Is that all we need Wes?
musachy
On Sun, Apr 12, 2009 at 12:40 PM, Frans Thamura wrote:
> is it possible the JSON plugins as default bundle for S2 2.2
>
> F
>
> On Sun, Apr 12, 2009 at 11:34 PM, Musachy Barroso wrote:
>> The problem I have
is it possible the JSON plugins as default bundle for S2 2.2
F
On Sun, Apr 12, 2009 at 11:34 PM, Musachy Barroso wrote:
> The problem I have is that once the Container is built, there is no
> way to register new beans into it. The side effect of this is that
> "constants" and "beans" that are de
The problem I have is that once the Container is built, there is no
way to register new beans into it. The side effect of this is that
"constants" and "beans" that are defined in bundled xml config files
are never loaded into the container. It is the only limitation so far
for the OSGi plugin.
mus
I forgot to say, we can roll a build without trouble, we just need to
release xwork first (I don't think there is any blocker for xwork).
musachy
On Fri, Apr 10, 2009 at 4:02 PM, Musachy Barroso wrote:
> 2.1.7 has bug fixes and some small changes in Convention, nothing big.
>
> musachy
>
> On Fr
2.1.7 has bug fixes and some small changes in Convention, nothing big.
musachy
On Fri, Apr 10, 2009 at 9:35 AM, Don Brown wrote:
> Off the top of my head:
> * Split out the XML parser from XmlConfigurationProvider so that you
> can parse XML from any source
> * Get rid of all the Class.forName()
Off the top of my head:
* Split out the XML parser from XmlConfigurationProvider so that you
can parse XML from any source
* Get rid of all the Class.forName() calls in XWork
I'd rather not do this on a stable branch, particularly since new
public classes will be created. How many changes are the
I think we are good. What changes do you have in mind?, the OSGi
plugin could take advantage of some refactoring of xwork so I am
interested :)
musachy
On Fri, Apr 10, 2009 at 8:24 AM, Don Brown wrote:
> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
> off and move trunk t
Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
off and move trunk to 2.2? I was wanting to do some refactoring of
how XWork configuration is loaded and parsed, but new classes and the
like really isn't appropriate for a patch/micro release.
Any objections to the branching?
95 matches
Mail list logo
