Renaming XWork packages (was Poll: What part of a Struts...)

NAVIGATION

CATEGORIES

Java

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » Java

Renaming XWork packages (was Poll: What part of a Struts...)
10 answers - 737 bytes -
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:
or
or even
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
6/13/06, Alexandru Popescu <the.mindstorm.mailinglist (AT) gmail (DOT) comwrote:
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
No.1 | | 967 bytes | |
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?
>
>
>
No.2 | | 293 bytes | |
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?
No.3 | | 263 bytes | |
I see, so short term, you want to repackage XWork with all the latest
changes under a new package name, but leave it at S.
And looking long term, XWork ('org.apache.xwork') as an official
subproject under Apache Struts ;) ? I'd vote +1
No.4 | | 841 bytes | |
We should use jarjar:

Bob

6/13/06, Don Brown <donald.brown (AT) gmail (DOT) comwrote:
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:

or
or even

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

6/13/06, Alexandru Popescu <the.mindstorm.mailinglist (AT) gmail (DOT) comwrote:
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
No.5 | | 3811 bytes | |
Very tempting if it wasn't GPL :(

Don

Bob Lee wrote:
We should use jarjar:

Bob

6/13/06, Don Brown <donald.brown (AT) gmail (DOT) comwrote:
>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:
>>
>or
>or even
>
>>
>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
>>
>6/13/06, Alexandru Popescu <the.mindstorm.mailinglist (AT) gmail (DOT) 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.
>>
>>
>6/13/06, Jason Carreira <forum-struts-dev (AT) opensymphony (DOT) comwrote:
>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
>
>#66503
>>
>>
>>
>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>>
>>
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>>
>>
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>>
>>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
--

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.6 | | 4309 bytes | |
It's a tool though, so it won't be distrubuted. If it's a big issue,
I'm sure we can talk Chris into something. Chris?

Bob

6/13/06, Don Brown <mrdon (AT) twdata (DOT) orgwrote:
Very tempting if it wasn't GPL :(

Don

Bob Lee wrote:
We should use jarjar:

Bob

6/13/06, Don Brown <donald.brown (AT) gmail (DOT) comwrote:
>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:
>>
>or
>or even
>
>>
>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
>>
>6/13/06, Alexandru Popescu <the.mindstorm.mailinglist (AT) gmail (DOT) 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.
>>
>>
>6/13/06, Jason Carreira <forum-struts-dev (AT) opensymphony (DOT) comwrote:
>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
>>
>#66503
>>
>>
>>
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>>
>>
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>>
>>
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>>
>>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>
>
>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
--

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.7 | | 1250 bytes | |
I'm not sure how easy it would be to change the license, but that really
shouldn't be necessary. As you say it is just a build tool so there is no
need to distribute the source, or even have the source checked in. I did a
few quick searches and found:

"ASF projects can use GPL/LGPL code during the build process so long as
there is no runtime dependency in the code produced."

Link here:

I'm sure you could find a bunch of existing examples.

Let me know if you have any technical problems getting jarjar to work.
From what I understand it does seem like a quick solution to your problem.

Chris

Tue, 13 Jun 2006 23:05:51 -0700, Bob Lee wrote:
It's a tool though, so it won't be distrubuted. If it's a big issue,
I'm sure we can talk Chris into something. Chris?

6/13/06, Don Brown <mrdon (AT) twdata (DOT) orgwrote:
>Very tempting if it wasn't GPL :(
>>
>Bob Lee wrote:
>We should use jarjar:

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.8 | | 1034 bytes | |
6/14/06, Don Brown <mrdon (AT) twdata (DOT) orgwrote:
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.

It would be nice to at least have nightly builds running by late June. :)

I can work 80% or more on SAF2 in July, but I have almost no
discretionary time left for the rest of June. My plan was to be ready
to try and roll SAF 2.0.0 the first week of August. Whether it will
be deemed "stable" is another matter. :)

We also need to find a macro or something to export the Confluence
documentation before we can even think about a test-build.
-Ted.

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.9 | | 3549 bytes | |
Is this really an issue? If users are running WW2.2 with Struts2
everything should be fine, so this case will be only when running WW2.0
or WW1 with Struts2 - correct? And it would only be a problem when
running in the same web application (and thus same class loader).

I'll probably get some slack for this, but isn't the goal to try to
provide an upgrade path for Struts users and not pre-WW2.2 user?

/Ian

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:

or
or even

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

6/13/06, Alexandru Popescu <the.mindstorm.mailinglist (AT) gmail (DOT) 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.
>>
>>
>6/13/06, Jason Carreira <forum-struts-dev (AT) opensymphony (DOT) comwrote:
>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
>
>#66503
>>
>>
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>>
>>
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>>
>>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.10 | | 1549 bytes | |
If that is the case, then jarjar seems to be a great solution. Anyone know if
it has a Maven 2 plugin?

Don

Chris Nokleberg wrote:
I'm not sure how easy it would be to change the license, but that really
shouldn't be necessary. As you say it is just a build tool so there is no
need to distribute the source, or even have the source checked in. I did a
few quick searches and found:

"ASF projects can use GPL/LGPL code during the build process so long as
there is no runtime dependency in the code produced."

Link here:

I'm sure you could find a bunch of existing examples.

Let me know if you have any technical problems getting jarjar to work.
From what I understand it does seem like a quick solution to your problem.

Chris

Tue, 13 Jun 2006 23:05:51 -0700, Bob Lee wrote:
>It's a tool though, so it won't be distrubuted. If it's a big issue,
>I'm sure we can talk Chris into something. Chris?
>>
>6/13/06, Don Brown <mrdon (AT) twdata (DOT) orgwrote:
Very tempting if it wasn't GPL :(

Bob Lee wrote:
We should use jarjar:

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

Re: Renaming XWork packages (was Poll: What part of a Struts...)

EMSDN.COM

Archive for 'Renaming XWork packages (was Poll: What part of a Struts...)' by Don Brown

Java

Renaming XWork packages (was Poll: What part of a Struts...)