http://struts.zones.apache.org:8080/continuum/
I had to fix all of the s1 pom scm references, which, I hope, doesn't
break anything else.(Wendy???) :D
Now we just need to have Continuum nag us on build failures.
--
James Mitchell
678.910.8017
and publish our web site
--
James Mitchell
678.910.8017
On Nov 1, 2006, at 5:10 AM, James Mitchell wrote:
http://struts.zones.apache.org:8080/continuum/
I had to fix all of the s1 pom scm references, which, I hope,
doesn't break anything else.(Wendy???) :D
Now we just need to
and do the nightly distribution
--
James Mitchell
678.910.8017
On Nov 1, 2006, at 5:10 AM, James Mitchell wrote:
http://struts.zones.apache.org:8080/continuum/
I had to fix all of the s1 pom scm references, which, I hope,
doesn't break anything else.(Wendy???) :D
Now we just
and keep careless developer like me to make sure the test case passed and
things run smoothly before commiting
James Mitchell [EMAIL PROTECTED] wrote: and do the nightly distribution
--
James Mitchell
678.910.8017
On Nov 1, 2006, at 5:10 AM, James Mitchell wrote:
Wendy Smoak wrote:
We might want to switch to timestamped snapshots (remove the
uniqueVersion=false in the pom) so that projects can choose when to
move up to the latest bits.
This is specified in the master pom, right?
What's the thought process behind NOT having timestamped snapshots? Is
On 11/1/06, David H. DeWolf [EMAIL PROTECTED] wrote:
This is specified in the master pom, right?
What's the thought process behind NOT having timestamped snapshots? Is
the idea that you want to force people to stay current?
Nothing more than that the repository will fill up with timestamped
If you can find a way to upload them, I'm sure Continuum will find a
way to wash them for you ;)
...although I'm not really sure which phase of the build process to
hook the maven plugin into...
My initial attempt keeps failing with this configurationwhat's
wrong? I copied it from
Dave Newton ha scritto:
From: James Mitchell [mailto:[EMAIL PROTECTED]
and do the nightly distribution
I have some dirty dishes it could look at.
I can understand you, today I made the springtime clean up, though it is
autumn :-)
Antonio
So, after fixing the scm references for s1 poms, I added s2 poms
(base, apps, plugins) to continuum and they also suffer the same
issue with Continuum getting the wrong url from (I'm guessing) the
ancestor scm via inheritance. Looks like Maven uses some sort of
parent.scm +
David H. DeWolf ha scritto:
David H. DeWolf wrote:
I'm wondering why the ComponentDefinitions interface has been exposed
outside of the DefinitionsFactory. To me, this class seems like an
implementation detail of the factory itself, and it should not be
exposed.
Notice that before I
Antonio Petrelli wrote:
. . .
So you are suggesting to put almost all the ComponentDefinitionsImpl
code inside UrlDefinitionsFactory? It is fine with me, but I don't know
what does Greg think of it :-)
. . .
No, not necessarily. For now I was just going to make it a private
member and
On Oct 31, 2006, at 3:10 PM, David H. DeWolf wrote:
I'm wondering why the ComponentDefinitions interface has been
exposed outside of the DefinitionsFactory. To me, this class seems
like an implementation detail of the factory itself, and it should
not be exposed.
If you look back at
I have attached the patch to WW-1484, please note that it doesn't
include some of the things mentioned in the bug (javadoc-like
documentation for the widgets). This includes
BindDiv, BindAnchor, BindButton, TabbedPannel, DatePicker, TimePicker,
DropDownDateTimePicker(kind of a verbose name
On 11/1/06, James Mitchell [EMAIL PROTECTED] wrote:
So, after fixing the scm references for s1 poms, I added s2 poms
(base, apps, plugins) to continuum and they also suffer the same
issue with Continuum getting the wrong url from (I'm guessing) the
ancestor scm via inheritance. Looks like
Greg Reddin wrote:
On Oct 31, 2006, at 3:10 PM, David H. DeWolf wrote:
I'm wondering why the ComponentDefinitions interface has been exposed
outside of the DefinitionsFactory. To me, this class seems like an
implementation detail of the factory itself, and it should not be
exposed.
If
Sounds good.
Don
tm jee wrote:
Hi,
Both filter, ActionContextCleanUp and FilterDispatcher contains some similar
logic which I think would be more appropriate if we move them to an abstract
superclass, maybe called AbstractFilterDispatcher.
Some of the logics are
- creation of a Dispatcher
Hello there,
Let's go straight to the question: will Struts2 continue to use OGNL as WebWork
used to? Does that mean that OGNL will continue to be developed?
Now to the long story... Sometime ago I posted a message at the OGNL forum.
Here's the link:
Just to complement the previous post, I quickly ported the application to
Struts2 (by the way, it was VERY easy to do it!) and removed my OgnlRuntime
hack and it does cause the problem.
The log file is here:
http://labes.inf.ufes.br/~vitor/ww_ognl_issue/cookbook-struts.log
The source code
AFAIK, other projects have moved from OGNL usage. I am not gonna
discuss if it is a good or bad decision, but in case we are gonna move
away from it the old apps with heavy usage of OGNL will become more
complex to be migrated. Unfortunately, I am not sure how we can find
out what WW users have
I think we can definitely say we will not be moving from OGNL for the
Struts 2.0.x series, and most likely not for the Struts 2.1.x series.
If we did try to move from OGNL for 2.1.x, it would probably still be
the default, with the ability to switch OGNL for another EL for
experimental
20 matches
Mail list logo
