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
On 6/13/06, Don Brown <[EMAIL PROTECTED]> wrote:
Very tempting if it wasn't GPL :(
Don
Bob Lee wrote:
> We should use jarjar: http://tonicsystems.com/products/jarjar/
>
>
Very tempting if it wasn't GPL :(
Don
Bob Lee wrote:
We should use jarjar: http://tonicsystems.com/products/jarjar/
Bob
On 6/13/06, Don Brown <[EMAIL PROTECTED]> 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.
We should use jarjar: http://tonicsystems.com/products/jarjar/
Bob
On 6/13/06, Don Brown <[EMAIL PROTECTED]> 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 v
I'd be fine with that too.
Don
Patrick Lightbody wrote:
How about com.opensymphony.xwork2? :)
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=34229&messageID=66656#66656
--
How about com.opensymphony.xwork2? :)
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=34229&messageID=66656#66656
-
To unsubscribe,
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,
On 6/13/06, Ted Husted <[EMAIL PROTECTED]> wrote:
Right now, Wendy has been publishing 1.3.5 snapshots, and she may be
ready for another try at a release. I don't know if we want to get
into this again now or after we have a GA 1.3.
The 1.3 distribution is in good shape, I think, (but I've tho
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 pushin
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 Ju
On 6/13/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
I removed the servlet API from the repo. The install downloads the 2.4 plugin
but it's not using it in the compile.
Can you send me (off-list) the output of mvn install -X for shale-test?
cd shale-test
mvn clean
mvn install -X > build.lo
Ok, that's no problem. Waiting might be better, especially since it
looks like at least some of it involves rule tweaking, and hence I'd
think some discussion. I don't want to do anything that makes getting
to GA more difficult, so I'm ok with coming back to it later.
Frank
Ted Husted wrote
On 6/13/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Hi Ted... I wouldn't say there's no one interested in fixing the errors
:) I offered to do it some time ago, and I'm still willing (and my time
has freed up again, so able as well!)
Unforutnately, it seems to be a timing issue. If the pa
Hi Ted... I wouldn't say there's no one interested in fixing the errors
:) I offered to do it some time ago, and I'm still willing (and my time
has freed up again, so able as well!)
I just started going through them... my plan was to do one package in
Core and see if anyone was willing to com
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.xwor
Ticket SB-21 [1] seeks to simplify the Tiles taglib API. First, it's
a given that this will break backwards compatibility. You can't
reduce an API without breaking compatibility. But as long as we're
seeing this version of Tiles as a rework, I don't think it's a
problem. Also, I don't t
At 9:23 PM +0100 6/13/06, Phil Zoio wrote:
Is it possible to have multiple chain configurations for the same
Struts 1.3 app. For example, can you configure one module to use
tiles and another to not do so?
It is technically possible to change which command is looked up in
the catalogs and exe
>From: "Wendy Smoak" <[EMAIL PROTECTED]>
>
> On 6/13/06, Gary VanMatre wrote:
>
> > I tried a fresh checkout on
> (https://svn.apache.org/repos/asf/struts/shale/branches/mvn_reorg). I'm still
> seeing the same error when executing "mvn clean install" from the branch root
> or
> from mvn_reor
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.
> J
Is it possible to have multiple chain configurations for the same Struts
1.3 app. For example, can you configure one module to use tiles and
another to not do so?
Regards,
Phil Zoio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
On 6/13/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
I tried a fresh checkout on
(https://svn.apache.org/repos/asf/struts/shale/branches/mvn_reorg). I'm still seeing the
same error when executing "mvn clean install" from the branch root or from
mvn_reorg/shale-test. Not sure what I've messe
On 6/13/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Just so I'm clear, because I frankly wasn't paying attention previously
:)... are we favoring this Confluence instance over the Struts Wiki for
this sort of thing?
As it stands, all of the SAF2 documentation is under Confluence.
-Ted.
-
>From: "Craig McClanahan" <[EMAIL PROTECTED]>
>
> On 6/12/06, Wendy Smoak wrote:
> >
> > On 6/12/06, Craig McClanahan wrote:
> > > On 6/12/06, Gary VanMatre wrote:
> > > >
> > > > I had to wack my m2 shale repos and then rebuild all of the
> > > > libraries. That was the was the ticket. I'm
> 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
At 1:57 PM +0200 6/13/06, Antonio Petrelli wrote:
Yes that would be a workaround indeed but somewhat cumbersome since
I use this scope everywhere. I do think struts should offer a way
to change TagUtils behavior.
With the : private final TagUtils instance; there is clearly no
way in :-( It
I did an webBase ERP and in this context the window scope make sense.
One session, 3 windows, 1 Request and 1 page scope. And I do want to
change the implementation because this way I can use all the Struts
taglib without a change!
You are correct, but what if you are going to use JSTL tag
On 6/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
Having two frameworks to keep track of instead of one, each with their own
idiosyncracies and release trains, is not making life better for the
engineers that have to maintain that kind of a beast.
Well, it would have made Atlassian's life
David Gagnon ha scritto:
Hi Antonio,
I suppose that you want to use some window-scoped attribute in your
JSP page, right?
In this case I think that you could "copy" you attribute from window
scope to page scope (probably with some custom tag library) and then
use it, without changing Struts c
Hi Antonio,
I suppose that you want to use some window-scoped attribute in your
JSP page, right?
In this case I think that you could "copy" you attribute from window
scope to page scope (probably with some custom tag library) and then
use it, without changing Struts codebase.
HTH
Antonio
Ye
David Gagnon ha scritto:
If the instance variable is at least protected and not final. It
would be possible to create my new WindowScopeEnabledTagUtils class
that inherit from tagUtils and change the instance for my new
instance. That would have been great! Is that can be done ? Is there
a
29 matches
Mail list logo
