struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mitchell <jmitch...@apache.org>
Subject Re: Renaming XWork packages (was Poll: What part of a Struts...)
Date Wed, 14 Jun 2006 04:59:13 GMT
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  
>>> <the.mindstorm.mailinglist@gmail.com> 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 <forum-struts-dev@opensymphony.com>  
>>>> 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: dev-unsubscribe@struts.apache.org
>>>> > For additional commands, e-mail: dev-help@struts.apache.org
>>>> >
>>>> >
>>>>
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message