I see, so short term, you want to repackage XWork with all the latest
changes under a new package name, but leave it at OS.
And looking long term, XWork ('org.apache.xwork') as an official
subproject under Apache Struts ;) ??? I'd vote +1
--
James Mitchell
On Jun 14, 2006, at 12:42 AM, Don Brown wrote:
Theoretically, I agree with you. However, pushing a project
through Incubation takes a lot of work, and we are already
stretched trying to get a stable Action 2 release out. In order to
meet our August target, we have to get the feature scope wrapped up
in the next few weeks, and start pushing out betas by late June.
If we had an infinite workforce, I'd say let's do it. As it is
now, I think we should tackle one thing at a time. Therefore, I
think repackaging XWork will be a good workaround until we have
time to take on XWork migration.
Don
James Mitchell wrote:
If XWork were at Apache, it's hard to see it as anything but
'org.apache.xwork'. Is that not possible?
I think XWork truly deserves to stand on it's own (like it does
today) and not be tied to anything else. Surely it can live as a
TLP at Apache can it not?
--
James Mitchell
On Jun 13, 2006, at 8:01 PM, Don Brown wrote:
What about doing what Sun does with Xalan for Java 5 and rename
XWork
packages? With the changes we are making to XWork 2.0, I don't
think
it will co-exist with WebWork 2.2.2/3 very well, if at all.
Therefore:
com.opensymphony.xwork
will become:
org.apache.struts.action2.com.opensymphony.xwork or
org.apache.com.opensymphony.xwork or even
org.apache.struts.action2.xwork
If the new API does its job, XWork should be completely hidden
for the
user anyways and for legacy apps, they just need a simple
refactoring.
Don
On 6/13/06, Alexandru Popescu
<[EMAIL PROTECTED]> wrote:
Isn't possible to be an issue with XWork dependency? I don't
think 2
different versions of XWork can co-exist on the same webapp....
but I
may be wrong.
./alex
--
.w( the_mindstorm )p.
On 6/13/06, Jason Carreira <[EMAIL PROTECTED]>
wrote:
> > Well, it would have made Atlassian's life easier.
> > JIRA is written with
> > WW1 and Confluence is written with WW2, the two
> > versions cannot
> > coexist in the same web application, and they still
> > haven't gotten
> > around to migrating JIRA. When people (like me) run
> > both applications,
> > we need to run them as two separate web apps, instead
> > of two "modules"
> > that can share session.
>
> Not to nitpick, but WW1 and WW2 CAN peacefully coexist,
because we changed the package names in the change. At Notiva we
converted the app piecemeal from WW1 to WW2 over time, moving
over new pieces and migrating anything old that we had to touch.
We simply mapped them to different extensions.
>
> I'm not sure why Atlassian didn't switch over. Maybe it just
didn't ever make sense. Maybe there was some other issue with
common configuration files that we didn't run into at Notiva.
But I can tell you that they can run side-by-side, just as
WebWork 2.x and Struts 2.x will be able to.
>
-------------------------------------------------------------------
--
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?
threadID=34181&messageID=66503#66503
>
>
>
-------------------------------------------------------------------
--
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
