On Sun, 21 May 2006 12:44:02 -0700, Don Brown wrote:
You can inherit packages and their defined defaults. Therefore, in this
case, you could define the default interceptor stack and result type for
a root package then not have to specify it in any action configs of that
package or child
Let's leave XW at OpenSymphony for now - as we know there is a lot of work to
be focussed on when moving a project to Apache and I'd rather not let that
distract us from the core work that needs to be done on Struts. I say in 6
months or so we see about moving it, once we have a SAF 2.0 release
For the 2.0 XWork branch, why not branch off 1.x so we can keep trunk for
current development? This way, we don't have to change our current checked out
code :)
Don
Patrick Lightbody wrote:
Let's leave XW at OpenSymphony for now - as we know there is a lot of work to
be focussed on when
As Don suggested, I would branch xwork 1.x series as it is required for
the upcoming webwork 2.2.3 bugfix release. Trunk/Head will do fine for the
2.0 release then.
What about the proposal of moving over xwork to OpenSymphony SVN repository?
Rainer
For the 2.0 XWork branch, why not branch off
Sounds good to me. I can start the process of migrating to SVN.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61925#61925
Why move it to SVN? What does it gain? Just wondering how I'm going to
reconcile all these changes I've got that will be harder to do if we switch
repositories...
-
Posted via Jive Forums
My experience is that it's quite a bit faster than CVS (especially
over a WAN) but to be honest the biggest advantages I've seen are with
file moves, renames, and branching. SVN seems to handle them all
relatively painlessly which is a significant improvement over CVS.
Also the SVN support in
My experience is that it's quite a bit faster than CVS (especially
over a WAN) but to be honest the biggest advantages I've seen are with
file moves, renames, and branching. SVN seems to handle them all
relatively painlessly which is a significant improvement over CVS.
That's my experience as
At 12:20 PM -0500 5/23/06, Eric Molitor wrote:
My experience is that it's quite a bit faster than CVS (especially
over a WAN) but to be honest the biggest advantages I've seen are with
file moves, renames, and branching. SVN seems to handle them all
relatively painlessly which is a significant
I've imported a CVS repo into SVN and the history was preserved. Worked
like a charm.
/Ian
--
From Down Around, Inc.
Innovative IT Solutions
Software Architecture * Design * Development
~
web: www.fdar.com
email [EMAIL PROTECTED]
It also may be wasted work if there's an idea that
the whole
repository may be moving again (that is, to Apache)
in 6 months.
Exactly, point #1.
That said, I recall people generally saying that the
SVN
import-from-CVS tools work pretty well, and they also
are able to
preserve CVS
If Jason has a lot of uncommitted changes, it would
probably make
sense to let him commit them before migrating, if the
migration is to
go ahead.
Exactly, point #2.
But the problem is... If we're going to branch the old stuff, do I
want to check in my XWork 2.0 changes and then port to SVN,
Staying on CVS is probably a smarter descision for now but...
You could convert the repo to SVN, create a 1.xx branch and then you
could import your local copy into the trunk.
Never tried it but in theory it would work.
Cheers,
Eric
On 5/23/06, Jason Carreira [EMAIL PROTECTED] wrote:
It
Yep, we should branch XWork before you commit your
changes. Shall I
create a branch of the current CVS as XWORK_1_2?
So you could commit your changes later into HEAD and
Patrick could
start the migration to SVN after this commit.
Rainer
+1 (if we're voting)
Hi everyone,
Wanted to document the discussion we had at JavaOne regarding ajax
support for Struts2. In attendance were Pat, myself and Martin from the
committers group, as well as Joe (from DWR) and a couple of other people
(my apologies for not writing down names).
The discussion focused
On Tue, May 23, 2006 2:57 pm, Ian Roughley wrote:
What we came up with is:
1. Struts2 should be able to work generically as a data source for any
ajax client. This would entail being able to return HTML and XML
results, but also JSON results. Additionally, as well as populating the
action
Friends,
Pls Help, URGENT
I am gettting the following error when I invoke my Action class.
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error ()
Hi Ian,
I think using DWR as the core library will come up with some
problems. For example
How do you get the return value for the javascript function you call?
(if receiveMessages() returns something )
How do you switch between polling and Comet?
Solution (From forum)
Right now
18 matches
Mail list logo
