You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2006/03/31 08:10:17 UTC
Towards a stable 1.3 release
Ok, as I understand the current system, we'd need a GA release of all
the subprojects, including Action 1, in order to declare a GA 1.3 release.
How much work does those involved think this will be? If a bit, I'm
thinking it might be easier in the long run to go ahead, consolidate the
subprojects, and even merge a few like taglibs and EL. Then, we can
push for a single release instead of having to roll and evaluate the 6
subprojects, each might take a few releases to get GA.
I'm willing to defer to those who have been doing all the hard work to
get this far, and I'd like to help do whatever it takes to get a stable
release out there. I'm just wondering if one larger release will be
quicker and easier than 6 releases. In fact, here is an idea at how to
getting a release out ASAP and make Action easier to manage:
- Put all subprojects under Action 1
- Merge Faces into Extras
- Merge EL into taglibs
- Get strict with tickets - only let bugs hold us up, and then, only
ones we agree should hold us back. Most projects ship with bugs, just
we'd make sure to document them.
Bottom line, the fewer subprojects and even "modules", the quicker a GA
release will happen and the easier the project will be to manage. We
are _way_ overdue on this release and I'm now hearing some literally
don't think it will _ever_ be finished, and worse, that we don't care.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Michael Jouravlev <jm...@gmail.com>.
On 3/31/06, Ted Husted <te...@gmail.com> wrote:
> On 3/31/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > There is another related product, StrutsLive! .
>
> Do you mean this StrutsLive!, Michael?
>
> * https://strutslive.dev.java.net/
Yes. I played with it, seems quite comprehensive. For an add-on it
might be a bit intrusive since it requires changes to request
processor, but otherwise a nice library.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Ted Husted <te...@gmail.com>.
On 3/31/06, Michael Jouravlev <jm...@gmail.com> wrote:
> There is another related product, StrutsLive! .
Do you mean this StrutsLive!, Michael?
* https://strutslive.dev.java.net/
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Hubert Rabago <hr...@gmail.com>.
On 3/31/06, Ted Husted <te...@gmail.com> wrote:
> If Hubert did have time to drop the plug-in now, that would be a
> reasonable first step. Then, we can integrate into a 1.4 DTD, if
> that's what we want to do. We did the same sort of thing with opt-in
> Cancel Handling. We "patched" 1.2 and then made the DTD change in 1.3.
This is also what I had in mind. Integrating FormDef features into
Struts would take more work and much more time. IMO, that change
would be enough for a change in version number. While I've thought
about what an integrated FormDef would look like, I still don't have
the full concept figured out.
> A big reason that we average 24 months between releases is because
> people tend to say, "Let's add this one more thing. It won't take
> long." And, then it always does take much longer that we imagine.
And this is what I'd like to avoid.
Hubert
(It's a very busy Friday for me at work so I'm not able to chime in as
much as I would like.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Michael Jouravlev <jm...@gmail.com>.
On 3/31/06, Ted Husted <te...@gmail.com> wrote:
> If Hubert did have time to drop the plug-in now, that would be a
> reasonable first step. Then, we can integrate into a 1.4 DTD, if
> that's what we want to do. We did the same sort of thing with opt-in
> Cancel Handling. We "patched" 1.2 and then made the DTD change in 1.3.
I just thought that having one change in DTD is better than having two
consecutive changes. It was pointed out in another thread that
stability (both code and API) is Struts' key to success. If a change
requires DTD to be updated, I'd rather have it combined with other DTD
updates in one bigger chunk. But this is just me.
I don't want to rush Hubert ;)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Ted Husted <te...@gmail.com>.
On 3/31/06, Michael Jouravlev <jm...@gmail.com> wrote:
> I think integrating FormDef into struts-config is a good thing, and
> this can be legitimately done right now, when version changes from 1.2
> to 1.3. It will not be possible later unless 1.4 will be released. But
> if Hubert prefers having FormDef as a plugin, well, it is his choice.
Procedurally, there's no difference to us between, say, a 1.3.3 and a
1.4.0. We're going to do exactly the same things either way. It's
mainly a about versioning the DTD. So far, we've only had "minor" DTD
releases ratrher than major one.
If Hubert did have time to drop the plug-in now, that would be a
reasonable first step. Then, we can integrate into a 1.4 DTD, if
that's what we want to do. We did the same sort of thing with opt-in
Cancel Handling. We "patched" 1.2 and then made the DTD change in 1.3.
A big reason that we average 24 months between releases is because
people tend to say, "Let's add this one more thing. It won't take
long." And, then it always does take much longer that we imagine.
We can keep rolling 1.x releases for as long as there are people
interested in rolling them. It's not like it affects the payroll or
anything :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Don Brown <mr...@twdata.org>.
Look at it this way - all this work has to be done whether we release a stable 1.3 now or after formdef. We might as
well get it done now, then we always could release again right afterwards. If this Maven build is as magical as Wendy
and James say it is ;), we shouldn't have a problem.
Don
Michael Jouravlev wrote:
> Don, despite that I myself feel that new release is in order, I think
> that waiting a few more weeks and having a bigger bang so to speak
> would be more beneficial. It is like releasing WinME instead of
> Win95OSR2 while the work on Win2K is still in progress.
>
> I think integrating FormDef into struts-config is a good thing, and
> this can be legitimately done right now, when version changes from 1.2
> to 1.3. It will not be possible later unless 1.4 will be released. But
> if Hubert prefers having FormDef as a plugin, well, it is his choice.
>
> Michael.
>
> On 3/31/06, Don Brown <mr...@twdata.org> wrote:
>> Agreed, I'd like to get a 1.3 release out first in the next week or so.
>> Will the FormDef code be integrated into the
>> code base, or would it be a new module with its own build?
>>
>> Don
>>
>> Hubert Rabago wrote:
>>> While I would be very much willing to bring FormDef in, I wouldn't
>>> want to hold up a 1.3 GA release because of it. This would take at
>>> least a few more weeks. For one thing, FormDef doesn't have methods
>>> that work with ActionContext yet, and Commands as Actions is one of
>>> the biggest new features of 1.3.
>>>
>>> If we bring in FormDef as just another plugin, there's no reason we
>>> can't bring it in later as part of another GA 1.3 download. If we
>>> integrate FormDef into struts-config.xml, then that's a much bigger
>>> change that 1.3 shouldn't have to wait for.
>>>
>>> Hubert
>>>
>>> On 3/31/06, Michael Jouravlev <jm...@gmail.com> wrote:
>>>> On 3/31/06, Ted Husted <te...@gmail.com> wrote:
>>>>> I don't even know that we need a 1.3.1 build yet.
>>>> 1.3.1 has EventActionDispatcher while 1.3.0 doesn't. I don't know
>>>> about other features. This may cause misunderstanding during upgrade,
>>>> since 1.2.9 contains EventActionDispatcher as well so 1.3.0 would have
>>>> a "hole". Why don't you either add EventActionDispatcher into 1.3.0,
>>>> or skip 1.3.0 altogether and move on to 1.3.1.
>>>>
>>>> Also, please consider FormDef as part of core distro. It is pretty
>>>> slick and nicely written piece of code. It should not take a lot of
>>>> effort to rename packages and to include it into standard distro.
>>>> Reformatting the docs also should be simple, Hubert wrote very concise
>>>> docs.
>>>>
>>>> Having waiting this long, new Struts release should be significantly
>>>> different (as in: better) than previous ones, and not only internally.
>>>> 13 months *is* long. The fact that 1.3 is being released with about
>>>> the same interval as prior versions is the reason for talking about
>>>> stagnation (I don't want to start this flame war again, I just say
>>>> what I see from where I stand). Struts has been good to me and I found
>>>> ways to work around it shortcomings, but not everyone is that patient.
>>>>
>>>> My feeling is that aside of technology purists when people say "Struts
>>>> sucks" they often mean how Struts handles input data type
>>>> conversion/validation and how it preserves (or not) entered values
>>>> between requests. Considering that more and more Struts users discover
>>>> niceties of dynabeans, FormDef comes as missing element of the
>>>> picture. For some users it can be a bigger reason for upgrade to 1.3
>>>> than internal changes in request processor.
>>>>
>>>> There is another related product, StrutsLive! . I think it is
>>>> Apache-licensed so you may want to take a look. It seems like a
>>>> comprehensive solution, but looks heavier than Hubert's and I am not
>>>> sure is it really better (and how much better) to warrant its
>>>> inclusion into Struts. I prefer to have things as simple as possible
>>>> ;)
>>>>
>>>> Michael.
>
> ---------------------------------------------------------------------
> 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
Re: Towards a stable 1.3 release
Posted by Michael Jouravlev <jm...@gmail.com>.
Don, despite that I myself feel that new release is in order, I think
that waiting a few more weeks and having a bigger bang so to speak
would be more beneficial. It is like releasing WinME instead of
Win95OSR2 while the work on Win2K is still in progress.
I think integrating FormDef into struts-config is a good thing, and
this can be legitimately done right now, when version changes from 1.2
to 1.3. It will not be possible later unless 1.4 will be released. But
if Hubert prefers having FormDef as a plugin, well, it is his choice.
Michael.
On 3/31/06, Don Brown <mr...@twdata.org> wrote:
> Agreed, I'd like to get a 1.3 release out first in the next week or so.
> Will the FormDef code be integrated into the
> code base, or would it be a new module with its own build?
>
> Don
>
> Hubert Rabago wrote:
> > While I would be very much willing to bring FormDef in, I wouldn't
> > want to hold up a 1.3 GA release because of it. This would take at
> > least a few more weeks. For one thing, FormDef doesn't have methods
> > that work with ActionContext yet, and Commands as Actions is one of
> > the biggest new features of 1.3.
> >
> > If we bring in FormDef as just another plugin, there's no reason we
> > can't bring it in later as part of another GA 1.3 download. If we
> > integrate FormDef into struts-config.xml, then that's a much bigger
> > change that 1.3 shouldn't have to wait for.
> >
> > Hubert
> >
> > On 3/31/06, Michael Jouravlev <jm...@gmail.com> wrote:
> >> On 3/31/06, Ted Husted <te...@gmail.com> wrote:
> >>> I don't even know that we need a 1.3.1 build yet.
> >> 1.3.1 has EventActionDispatcher while 1.3.0 doesn't. I don't know
> >> about other features. This may cause misunderstanding during upgrade,
> >> since 1.2.9 contains EventActionDispatcher as well so 1.3.0 would have
> >> a "hole". Why don't you either add EventActionDispatcher into 1.3.0,
> >> or skip 1.3.0 altogether and move on to 1.3.1.
> >>
> >> Also, please consider FormDef as part of core distro. It is pretty
> >> slick and nicely written piece of code. It should not take a lot of
> >> effort to rename packages and to include it into standard distro.
> >> Reformatting the docs also should be simple, Hubert wrote very concise
> >> docs.
> >>
> >> Having waiting this long, new Struts release should be significantly
> >> different (as in: better) than previous ones, and not only internally.
> >> 13 months *is* long. The fact that 1.3 is being released with about
> >> the same interval as prior versions is the reason for talking about
> >> stagnation (I don't want to start this flame war again, I just say
> >> what I see from where I stand). Struts has been good to me and I found
> >> ways to work around it shortcomings, but not everyone is that patient.
> >>
> >> My feeling is that aside of technology purists when people say "Struts
> >> sucks" they often mean how Struts handles input data type
> >> conversion/validation and how it preserves (or not) entered values
> >> between requests. Considering that more and more Struts users discover
> >> niceties of dynabeans, FormDef comes as missing element of the
> >> picture. For some users it can be a bigger reason for upgrade to 1.3
> >> than internal changes in request processor.
> >>
> >> There is another related product, StrutsLive! . I think it is
> >> Apache-licensed so you may want to take a look. It seems like a
> >> comprehensive solution, but looks heavier than Hubert's and I am not
> >> sure is it really better (and how much better) to warrant its
> >> inclusion into Struts. I prefer to have things as simple as possible
> >> ;)
> >>
> >> Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Don Brown <mr...@twdata.org>.
Agreed, I'd like to get a 1.3 release out first in the next week or so. Will the FormDef code be integrated into the
code base, or would it be a new module with its own build?
Don
Hubert Rabago wrote:
> While I would be very much willing to bring FormDef in, I wouldn't
> want to hold up a 1.3 GA release because of it. This would take at
> least a few more weeks. For one thing, FormDef doesn't have methods
> that work with ActionContext yet, and Commands as Actions is one of
> the biggest new features of 1.3.
>
> If we bring in FormDef as just another plugin, there's no reason we
> can't bring it in later as part of another GA 1.3 download. If we
> integrate FormDef into struts-config.xml, then that's a much bigger
> change that 1.3 shouldn't have to wait for.
>
> Hubert
>
> On 3/31/06, Michael Jouravlev <jm...@gmail.com> wrote:
>> On 3/31/06, Ted Husted <te...@gmail.com> wrote:
>>> I don't even know that we need a 1.3.1 build yet.
>> 1.3.1 has EventActionDispatcher while 1.3.0 doesn't. I don't know
>> about other features. This may cause misunderstanding during upgrade,
>> since 1.2.9 contains EventActionDispatcher as well so 1.3.0 would have
>> a "hole". Why don't you either add EventActionDispatcher into 1.3.0,
>> or skip 1.3.0 altogether and move on to 1.3.1.
>>
>> Also, please consider FormDef as part of core distro. It is pretty
>> slick and nicely written piece of code. It should not take a lot of
>> effort to rename packages and to include it into standard distro.
>> Reformatting the docs also should be simple, Hubert wrote very concise
>> docs.
>>
>> Having waiting this long, new Struts release should be significantly
>> different (as in: better) than previous ones, and not only internally.
>> 13 months *is* long. The fact that 1.3 is being released with about
>> the same interval as prior versions is the reason for talking about
>> stagnation (I don't want to start this flame war again, I just say
>> what I see from where I stand). Struts has been good to me and I found
>> ways to work around it shortcomings, but not everyone is that patient.
>>
>> My feeling is that aside of technology purists when people say "Struts
>> sucks" they often mean how Struts handles input data type
>> conversion/validation and how it preserves (or not) entered values
>> between requests. Considering that more and more Struts users discover
>> niceties of dynabeans, FormDef comes as missing element of the
>> picture. For some users it can be a bigger reason for upgrade to 1.3
>> than internal changes in request processor.
>>
>> There is another related product, StrutsLive! . I think it is
>> Apache-licensed so you may want to take a look. It seems like a
>> comprehensive solution, but looks heavier than Hubert's and I am not
>> sure is it really better (and how much better) to warrant its
>> inclusion into Struts. I prefer to have things as simple as possible
>> ;)
>>
>> Michael.
>>
>
> ---------------------------------------------------------------------
> 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
Re: Towards a stable 1.3 release
Posted by Hubert Rabago <hr...@gmail.com>.
While I would be very much willing to bring FormDef in, I wouldn't
want to hold up a 1.3 GA release because of it. This would take at
least a few more weeks. For one thing, FormDef doesn't have methods
that work with ActionContext yet, and Commands as Actions is one of
the biggest new features of 1.3.
If we bring in FormDef as just another plugin, there's no reason we
can't bring it in later as part of another GA 1.3 download. If we
integrate FormDef into struts-config.xml, then that's a much bigger
change that 1.3 shouldn't have to wait for.
Hubert
On 3/31/06, Michael Jouravlev <jm...@gmail.com> wrote:
> On 3/31/06, Ted Husted <te...@gmail.com> wrote:
> > I don't even know that we need a 1.3.1 build yet.
>
> 1.3.1 has EventActionDispatcher while 1.3.0 doesn't. I don't know
> about other features. This may cause misunderstanding during upgrade,
> since 1.2.9 contains EventActionDispatcher as well so 1.3.0 would have
> a "hole". Why don't you either add EventActionDispatcher into 1.3.0,
> or skip 1.3.0 altogether and move on to 1.3.1.
>
> Also, please consider FormDef as part of core distro. It is pretty
> slick and nicely written piece of code. It should not take a lot of
> effort to rename packages and to include it into standard distro.
> Reformatting the docs also should be simple, Hubert wrote very concise
> docs.
>
> Having waiting this long, new Struts release should be significantly
> different (as in: better) than previous ones, and not only internally.
> 13 months *is* long. The fact that 1.3 is being released with about
> the same interval as prior versions is the reason for talking about
> stagnation (I don't want to start this flame war again, I just say
> what I see from where I stand). Struts has been good to me and I found
> ways to work around it shortcomings, but not everyone is that patient.
>
> My feeling is that aside of technology purists when people say "Struts
> sucks" they often mean how Struts handles input data type
> conversion/validation and how it preserves (or not) entered values
> between requests. Considering that more and more Struts users discover
> niceties of dynabeans, FormDef comes as missing element of the
> picture. For some users it can be a bigger reason for upgrade to 1.3
> than internal changes in request processor.
>
> There is another related product, StrutsLive! . I think it is
> Apache-licensed so you may want to take a look. It seems like a
> comprehensive solution, but looks heavier than Hubert's and I am not
> sure is it really better (and how much better) to warrant its
> inclusion into Struts. I prefer to have things as simple as possible
> ;)
>
> Michael.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Michael Jouravlev <jm...@gmail.com>.
On 3/31/06, Ted Husted <te...@gmail.com> wrote:
> I don't even know that we need a 1.3.1 build yet.
1.3.1 has EventActionDispatcher while 1.3.0 doesn't. I don't know
about other features. This may cause misunderstanding during upgrade,
since 1.2.9 contains EventActionDispatcher as well so 1.3.0 would have
a "hole". Why don't you either add EventActionDispatcher into 1.3.0,
or skip 1.3.0 altogether and move on to 1.3.1.
Also, please consider FormDef as part of core distro. It is pretty
slick and nicely written piece of code. It should not take a lot of
effort to rename packages and to include it into standard distro.
Reformatting the docs also should be simple, Hubert wrote very concise
docs.
Having waiting this long, new Struts release should be significantly
different (as in: better) than previous ones, and not only internally.
13 months *is* long. The fact that 1.3 is being released with about
the same interval as prior versions is the reason for talking about
stagnation (I don't want to start this flame war again, I just say
what I see from where I stand). Struts has been good to me and I found
ways to work around it shortcomings, but not everyone is that patient.
My feeling is that aside of technology purists when people say "Struts
sucks" they often mean how Struts handles input data type
conversion/validation and how it preserves (or not) entered values
between requests. Considering that more and more Struts users discover
niceties of dynabeans, FormDef comes as missing element of the
picture. For some users it can be a bigger reason for upgrade to 1.3
than internal changes in request processor.
There is another related product, StrutsLive! . I think it is
Apache-licensed so you may want to take a look. It seems like a
comprehensive solution, but looks heavier than Hubert's and I am not
sure is it really better (and how much better) to warrant its
inclusion into Struts. I prefer to have things as simple as possible
;)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Ted Husted <te...@gmail.com>.
On 3/31/06, Don Brown <mr...@twdata.org> wrote:
> I guess what I'm saying is I'm willing to be the release manager for
> 1.3.1, but I'm looking to do as little work as possible :)
I'm just saying the infrastructure we have now for Action 1.3 doesn't
prevent anyone from doing a single plan that covers all the "Action 1"
JARs, as we did with 1.3.0. There is one 1.3.0 plan, and we could also
call for one quality vote on the 1.3.0 build, without doing *any*
additional work.
I don't even know that we need a 1.3.1 build yet. I haven't called for
a vote on the 1.3.0 build myself since my work schedule won't permit
me to provide the level of support a GA release deserves. The best I
could do myself is vote +0 on the 1.3.0 release.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/31/06, Wendy Smoak <ws...@gmail.com> wrote:
> Is it going to be struts-core.jar, then? It seems confusing to have a
> directory called 'core' build an artifact called 'struts-action'.
{sees Don svn mv core/* ../ in r151397}
No, that's not what I meant. I was only commenting on the name of the
directory, not its location.
It's fine to have (showing trunk, which isn't there now,)
action1/trunk/action
action1/trunk/taglib
etc...
HTH,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by James Mitchell <jm...@apache.org>.
I'm using a stock download of 2.0.3.
Oh how I dream of finding the missing manual for Maven 2 command line
options :(
--
James Mitchell
On Apr 6, 2006, at 1:25 AM, Wendy Smoak wrote:
> On 4/5/06, James Mitchell <jm...@apache.org> wrote:
>
>> I was pleasantly surprised (after making my changes to the 4 or 5
>> tests in core) to run 'mvn install' in struts/action/build/ and see
>> the reactor kick off and fully build/test/install all/some of SAF.
>> Same for compile, test, and a few other targets.
>
> Just curious... what version of m2 are you using, and have you added
> -U on the command line to make it update everything? I wonder if
> you're using an old version of Surefire (the testing plugin).
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/5/06, James Mitchell <jm...@apache.org> wrote:
> I was pleasantly surprised (after making my changes to the 4 or 5
> tests in core) to run 'mvn install' in struts/action/build/ and see
> the reactor kick off and fully build/test/install all/some of SAF.
> Same for compile, test, and a few other targets.
Just curious... what version of m2 are you using, and have you added
-U on the command line to make it update everything? I wonder if
you're using an old version of Surefire (the testing plugin).
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by James Mitchell <jm...@apache.org>.
That is probably what we would have done if we hadn't had to deal
with the {subproject}/build having to be svn:externals-ized into each
one.
I was pleasantly surprised (after making my changes to the 4 or 5
tests in core) to run 'mvn install' in struts/action/build/ and see
the reactor kick off and fully build/test/install all/some of SAF.
Same for compile, test, and a few other targets.
--
James Mitchell
On Apr 5, 2006, at 9:06 PM, Wendy Smoak wrote:
> On 4/5/06, James Mitchell <jm...@apache.org> wrote:
>
>> Also, I'm about to start another thread related to our build...it is
>> (more or less) notes as I go through the various project.xml,
>> pom.xml, etc, etc for each of the pieces of the action1 puzzle.
>
> What do you think about moving the build files (project.xml,
> maven.xml, etc.,) up to the 'struts/current/action' level? That would
> be closer to Maven's default project structure.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/5/06, James Mitchell <jm...@apache.org> wrote:
> Also, I'm about to start another thread related to our build...it is
> (more or less) notes as I go through the various project.xml,
> pom.xml, etc, etc for each of the pieces of the action1 puzzle.
What do you think about moving the build files (project.xml,
maven.xml, etc.,) up to the 'struts/current/action' level? That would
be closer to Maven's default project structure.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/5/06, James Mitchell <jm...@apache.org> wrote:
> Why 2.0.4? Building from source?!? Jeez! At least I'm not _that_
> bad ;)
Because 2.0.3 had some serious regressions, and it was just as easy to
grab the 2.0.4 release candidate as to go back to 2.0.2. It's the
plugins I'm building from source, though, to get some new features
that I wanted.
> I'm more inclined to work on a Maven 2 build and just remove whatever
> is in our way (e.g. failing tests, bad reports due to incomplete
> plugins, etc) to get to a distributable release.
>
> What do you think?
If this involves adopting most of Maven 2's conventions, and
restructuring where necessary, then _absolutely_. I think m2 can
handle the Struts build now, (with the possible exception of the
Cactus tests,) it's just not something I was ready to take on alone.
Just wait until you see 'mvn integration-test' work. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by James Mitchell <jm...@apache.org>.
Why 2.0.4? Building from source?!? Jeez! At least I'm not _that_
bad ;)
I'm more inclined to work on a Maven 2 build and just remove whatever
is in our way (e.g. failing tests, bad reports due to incomplete
plugins, etc) to get to a distributable release.
What do you think?
--
James Mitchell
On Apr 6, 2006, at 12:05 AM, Wendy Smoak wrote:
> On 4/5/06, James Mitchell <jm...@apache.org> wrote:
>
>> Notice the console outputs "FAILURE !!", which make it pretty easy to
>> spot ;)
>
> I notice it, I'm just not seeing it here. FWIW, I'm using a snapshot
> of Maven 2.0.4 and quite a few plugins built from source. Maven 2 is
> still a work in progress... I'm enjoying the journey, but there's a
> reason I haven't proposed moving Struts to m2. :)
>
>> Not to sound too negative, but if I have to bust out the diff command
>> on a list of my maven plugin versions to find why it fails for me and
>> not for other people, that's the tipping point for me to rip out
>> Maven and stick in Ivy.
>>
>> Your thoughts?
>
> I wouldn't mind seeing the end of Maven 1 and Jelly. As long as some
> build tool can build something that we can call a release, it doesn't
> really matter to me what it is.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/5/06, James Mitchell <jm...@apache.org> wrote:
> Notice the console outputs "FAILURE !!", which make it pretty easy to
> spot ;)
I notice it, I'm just not seeing it here. FWIW, I'm using a snapshot
of Maven 2.0.4 and quite a few plugins built from source. Maven 2 is
still a work in progress... I'm enjoying the journey, but there's a
reason I haven't proposed moving Struts to m2. :)
> Not to sound too negative, but if I have to bust out the diff command
> on a list of my maven plugin versions to find why it fails for me and
> not for other people, that's the tipping point for me to rip out
> Maven and stick in Ivy.
>
> Your thoughts?
I wouldn't mind seeing the end of Maven 1 and Jelly. As long as some
build tool can build something that we can call a release, it doesn't
really matter to me what it is.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by James Mitchell <jm...@apache.org>.
Before my changes, they fail for me on maven 1, when instrumented for
jcoverage (which is the case for the 'dist' target) and maven 2 when
run normally (mvn install).
Maven 1
-------
...
...
[junit] Running org.apache.struts.action.TestActionRedirect
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed:
0.033 sec
[junit] Running org.apache.struts.action.TestActionMessage
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
0.004 sec
[junit] Running org.apache.struts.action.TestActionServlet
Missing type value for noTypeForm form bean
Missing type value for name form property
Unable to create an instance of
org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
java.lang.InstantiationException:
org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
at java.lang.Class.newInstance0(Class.java:293)
at java.lang.Class.newInstance(Class.java:261)
at org.apache.struts.util.RequestUtils.applicationInstance
(RequestUtils.java:163)
at org.apache.struts.util.RequestUtils.applicationInstance
(RequestUtils.java:138)
at
org.apache.struts.action.ActionServlet.processFormBeanConfigClass
(ActionServlet.java:1021)
at
org.apache.struts.action.TestActionServlet.testProcessFormBeanConfigClas
sError(TestActionServlet.java:443)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
(noise)
[junit] Tests run: 34, Failures: 0, Errors: 0, Time elapsed: 0.308 sec
...
...
Passes ok, however it fails when running the tests for the jcoverage
reports.
Maven 2
-------
...
...
[surefire] Running org.apache.struts.action.TestActionMessages
[surefire] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.012 sec
[surefire] Running org.apache.struts.action.TestActionRedirect
[surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.022 sec
[surefire] Running org.apache.struts.action.TestActionServlet
Apr 5, 2006 3:38:51 PM org.apache.struts.action.ActionServlet
handleValueRequiredException
SEVERE: Missing type value for noTypeForm form bean
Apr 5, 2006 3:38:51 PM org.apache.struts.action.ActionServlet
handleValueRequiredException
SEVERE: Missing type value for name form property
Apr 5, 2006 3:38:51 PM org.apache.struts.action.ActionServlet
handleCreationException
SEVERE: Unable to create an instance of
org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
java.lang.InstantiationException:
org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
at java.lang.Class.newInstance0(Class.java:293)
at java.lang.Class.newInstance(Class.java:261)
at org.apache.struts.util.RequestUtils.applicationInstance
(RequestUtils.java:163)
at org.apache.struts.util.RequestUtils.applicationInstance
(RequestUtils.java:138)
at
org.apache.struts.action.ActionServlet.processFormBeanConfigClass
(ActionServlet.java:1022)
at
org.apache.struts.action.TestActionServlet.testProcessFormBeanConfigClas
sError(TestActionServlet.java:443)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
(more noise)
...
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode
(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[surefire] Tests run: 34, Failures: 1, Errors: 0, Time elapsed: 0.224
sec <<<<<<<< FAILURE !!
[surefire] Running org.apache.struts.action.TestDynaActionForm
[surefire] Tests run: 46, Failures: 0, Errors: 0, Time elapsed: 0.08 sec
[surefire] Running org.apache.struts.action.TestDynaActionFormClass
[surefire] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.009 sec
Notice the console outputs "FAILURE !!", which make it pretty easy to
spot ;)
Not to sound too negative, but if I have to bust out the diff command
on a list of my maven plugin versions to find why it fails for me and
not for other people, that's the tipping point for me to rip out
Maven and stick in Ivy.
Your thoughts?
--
James Mitchell
On Apr 5, 2006, at 9:04 PM, Wendy Smoak wrote:
> On 4/5/06, Don Brown <mr...@twdata.org> wrote:
>
>> Weird, so your Maven thinks that the tests fail? The tests pass
>> for me, for the core module anyways.
>
> The tests don't fail for me, either. They're just noisy with stack
> traces.
>
> Don, 'maven nightly' continues to work fine here. I deleted
> org.apache.struts.action and org.apache.struts.tiles from my local m1
> repo to make sure it was really building and/or retrieving everything.
>
> I put up a list of all my installed plugins. You might want to
> compare versions and consider upgrading if you're using older versions
> of any of them.
> http://wiki.wsmoak.net/cgi-bin/wiki.pl?StrutsBuild
>
> Does running maven with -X on the command line show anything
> interesting?
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/5/06, Don Brown <mr...@twdata.org> wrote:
> Weird, so your Maven thinks that the tests fail? The tests pass for me, for the core module anyways.
The tests don't fail for me, either. They're just noisy with stack traces.
Don, 'maven nightly' continues to work fine here. I deleted
org.apache.struts.action and org.apache.struts.tiles from my local m1
repo to make sure it was really building and/or retrieving everything.
I put up a list of all my installed plugins. You might want to
compare versions and consider upgrading if you're using older versions
of any of them.
http://wiki.wsmoak.net/cgi-bin/wiki.pl?StrutsBuild
Does running maven with -X on the command line show anything interesting?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Don Brown <mr...@twdata.org>.
James Mitchell wrote:
> Funny you should mention this now. About 10 minutes ago I (locally)
> commented the failing tests out (actually, I put 'no' in front of the
> failing testFoo methods, so it looks like 'notestFoo') so I could 'mvn
> eclipse:eclipse' core, taglib, and extras.
>
> I'm not sure why the output of the tests make Maven think that they
> failed, when, they actually did not and I know it's not an optimal
> solution, but I'd like to check that in so we can move on with our
> build. We can work out the kinks later.
Weird, so your Maven thinks that the tests fail? The tests pass for me, for the core module anyways.
> Also, I'm about to start another thread related to our build...it is
> (more or less) notes as I go through the various project.xml, pom.xml,
> etc, etc for each of the pieces of the action1 puzzle.
Ok, I'll hurry and move scripting into action then. That should be the last action 1-related move.
Don
>
>
> --
> James Mitchell
>
>
>
>
> On Apr 5, 2006, at 4:23 PM, Don Brown wrote:
>
>> The "nightly" maven goal isn't working for me. It doesn't seem to be
>> correctly executing the jar:install goal, causing other artifact
>> builds to fail due to missing dependencies. Perhaps someone seems
>> something I'm missing from this snippet from a nightly build:
>>
>> +----------------------------------------
>> | Building nightlies Struts Action Framework
>> | Memory: 18M/20M
>> +----------------------------------------
>>
>> jar:jar:
>>
>> jar:install:
>>
>>
>> build:end:
>>
>> build:start:
>>
>> dist:build-setup:
>> [delete] Deleting directory
>> /data/brownd/dev/struts/action/core/target/distributions
>> [mkdir] Created dir:
>> /data/brownd/dev/struts/action/core/target/distributions
>>
>> xdoc:init:
>>
>> java:prepare-filesystem:
>>
>> java:compile:
>> [echo] Compiling to
>> /data/brownd/dev/struts/action/core/../core/target/classes
>>
>> java:jar-resources:
>>
>> test:prepare-filesystem:
>>
>> test:test-resources:
>>
>> test:compile:
>>
>> test:test:
>> [junit] Running
>> org.apache.struts.chain.commands.servlet.TestPerformForward
>> exception: The path of an ForwardConfig cannot be null
>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.183 sec
>> [junit] Running
>> org.apache.struts.chain.commands.servlet.TestSetOriginalURI
>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.139 sec
>> [junit] Running
>> org.apache.struts.chain.commands.servlet.TestAuthorizeAction
>> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.191 sec
>> [junit] Running
>> org.apache.struts.chain.commands.generic.TestWrappingLookupCommand
>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.38 sec
>> [junit] Running
>> org.apache.struts.chain.commands.generic.TestCopyFormToContext
>> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.217 sec
>> [junit] Running org.apache.struts.config.TestActionConfigMatcher
>> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.244 sec
>> [junit] Running org.apache.struts.config.TestFormBeanConfig
>> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.165 sec
>> [junit] Running org.apache.struts.config.TestActionConfig
>> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.178 sec
>> [junit] Running org.apache.struts.config.TestForwardConfig
>> [junit] Tests run: 15, Failures: 0, Errors: 0, Time elapsed: 0.082
>> sec
>> [junit] Running org.apache.struts.config.TestModuleConfig
>> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.185 sec
>> [junit] Running org.apache.struts.config.TestFormPropertyConfig
>> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.04 sec
>> [junit] Running org.apache.struts.validator.TestValidWhen
>> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.442 sec
>> [junit] Running org.apache.struts.action.TestDynaActionFormClass
>> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.106 sec
>> [junit] Running org.apache.struts.action.TestActionRedirect
>> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.058 sec
>> [junit] Running org.apache.struts.action.TestActionMessage
>> [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.007 sec
>> [junit] Running org.apache.struts.action.TestActionServlet
>> Missing type value for noTypeForm form bean
>> Missing type value for name form property
>> Unable to create an instance of
>> org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
>> java.lang.InstantiationException:
>> org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
>> at java.lang.Class.newInstance0(Class.java:293)
>> at java.lang.Class.newInstance(Class.java:261)
>> at
>> org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:163)
>>
>> at
>> org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:138)
>>
>> at
>> org.apache.struts.action.ActionServlet.processFormBeanConfigClass(ActionServlet.java:1021)
>>
>> at
>> org.apache.struts.action.TestActionServlet.testProcessFormBeanConfigClassError(TestActionServlet.java:443)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at junit.framework.TestCase.runTest(TestCase.java:154)
>> at junit.framework.TestCase.runBare(TestCase.java:127)
>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>> at junit.framework.TestResult.run(TestResult.java:109)
>> at junit.framework.TestCase.run(TestCase.java:118)
>> at junit.framework.TestSuite.runTest(TestSuite.java:208)
>> at junit.framework.TestSuite.run(TestSuite.java:203)
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:848)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:556)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:532)
>>
>> at org.apache.tools.ant.Task.perform(Task.java:341)
>> at
>> org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
>> at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
>>
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
>>
>> at com.werken.werkz.Goal.fire(Goal.java:639)
>> at com.werken.werkz.Goal.attain(Goal.java:575)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at
>> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
>> at
>> org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
>> at
>> org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
>>
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
>>
>> at com.werken.werkz.Goal.fire(Goal.java:639)
>> at com.werken.werkz.Goal.attain(Goal.java:575)
>> at
>> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
>> at
>> org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
>> at org.apache.maven.cli.App.doMain(App.java:488)
>> at org.apache.maven.cli.App.main(App.java:1239)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at com.werken.forehead.Forehead.run(Forehead.java:551)
>> at com.werken.forehead.Forehead.main(Forehead.java:581)
>> Missing key value for java.lang.NullPointerException global exception
>> config
>> Unable to create an instance of
>> org.apache.struts.action.TestActionServlet$CustomExceptionConfigArg
>> java.lang.InstantiationException:
>> org.apache.struts.action.TestActionServlet$CustomExceptionConfigArg
>> at java.lang.Class.newInstance0(Class.java:293)
>> at java.lang.Class.newInstance(Class.java:261)
>> at
>> org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:163)
>>
>> at
>> org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:138)
>>
>> at
>> org.apache.struts.action.ActionServlet.processExceptionConfigClass(ActionServlet.java:1270)
>>
>> at
>> org.apache.struts.action.TestActionServlet.testProcessExceptionConfigClassError(TestActionServlet.java:621)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at junit.framework.TestCase.runTest(TestCase.java:154)
>> at junit.framework.TestCase.runBare(TestCase.java:127)
>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>> at junit.framework.TestResult.run(TestResult.java:109)
>> at junit.framework.TestCase.run(TestCase.java:118)
>> at junit.framework.TestSuite.runTest(TestSuite.java:208)
>> at junit.framework.TestSuite.run(TestSuite.java:203)
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:848)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:556)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:532)
>>
>> at org.apache.tools.ant.Task.perform(Task.java:341)
>> at
>> org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
>> at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
>>
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
>>
>> at com.werken.werkz.Goal.fire(Goal.java:639)
>> at com.werken.werkz.Goal.attain(Goal.java:575)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at
>> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
>> at
>> org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
>> at
>> org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
>>
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
>>
>> at com.werken.werkz.Goal.fire(Goal.java:639)
>> at com.werken.werkz.Goal.attain(Goal.java:575)
>> at
>> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
>> at
>> org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
>> at org.apache.maven.cli.App.doMain(App.java:488)
>> at org.apache.maven.cli.App.main(App.java:1239)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at com.werken.forehead.Forehead.run(Forehead.java:551)
>> at com.werken.forehead.Forehead.main(Forehead.java:581)
>> Missing path value for success global forward
>> Unable to create an instance of
>> org.apache.struts.action.TestActionServlet$CustomForwardConfigArg
>> java.lang.InstantiationException:
>> org.apache.struts.action.TestActionServlet$CustomForwardConfigArg
>> at java.lang.Class.newInstance0(Class.java:293)
>> at java.lang.Class.newInstance(Class.java:261)
>> at
>> org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:163)
>>
>> at
>> org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:138)
>>
>> at
>> org.apache.struts.action.ActionServlet.processForwardConfigClass(ActionServlet.java:1149)
>>
>> at
>> org.apache.struts.action.TestActionServlet.testProcessForwardConfigClassError(TestActionServlet.java:795)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at junit.framework.TestCase.runTest(TestCase.java:154)
>> at junit.framework.TestCase.runBare(TestCase.java:127)
>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>> at junit.framework.TestResult.run(TestResult.java:109)
>> at junit.framework.TestCase.run(TestCase.java:118)
>> at junit.framework.TestSuite.runTest(TestSuite.java:208)
>> at junit.framework.TestSuite.run(TestSuite.java:203)
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:848)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:556)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:532)
>>
>> at org.apache.tools.ant.Task.perform(Task.java:341)
>> at
>> org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
>> at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
>>
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
>>
>> at com.werken.werkz.Goal.fire(Goal.java:639)
>> at com.werken.werkz.Goal.attain(Goal.java:575)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at
>> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
>> at
>> org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
>> at
>> org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
>>
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
>>
>> at com.werken.werkz.Goal.fire(Goal.java:639)
>> at com.werken.werkz.Goal.attain(Goal.java:575)
>> at
>> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
>> at
>> org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
>> at org.apache.maven.cli.App.doMain(App.java:488)
>> at org.apache.maven.cli.App.main(App.java:1239)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at com.werken.forehead.Forehead.run(Forehead.java:551)
>> at com.werken.forehead.Forehead.main(Forehead.java:581)
>> Unable to create an instance of
>> org.apache.struts.action.TestActionServlet$CustomActionConfigArg
>> java.lang.InstantiationException:
>> org.apache.struts.action.TestActionServlet$CustomActionConfigArg
>> at java.lang.Class.newInstance0(Class.java:293)
>> at java.lang.Class.newInstance(Class.java:261)
>> at
>> org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:163)
>>
>> at
>> org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:138)
>>
>> at
>> org.apache.struts.action.ActionServlet.processActionConfigClass(ActionServlet.java:1409)
>>
>> at
>> org.apache.struts.action.TestActionServlet.testProcessActionConfigClassError(TestActionServlet.java:943)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at junit.framework.TestCase.runTest(TestCase.java:154)
>> at junit.framework.TestCase.runBare(TestCase.java:127)
>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>> at junit.framework.TestResult.run(TestResult.java:109)
>> at junit.framework.TestCase.run(TestCase.java:118)
>> at junit.framework.TestSuite.runTest(TestSuite.java:208)
>> at junit.framework.TestSuite.run(TestSuite.java:203)
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:848)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:556)
>>
>> at
>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:532)
>>
>> at org.apache.tools.ant.Task.perform(Task.java:341)
>> at
>> org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
>> at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
>>
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
>>
>> at com.werken.werkz.Goal.fire(Goal.java:639)
>> at com.werken.werkz.Goal.attain(Goal.java:575)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
>> at com.werken.werkz.Goal.attain(Goal.java:573)
>> at
>> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
>> at
>> org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
>> at
>> org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368)
>> at
>> org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
>> at
>> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
>>
>> at
>> org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
>>
>> at com.werken.werkz.Goal.fire(Goal.java:639)
>> at com.werken.werkz.Goal.attain(Goal.java:575)
>> at
>> org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
>> at
>> org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
>> at org.apache.maven.cli.App.doMain(App.java:488)
>> at org.apache.maven.cli.App.main(App.java:1239)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at com.werken.forehead.Forehead.run(Forehead.java:551)
>> at com.werken.forehead.Forehead.main(Forehead.java:581)
>> [junit] Tests run: 34, Failures: 0, Errors: 0, Time elapsed: 0.382
>> sec
>> [junit] Running org.apache.struts.action.TestActionMessages
>> [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.012 sec
>> [junit] Running org.apache.struts.action.TestDynaActionForm
>> [junit] Tests run: 46, Failures: 0, Errors: 0, Time elapsed: 0.232
>> sec
>> [junit] Running org.apache.struts.util.TestRequestUtilsPopulate
>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.222 sec
>> [junit] Running org.apache.struts.util.TestRequestUtils
>> [junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 0.216
>> sec
>>
>> jar:jar:
>>
>> site:
>> xdoc:register-reports:
>> maven-checkstyle-plugin:register:
>>
>> maven-changelog-plugin:register:
>>
>> maven-changes-plugin:register:
>>
>> maven-developer-activity-plugin:register:
>>
>> maven-file-activity-plugin:register:
>>
>> xdoc:init:
>>
>> maven-javadoc-plugin:register:
>>
>> maven-jdepend-plugin:register:
>>
>> maven-junit-report-plugin:register:
>>
>> maven-jxr-plugin:register:
>>
>> maven-pmd-plugin:register:
>>
>> maven-simian-plugin:register:
>>
>> maven-tasklist-plugin:register:
>>
>> maven-jcoverage-plugin:register:
>>
>>
>> site:run-reports:
>> [echo] Generating the Checkstyle...
>> +----------------------------------------
>> | Building nightlies Struts Taglibs
>> | Memory: 21M/31M
>> +----------------------------------------
>> Attempting to download struts-core-1.3.2-SNAPSHOT.jar.
>> WARNING: Failed to download struts-core-1.3.2-SNAPSHOT.jar.
>>
>> --
>>
>> Don
>>
>> ---------------------------------------------------------------------
>> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by James Mitchell <jm...@apache.org>.
Funny you should mention this now. About 10 minutes ago I (locally)
commented the failing tests out (actually, I put 'no' in front of the
failing testFoo methods, so it looks like 'notestFoo') so I could
'mvn eclipse:eclipse' core, taglib, and extras.
I'm not sure why the output of the tests make Maven think that they
failed, when, they actually did not and I know it's not an optimal
solution, but I'd like to check that in so we can move on with our
build. We can work out the kinks later.
Also, I'm about to start another thread related to our build...it is
(more or less) notes as I go through the various project.xml,
pom.xml, etc, etc for each of the pieces of the action1 puzzle.
--
James Mitchell
On Apr 5, 2006, at 4:23 PM, Don Brown wrote:
> The "nightly" maven goal isn't working for me. It doesn't seem to
> be correctly executing the jar:install goal, causing other artifact
> builds to fail due to missing dependencies. Perhaps someone seems
> something I'm missing from this snippet from a nightly build:
>
> +----------------------------------------
> | Building nightlies Struts Action Framework
> | Memory: 18M/20M
> +----------------------------------------
>
> jar:jar:
>
> jar:install:
>
>
> build:end:
>
> build:start:
>
> dist:build-setup:
> [delete] Deleting directory /data/brownd/dev/struts/action/core/
> target/distributions
> [mkdir] Created dir: /data/brownd/dev/struts/action/core/target/
> distributions
>
> xdoc:init:
>
> java:prepare-filesystem:
>
> java:compile:
> [echo] Compiling to /data/brownd/dev/struts/action/core/../core/
> target/classes
>
> java:jar-resources:
>
> test:prepare-filesystem:
>
> test:test-resources:
>
> test:compile:
>
> test:test:
> [junit] Running
> org.apache.struts.chain.commands.servlet.TestPerformForward
> exception: The path of an ForwardConfig cannot be null
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.183 sec
> [junit] Running
> org.apache.struts.chain.commands.servlet.TestSetOriginalURI
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
> 0.139 sec
> [junit] Running
> org.apache.struts.chain.commands.servlet.TestAuthorizeAction
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed:
> 0.191 sec
> [junit] Running
> org.apache.struts.chain.commands.generic.TestWrappingLookupCommand
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
> 0.38 sec
> [junit] Running
> org.apache.struts.chain.commands.generic.TestCopyFormToContext
> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed:
> 0.217 sec
> [junit] Running org.apache.struts.config.TestActionConfigMatcher
> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed:
> 0.244 sec
> [junit] Running org.apache.struts.config.TestFormBeanConfig
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed:
> 0.165 sec
> [junit] Running org.apache.struts.config.TestActionConfig
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed:
> 0.178 sec
> [junit] Running org.apache.struts.config.TestForwardConfig
> [junit] Tests run: 15, Failures: 0, Errors: 0, Time elapsed:
> 0.082 sec
> [junit] Running org.apache.struts.config.TestModuleConfig
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed:
> 1.185 sec
> [junit] Running org.apache.struts.config.TestFormPropertyConfig
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed:
> 0.04 sec
> [junit] Running org.apache.struts.validator.TestValidWhen
> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed:
> 0.442 sec
> [junit] Running org.apache.struts.action.TestDynaActionFormClass
> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed:
> 0.106 sec
> [junit] Running org.apache.struts.action.TestActionRedirect
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed:
> 0.058 sec
> [junit] Running org.apache.struts.action.TestActionMessage
> [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
> 0.007 sec
> [junit] Running org.apache.struts.action.TestActionServlet
> Missing type value for noTypeForm form bean
> Missing type value for name form property
> Unable to create an instance of
> org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
> java.lang.InstantiationException:
> org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
> at java.lang.Class.newInstance0(Class.java:293)
> at java.lang.Class.newInstance(Class.java:261)
> at org.apache.struts.util.RequestUtils.applicationInstance
> (RequestUtils.java:163)
> at org.apache.struts.util.RequestUtils.applicationInstance
> (RequestUtils.java:138)
> at
> org.apache.struts.action.ActionServlet.processFormBeanConfigClass
> (ActionServlet.java:1021)
> at
> org.apache.struts.action.TestActionServlet.testProcessFormBeanConfigCl
> assError(TestActionServlet.java:443)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:
> 124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run
> (JUnitTestRunner.java:325)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM
> (JUnitTask.java:848)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute
> (JUnitTask.java:556)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute
> (JUnitTask.java:532)
> at org.apache.tools.ant.Task.perform(Task.java:341)
> at org.apache.commons.jelly.tags.ant.AntTag.doTag
> (AntTag.java:185)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.commons.jelly.TagSupport.invokeBody
> (TagSupport.java:233)
> at org.apache.commons.jelly.tags.core.IfTag.doTag
> (IfTag.java:88)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
> (MavenGoalTag.java:79)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag
> $MavenGoalAction.performAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at org.apache.maven.plugin.PluginManager.attainGoals
> (PluginManager.java:671)
> at org.apache.maven.MavenSession.attainGoals
> (MavenSession.java:263)
> at org.apache.maven.jelly.tags.maven.ReactorTag.doTag
> (ReactorTag.java:368)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
> (MavenGoalTag.java:79)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag
> $MavenGoalAction.performAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at org.apache.maven.plugin.PluginManager.attainGoals
> (PluginManager.java:671)
> at org.apache.maven.MavenSession.attainGoals
> (MavenSession.java:263)
> at org.apache.maven.cli.App.doMain(App.java:488)
> at org.apache.maven.cli.App.main(App.java:1239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at com.werken.forehead.Forehead.run(Forehead.java:551)
> at com.werken.forehead.Forehead.main(Forehead.java:581)
> Missing key value for java.lang.NullPointerException global
> exception config
> Unable to create an instance of
> org.apache.struts.action.TestActionServlet$CustomExceptionConfigArg
> java.lang.InstantiationException:
> org.apache.struts.action.TestActionServlet$CustomExceptionConfigArg
> at java.lang.Class.newInstance0(Class.java:293)
> at java.lang.Class.newInstance(Class.java:261)
> at org.apache.struts.util.RequestUtils.applicationInstance
> (RequestUtils.java:163)
> at org.apache.struts.util.RequestUtils.applicationInstance
> (RequestUtils.java:138)
> at
> org.apache.struts.action.ActionServlet.processExceptionConfigClass
> (ActionServlet.java:1270)
> at
> org.apache.struts.action.TestActionServlet.testProcessExceptionConfigC
> lassError(TestActionServlet.java:621)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:
> 124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run
> (JUnitTestRunner.java:325)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM
> (JUnitTask.java:848)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute
> (JUnitTask.java:556)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute
> (JUnitTask.java:532)
> at org.apache.tools.ant.Task.perform(Task.java:341)
> at org.apache.commons.jelly.tags.ant.AntTag.doTag
> (AntTag.java:185)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.commons.jelly.TagSupport.invokeBody
> (TagSupport.java:233)
> at org.apache.commons.jelly.tags.core.IfTag.doTag
> (IfTag.java:88)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
> (MavenGoalTag.java:79)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag
> $MavenGoalAction.performAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at org.apache.maven.plugin.PluginManager.attainGoals
> (PluginManager.java:671)
> at org.apache.maven.MavenSession.attainGoals
> (MavenSession.java:263)
> at org.apache.maven.jelly.tags.maven.ReactorTag.doTag
> (ReactorTag.java:368)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
> (MavenGoalTag.java:79)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag
> $MavenGoalAction.performAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at org.apache.maven.plugin.PluginManager.attainGoals
> (PluginManager.java:671)
> at org.apache.maven.MavenSession.attainGoals
> (MavenSession.java:263)
> at org.apache.maven.cli.App.doMain(App.java:488)
> at org.apache.maven.cli.App.main(App.java:1239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at com.werken.forehead.Forehead.run(Forehead.java:551)
> at com.werken.forehead.Forehead.main(Forehead.java:581)
> Missing path value for success global forward
> Unable to create an instance of
> org.apache.struts.action.TestActionServlet$CustomForwardConfigArg
> java.lang.InstantiationException:
> org.apache.struts.action.TestActionServlet$CustomForwardConfigArg
> at java.lang.Class.newInstance0(Class.java:293)
> at java.lang.Class.newInstance(Class.java:261)
> at org.apache.struts.util.RequestUtils.applicationInstance
> (RequestUtils.java:163)
> at org.apache.struts.util.RequestUtils.applicationInstance
> (RequestUtils.java:138)
> at
> org.apache.struts.action.ActionServlet.processForwardConfigClass
> (ActionServlet.java:1149)
> at
> org.apache.struts.action.TestActionServlet.testProcessForwardConfigCla
> ssError(TestActionServlet.java:795)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:
> 124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run
> (JUnitTestRunner.java:325)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM
> (JUnitTask.java:848)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute
> (JUnitTask.java:556)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute
> (JUnitTask.java:532)
> at org.apache.tools.ant.Task.perform(Task.java:341)
> at org.apache.commons.jelly.tags.ant.AntTag.doTag
> (AntTag.java:185)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.commons.jelly.TagSupport.invokeBody
> (TagSupport.java:233)
> at org.apache.commons.jelly.tags.core.IfTag.doTag
> (IfTag.java:88)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
> (MavenGoalTag.java:79)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag
> $MavenGoalAction.performAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at org.apache.maven.plugin.PluginManager.attainGoals
> (PluginManager.java:671)
> at org.apache.maven.MavenSession.attainGoals
> (MavenSession.java:263)
> at org.apache.maven.jelly.tags.maven.ReactorTag.doTag
> (ReactorTag.java:368)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
> (MavenGoalTag.java:79)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag
> $MavenGoalAction.performAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at org.apache.maven.plugin.PluginManager.attainGoals
> (PluginManager.java:671)
> at org.apache.maven.MavenSession.attainGoals
> (MavenSession.java:263)
> at org.apache.maven.cli.App.doMain(App.java:488)
> at org.apache.maven.cli.App.main(App.java:1239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at com.werken.forehead.Forehead.run(Forehead.java:551)
> at com.werken.forehead.Forehead.main(Forehead.java:581)
> Unable to create an instance of
> org.apache.struts.action.TestActionServlet$CustomActionConfigArg
> java.lang.InstantiationException:
> org.apache.struts.action.TestActionServlet$CustomActionConfigArg
> at java.lang.Class.newInstance0(Class.java:293)
> at java.lang.Class.newInstance(Class.java:261)
> at org.apache.struts.util.RequestUtils.applicationInstance
> (RequestUtils.java:163)
> at org.apache.struts.util.RequestUtils.applicationInstance
> (RequestUtils.java:138)
> at
> org.apache.struts.action.ActionServlet.processActionConfigClass
> (ActionServlet.java:1409)
> at
> org.apache.struts.action.TestActionServlet.testProcessActionConfigClas
> sError(TestActionServlet.java:943)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:
> 124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run
> (JUnitTestRunner.java:325)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM
> (JUnitTask.java:848)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute
> (JUnitTask.java:556)
> at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute
> (JUnitTask.java:532)
> at org.apache.tools.ant.Task.perform(Task.java:341)
> at org.apache.commons.jelly.tags.ant.AntTag.doTag
> (AntTag.java:185)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.commons.jelly.TagSupport.invokeBody
> (TagSupport.java:233)
> at org.apache.commons.jelly.tags.core.IfTag.doTag
> (IfTag.java:88)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
> (MavenGoalTag.java:79)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag
> $MavenGoalAction.performAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
> at com.werken.werkz.Goal.attain(Goal.java:573)
> at org.apache.maven.plugin.PluginManager.attainGoals
> (PluginManager.java:671)
> at org.apache.maven.MavenSession.attainGoals
> (MavenSession.java:263)
> at org.apache.maven.jelly.tags.maven.ReactorTag.doTag
> (ReactorTag.java:368)
> at org.apache.commons.jelly.impl.TagScript.run
> (TagScript.java:279)
> at org.apache.commons.jelly.impl.ScriptBlock.run
> (ScriptBlock.java:135)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
> (MavenGoalTag.java:79)
> at org.apache.maven.jelly.tags.werkz.MavenGoalTag
> $MavenGoalAction.performAction(MavenGoalTag.java:110)
> at com.werken.werkz.Goal.fire(Goal.java:639)
> at com.werken.werkz.Goal.attain(Goal.java:575)
> at org.apache.maven.plugin.PluginManager.attainGoals
> (PluginManager.java:671)
> at org.apache.maven.MavenSession.attainGoals
> (MavenSession.java:263)
> at org.apache.maven.cli.App.doMain(App.java:488)
> at org.apache.maven.cli.App.main(App.java:1239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at com.werken.forehead.Forehead.run(Forehead.java:551)
> at com.werken.forehead.Forehead.main(Forehead.java:581)
> [junit] Tests run: 34, Failures: 0, Errors: 0, Time elapsed:
> 0.382 sec
> [junit] Running org.apache.struts.action.TestActionMessages
> [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed:
> 0.012 sec
> [junit] Running org.apache.struts.action.TestDynaActionForm
> [junit] Tests run: 46, Failures: 0, Errors: 0, Time elapsed:
> 0.232 sec
> [junit] Running org.apache.struts.util.TestRequestUtilsPopulate
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed:
> 0.222 sec
> [junit] Running org.apache.struts.util.TestRequestUtils
> [junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed:
> 0.216 sec
>
> jar:jar:
>
> site:
> xdoc:register-reports:
> maven-checkstyle-plugin:register:
>
> maven-changelog-plugin:register:
>
> maven-changes-plugin:register:
>
> maven-developer-activity-plugin:register:
>
> maven-file-activity-plugin:register:
>
> xdoc:init:
>
> maven-javadoc-plugin:register:
>
> maven-jdepend-plugin:register:
>
> maven-junit-report-plugin:register:
>
> maven-jxr-plugin:register:
>
> maven-pmd-plugin:register:
>
> maven-simian-plugin:register:
>
> maven-tasklist-plugin:register:
>
> maven-jcoverage-plugin:register:
>
>
> site:run-reports:
> [echo] Generating the Checkstyle...
> +----------------------------------------
> | Building nightlies Struts Taglibs
> | Memory: 21M/31M
> +----------------------------------------
> Attempting to download struts-core-1.3.2-SNAPSHOT.jar.
> WARNING: Failed to download struts-core-1.3.2-SNAPSHOT.jar.
>
> --
>
> Don
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Don Brown <mr...@twdata.org>.
The "nightly" maven goal isn't working for me. It doesn't seem to be correctly executing the jar:install goal, causing
other artifact builds to fail due to missing dependencies. Perhaps someone seems something I'm missing from this
snippet from a nightly build:
+----------------------------------------
| Building nightlies Struts Action Framework
| Memory: 18M/20M
+----------------------------------------
jar:jar:
jar:install:
build:end:
build:start:
dist:build-setup:
[delete] Deleting directory /data/brownd/dev/struts/action/core/target/distributions
[mkdir] Created dir: /data/brownd/dev/struts/action/core/target/distributions
xdoc:init:
java:prepare-filesystem:
java:compile:
[echo] Compiling to /data/brownd/dev/struts/action/core/../core/target/classes
java:jar-resources:
test:prepare-filesystem:
test:test-resources:
test:compile:
test:test:
[junit] Running org.apache.struts.chain.commands.servlet.TestPerformForward
exception: The path of an ForwardConfig cannot be null
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.183 sec
[junit] Running org.apache.struts.chain.commands.servlet.TestSetOriginalURI
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.139 sec
[junit] Running org.apache.struts.chain.commands.servlet.TestAuthorizeAction
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.191 sec
[junit] Running org.apache.struts.chain.commands.generic.TestWrappingLookupCommand
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.38 sec
[junit] Running org.apache.struts.chain.commands.generic.TestCopyFormToContext
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.217 sec
[junit] Running org.apache.struts.config.TestActionConfigMatcher
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.244 sec
[junit] Running org.apache.struts.config.TestFormBeanConfig
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.165 sec
[junit] Running org.apache.struts.config.TestActionConfig
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.178 sec
[junit] Running org.apache.struts.config.TestForwardConfig
[junit] Tests run: 15, Failures: 0, Errors: 0, Time elapsed: 0.082 sec
[junit] Running org.apache.struts.config.TestModuleConfig
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.185 sec
[junit] Running org.apache.struts.config.TestFormPropertyConfig
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.04 sec
[junit] Running org.apache.struts.validator.TestValidWhen
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.442 sec
[junit] Running org.apache.struts.action.TestDynaActionFormClass
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.106 sec
[junit] Running org.apache.struts.action.TestActionRedirect
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.058 sec
[junit] Running org.apache.struts.action.TestActionMessage
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.007 sec
[junit] Running org.apache.struts.action.TestActionServlet
Missing type value for noTypeForm form bean
Missing type value for name form property
Unable to create an instance of org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
java.lang.InstantiationException: org.apache.struts.action.TestActionServlet$CustomFormBeanConfigArg
at java.lang.Class.newInstance0(Class.java:293)
at java.lang.Class.newInstance(Class.java:261)
at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:163)
at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:138)
at org.apache.struts.action.ActionServlet.processFormBeanConfigClass(ActionServlet.java:1021)
at org.apache.struts.action.TestActionServlet.testProcessFormBeanConfigClassError(TestActionServlet.java:443)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:848)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:556)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:532)
at org.apache.tools.ant.Task.perform(Task.java:341)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
Missing key value for java.lang.NullPointerException global exception config
Unable to create an instance of org.apache.struts.action.TestActionServlet$CustomExceptionConfigArg
java.lang.InstantiationException: org.apache.struts.action.TestActionServlet$CustomExceptionConfigArg
at java.lang.Class.newInstance0(Class.java:293)
at java.lang.Class.newInstance(Class.java:261)
at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:163)
at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:138)
at org.apache.struts.action.ActionServlet.processExceptionConfigClass(ActionServlet.java:1270)
at org.apache.struts.action.TestActionServlet.testProcessExceptionConfigClassError(TestActionServlet.java:621)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:848)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:556)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:532)
at org.apache.tools.ant.Task.perform(Task.java:341)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
Missing path value for success global forward
Unable to create an instance of org.apache.struts.action.TestActionServlet$CustomForwardConfigArg
java.lang.InstantiationException: org.apache.struts.action.TestActionServlet$CustomForwardConfigArg
at java.lang.Class.newInstance0(Class.java:293)
at java.lang.Class.newInstance(Class.java:261)
at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:163)
at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:138)
at org.apache.struts.action.ActionServlet.processForwardConfigClass(ActionServlet.java:1149)
at org.apache.struts.action.TestActionServlet.testProcessForwardConfigClassError(TestActionServlet.java:795)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:848)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:556)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:532)
at org.apache.tools.ant.Task.perform(Task.java:341)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
Unable to create an instance of org.apache.struts.action.TestActionServlet$CustomActionConfigArg
java.lang.InstantiationException: org.apache.struts.action.TestActionServlet$CustomActionConfigArg
at java.lang.Class.newInstance0(Class.java:293)
at java.lang.Class.newInstance(Class.java:261)
at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:163)
at org.apache.struts.util.RequestUtils.applicationInstance(RequestUtils.java:138)
at org.apache.struts.action.ActionServlet.processActionConfigClass(ActionServlet.java:1409)
at org.apache.struts.action.TestActionServlet.testProcessActionConfigClassError(TestActionServlet.java:943)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:848)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:556)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:532)
at org.apache.tools.ant.Task.perform(Task.java:341)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
[junit] Tests run: 34, Failures: 0, Errors: 0, Time elapsed: 0.382 sec
[junit] Running org.apache.struts.action.TestActionMessages
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.012 sec
[junit] Running org.apache.struts.action.TestDynaActionForm
[junit] Tests run: 46, Failures: 0, Errors: 0, Time elapsed: 0.232 sec
[junit] Running org.apache.struts.util.TestRequestUtilsPopulate
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.222 sec
[junit] Running org.apache.struts.util.TestRequestUtils
[junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 0.216 sec
jar:jar:
site:
xdoc:register-reports:
maven-checkstyle-plugin:register:
maven-changelog-plugin:register:
maven-changes-plugin:register:
maven-developer-activity-plugin:register:
maven-file-activity-plugin:register:
xdoc:init:
maven-javadoc-plugin:register:
maven-jdepend-plugin:register:
maven-junit-report-plugin:register:
maven-jxr-plugin:register:
maven-pmd-plugin:register:
maven-simian-plugin:register:
maven-tasklist-plugin:register:
maven-jcoverage-plugin:register:
site:run-reports:
[echo] Generating the Checkstyle...
+----------------------------------------
| Building nightlies Struts Taglibs
| Memory: 21M/31M
+----------------------------------------
Attempting to download struts-core-1.3.2-SNAPSHOT.jar.
WARNING: Failed to download struts-core-1.3.2-SNAPSHOT.jar.
--
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by James Mitchell <jm...@apache.org>.
.current is now .gone and so now I just need to fix the good one to
actually work correctly and we'll have our nightlies back.
--
James Mitchell
On Apr 4, 2006, at 1:01 PM, James Mitchell wrote:
> I believe the .current one is an older copy. I'll clean that up
> shortly.
>
> --
> James Mitchell
>
>
>
>
> On Apr 3, 2006, at 6:26 PM, Wendy Smoak wrote:
>
>> On 4/3/06, James Mitchell <jm...@apache.org> wrote:
>>> The 'actual' shell script that gets run nightly via cron is not
>>> under
>>> svn. Since we run nightlies on our zone, it is merely a copy of the
>>> one under svn and as changes come in, I review and then update my
>>> copy. It's probably an unnecessary level of security, but as
>>> long as
>>> my name and ASF Account is on the cron job, I'll be keeping it that
>>> way ;)
>>
>> So that's how that works. :) Do need both of these, or only the
>> first?
>> struts/current/nightly.sh or
>> struts/action/build/maven-nightly.sh.current
>>
>> Thanks,
>> --
>> Wendy
>>
>> ---------------------------------------------------------------------
>> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by James Mitchell <jm...@apache.org>.
I believe the .current one is an older copy. I'll clean that up
shortly.
--
James Mitchell
On Apr 3, 2006, at 6:26 PM, Wendy Smoak wrote:
> On 4/3/06, James Mitchell <jm...@apache.org> wrote:
>> The 'actual' shell script that gets run nightly via cron is not under
>> svn. Since we run nightlies on our zone, it is merely a copy of the
>> one under svn and as changes come in, I review and then update my
>> copy. It's probably an unnecessary level of security, but as long as
>> my name and ASF Account is on the cron job, I'll be keeping it that
>> way ;)
>
> So that's how that works. :) Do need both of these, or only the
> first?
> struts/current/nightly.sh or
> struts/action/build/maven-nightly.sh.current
>
> Thanks,
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/3/06, James Mitchell <jm...@apache.org> wrote:
> The 'actual' shell script that gets run nightly via cron is not under
> svn. Since we run nightlies on our zone, it is merely a copy of the
> one under svn and as changes come in, I review and then update my
> copy. It's probably an unnecessary level of security, but as long as
> my name and ASF Account is on the cron job, I'll be keeping it that
> way ;)
So that's how that works. :) Do need both of these, or only the first?
struts/current/nightly.sh or
struts/action/build/maven-nightly.sh.current
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Don Brown <mr...@twdata.org>.
James Mitchell wrote:
> Once we iron out action1 directories, I'll get that back online, but I'd
> like to wait till the dust settles before I pick up incubator/action2
> nightly builds.
If you are referring to the webwork2 incubated code, the only question mark in my mind relating to the build is
Patrick's Maven 2 stuff. The ant build works great and is very stable, however, I know Patrick is polishing up the
Maven 2 build and might want to do some splitting down the road to support multiple artifacts.
Don
>
>
> --
> James Mitchell
>
>
>
>
> On Apr 3, 2006, at 10:56 AM, Wendy Smoak wrote:
>
>> On 4/3/06, Don Brown <mr...@twdata.org> wrote:
>>
>>> Also, I'm hoping the nightly build scripts will be unaffected, although
>>> I'd kinda be surprised. Let me know any way I can help fix them, if
>>> they are indeed broken.
>>
>> It looks like Craig's are okay, but not the Maven-built ones. I made
>> a change to current/nightly.sh that should fix Struts Action 1.3.x for
>> tonight. We'll need to add Struts Tiles to the script, since it is
>> now separate.
>>
>> I asked site-dev@ to fix the config file for projects.apache.org.
>> (Our doap file moved from struts/site/trunk to struts/site.)
>>
>> --
>> Wendy
>>
>> ---------------------------------------------------------------------
>> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by James Mitchell <jm...@apache.org>.
The 'actual' shell script that gets run nightly via cron is not under
svn. Since we run nightlies on our zone, it is merely a copy of the
one under svn and as changes come in, I review and then update my
copy. It's probably an unnecessary level of security, but as long as
my name and ASF Account is on the cron job, I'll be keeping it that
way ;)
I'm still reviewing all the recent activity/changes and I do intend
to help keep the build up to date and as easy for new people to get
running as it is for someone whos been following this for years.
Once we iron out action1 directories, I'll get that back online, but
I'd like to wait till the dust settles before I pick up incubator/
action2 nightly builds.
--
James Mitchell
On Apr 3, 2006, at 10:56 AM, Wendy Smoak wrote:
> On 4/3/06, Don Brown <mr...@twdata.org> wrote:
>
>> Also, I'm hoping the nightly build scripts will be unaffected,
>> although
>> I'd kinda be surprised. Let me know any way I can help fix them, if
>> they are indeed broken.
>
> It looks like Craig's are okay, but not the Maven-built ones. I made
> a change to current/nightly.sh that should fix Struts Action 1.3.x for
> tonight. We'll need to add Struts Tiles to the script, since it is
> now separate.
>
> I asked site-dev@ to fix the config file for projects.apache.org.
> (Our doap file moved from struts/site/trunk to struts/site.)
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/3/06, Don Brown <mr...@twdata.org> wrote:
> Also, I'm hoping the nightly build scripts will be unaffected, although
> I'd kinda be surprised. Let me know any way I can help fix them, if
> they are indeed broken.
It looks like Craig's are okay, but not the Maven-built ones. I made
a change to current/nightly.sh that should fix Struts Action 1.3.x for
tonight. We'll need to add Struts Tiles to the script, since it is
now separate.
I asked site-dev@ to fix the config file for projects.apache.org.
(Our doap file moved from struts/site/trunk to struts/site.)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Don Brown <mr...@twdata.org>.
To add to that, I'll update the website to reflect the changes as soon
as they are all done. The only major one pending is the scripting move,
which I want to give a day or two to get any possible feedback.
Also, I'm hoping the nightly build scripts will be unaffected, although
I'd kinda be surprised. Let me know any way I can help fix them, if
they are indeed broken.
Don
Wendy Smoak wrote:
> To summarize the reorganization, (thanks, Don!) the 'current'
> svn:externals definition now contains:
>
> action, scripting, sandbox, shale, tiles and site.
>
> (I believe Don will also be moving scripting underneath action at some point.)
>
> Action builds several jars: struts-core, struts-extras,
> struts-taglib, struts-el, struts-faces, in addition to the example
> apps. We might also build "struts-action.jar" from this, which would
> be like the old "struts.jar" containing almost everything.
>
> The tags that were under the various sub-projects can now be found
> under action/tags/xxx. There were some naming conflicts and they
> could not all be copied to action/tags directly.
>
> Site has been flattened (tags and branches removed) as there is no
> need to version the top-level website. The 1.3.0 tag is over in
> action/tags/site for lack of a better place to put it.
>
> The "common build" is no more. Action, Shale, and Tiles have
> separate sets of build files. This leads to some duplication of small
> text files in the repository, but means less trouble with versioning
> and tags at release time.
>
> Struts Flow was moved to the sandbox.
>
> TODO:
>
> * The Struts Faces m1 build still needs some work, right now it only
> builds the site and struts-faces.jar, not the example apps.)
>
> * We need to bring back any branches that were under the various
> sub-projects and put them somewhere under action/branches. I think
> there is a 1.2 branch for Struts EL, at least.
>
> Let us know if you find anything that doesn't work right or have any questions.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
To summarize the reorganization, (thanks, Don!) the 'current'
svn:externals definition now contains:
action, scripting, sandbox, shale, tiles and site.
(I believe Don will also be moving scripting underneath action at some point.)
Action builds several jars: struts-core, struts-extras,
struts-taglib, struts-el, struts-faces, in addition to the example
apps. We might also build "struts-action.jar" from this, which would
be like the old "struts.jar" containing almost everything.
The tags that were under the various sub-projects can now be found
under action/tags/xxx. There were some naming conflicts and they
could not all be copied to action/tags directly.
Site has been flattened (tags and branches removed) as there is no
need to version the top-level website. The 1.3.0 tag is over in
action/tags/site for lack of a better place to put it.
The "common build" is no more. Action, Shale, and Tiles have
separate sets of build files. This leads to some duplication of small
text files in the repository, but means less trouble with versioning
and tags at release time.
Struts Flow was moved to the sandbox.
TODO:
* The Struts Faces m1 build still needs some work, right now it only
builds the site and struts-faces.jar, not the example apps.)
* We need to bring back any branches that were under the various
sub-projects and put them somewhere under action/branches. I think
there is a 1.2 branch for Struts EL, at least.
Let us know if you find anything that doesn't work right or have any questions.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/1/06, Don Brown <mr...@twdata.org> wrote:
> I don't think anything. If you are happy with it, I can make the
> changes tomorrow.
The structure in the test repo looks fine to me.
> I'd like to get a test release for Struts Action by
> Sunday, even if it isn't a voted on one. I'm aiming for a good Struts
> Action release by the end of the week. How does that sound?
Wonderful. :) I'll be around, but working on other things. I'll keep
an eye on email; please let me know if you need help with anything.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Don Brown <mr...@twdata.org>.
Wendy Smoak wrote:
> Did you get what's in the test repo to build for you? It ('maven
> nightly') works fine for me.
>
I wasn't able to get it working at work. I'll try again tomorrow from
this computer.
> * http://svn.apache.org/repos/test/action1
>
> What else needs to be done?
>
I don't think anything. If you are happy with it, I can make the
changes tomorrow. I haven't heard any complaints about moving Struts
Flow into the sandbox, so I'll probably do that too. I have one other
proposal I'll get out there so we can be done with the
re-organizations. I'd like to get a test release for Struts Action by
Sunday, even if it isn't a voted on one. I'm aiming for a good Struts
Action release by the end of the week. How does that sound?
Don
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/31/06, Don Brown <mr...@twdata.org> wrote:
> Oh, one other thing - what about tiles? I noticed tiles has its own build now, so can I then assume it is standalone?
The Struts Tiles build is separate. I did that when I changed the
groupId, in anticipation of this reorg. However, struts-tiles still
depends on struts-core, so it is not 'standalone' in that sense.
> I'd imagine a GA release of action would require a GA release of tiles.
I deployed the Struts Tiles 1.3.0 test build to the Maven snapshot
repositories, and changed the Apps and EL builds to depend on that.
We'll need to vote on Struts Tiles 1.3.0 along with Struts Action
1.3.2, one can't go GA without the other.
I also changed action back to core, and fixed the build files so it
works. The whole thing is Struts Action, that module is the core.
Makes sense to me, anyway...
Did you get what's in the test repo to build for you? It ('maven
nightly') works fine for me.
* http://svn.apache.org/repos/test/action1
What else needs to be done?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Don Brown <mr...@twdata.org>.
Ok, moving to struts-action. I tried changing paths, but the jars still aren't installing themselves, making it so only
action will build. I'll keep trying, but I have this suspicion that you could fix this in about 5 minutes when you get
home :)
Overall, I'm happy with the way it looks and should help clean up, in my opinion, our directory structure and make it
easier to grasp for users and new developers.
Oh, one other thing - what about tiles? I noticed tiles has its own build now, so can I then assume it is standalone?
If so, how close are they to a GA release, since I'd imagine a GA release of action would require a GA release of tiles.
Don
Wendy Smoak wrote:
> On 3/31/06, Don Brown <mr...@twdata.org> wrote:
>
>> I suppose the directory could be called 'action', but it seems
>> kinda silly to have 'action/trunk/action'. 'core' seems to be
>> what other projects like Cocoon, MyFaces, Shale, etc., are using,
>
> I'm fine with 'core', as long as the directory name is similar to the
> name of artifact it's building. That's all I was saying. :)
>
> Each directory should either contain modules, or be one. In fact the
> build files can be moved up to 'action1' if you want. That's the
> normal Maven project structure, though it will probably break a few
> more things along the way.
>
>> I'm am kind of wondering if the other modules shouldn't be prefixed with 'struts-action',
>> i.e. 'struts-action-extras'. It seems long, but it would be more accurate.
>
> I think they're fine the way they are, but wouldn't argue if the group
> wants to change it.
>
>> The other option would be to dump 'struts' all together:
>> - action-core.jar
> ...
>> I don't know if I like so easily giving up the Struts name though.
>
> Me, neither. Let's not.
>
>> This work is important as it paves the way to how we will handle Action 2 modules.
>> It would be even nicer if we could follow or synchronize the product
>> structure/layout with Shale.
>
> Shale is not where you want to look for a good layout for Maven. ;)
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/31/06, Don Brown <mr...@twdata.org> wrote:
> I suppose the directory could be called 'action', but it seems
> kinda silly to have 'action/trunk/action'. 'core' seems to be
> what other projects like Cocoon, MyFaces, Shale, etc., are using,
I'm fine with 'core', as long as the directory name is similar to the
name of artifact it's building. That's all I was saying. :)
Each directory should either contain modules, or be one. In fact the
build files can be moved up to 'action1' if you want. That's the
normal Maven project structure, though it will probably break a few
more things along the way.
> I'm am kind of wondering if the other modules shouldn't be prefixed with 'struts-action',
> i.e. 'struts-action-extras'. It seems long, but it would be more accurate.
I think they're fine the way they are, but wouldn't argue if the group
wants to change it.
> The other option would be to dump 'struts' all together:
> - action-core.jar
...
> I don't know if I like so easily giving up the Struts name though.
Me, neither. Let's not.
> This work is important as it paves the way to how we will handle Action 2 modules.
> It would be even nicer if we could follow or synchronize the product
> structure/layout with Shale.
Shale is not where you want to look for a good layout for Maven. ;)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Don Brown <mr...@twdata.org>.
Wendy Smoak wrote:
> Is it going to be struts-core.jar, then? It seems confusing to have a
> directory called 'core' build an artifact called 'struts-action'.
I suppose the directory could be called 'action', but it seems kinda silly to have 'action/trunk/action'. 'core' seems
to be what other projects like Cocoon, MyFaces, Shale, etc., are using, although in the first two cases, 'core' is top
level since they don't have the two framework split like we do. I tried dropping the contents of core down to action/,
but then the common build files aren't right and it is more confusing.
I'm am kind of wondering if the other modules shouldn't be prefixed with 'struts-action', i.e. 'struts-action-extras'.
It seems long, but it would be more accurate. The other option would be to dump 'struts' all together:
- action-core.jar
- action-extras.jar
- action-taglibs.jar
- action-apps.jar
- action-faces.jar
- action-el.jar
I don't know if I like so easily giving up the Struts name though.
This work is important as it paves the way to how we will handle Action 2 modules. It would be even nicer if we could
follow or synchronize the product structure/layout with Shale.
Don
>
>> I'm having trouble getting the nightly to run, as it seems the default built isn't installing the snapshot jars correctly. What am I missing here?
>
> It's the paths to 'build' in project.properties -- instead of
> "${basedir}/build" it should be "../build". And a few of these in
> maven.xml:
> - <ant:fileset dir="build/">
> + <ant:fileset dir="../build">
>
> HTH,
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/31/06, Don Brown <mr...@twdata.org> wrote:
> Ok, you asked for it... :) I put my first cut at https://svn.apache.org/repos/test/action1 I moved the subprojects under action1, action as core, and adjusted the builds so that they all shared the same version.
Oh, sure, do it now while I'm still at work and can't play. :)
> I moved the subprojects under action1, action as core
Is it going to be struts-core.jar, then? It seems confusing to have a
directory called 'core' build an artifact called 'struts-action'.
> I'm having trouble getting the nightly to run, as it seems the default built isn't installing the snapshot jars correctly. What am I missing here?
It's the paths to 'build' in project.properties -- instead of
"${basedir}/build" it should be "../build". And a few of these in
maven.xml:
- <ant:fileset dir="build/">
+ <ant:fileset dir="../build">
HTH,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Action 1 consolidation testing (was Towards a stable 1.3 release)
Posted by Don Brown <mr...@twdata.org>.
Wendy Smoak wrote:
> There were no objections to your proposed reorganization, so IMO the
> thing to do is try it and see what happens. Preferably in the test
> repo. :) We don't need history for this, so svn export/svn import
> should do it. (https://svn.apache.org/repos/test) If not, maybe Sean
> can help; he did the same thing for MyFaces before they switched to
> Maven 2.
Ok, you asked for it... :) I put my first cut at https://svn.apache.org/repos/test/action1 I moved the subprojects
under action1, action as core, and adjusted the builds so that they all shared the same version. I'm having trouble
getting the nightly to run, as it seems the default built isn't installing the snapshot jars correctly. What am I
missing here?
> Minor issues:
> * I think Struts EL and Taglib should stay in separate jars because
> you only need Struts EL in a Servlet 2.3 environment. (Further, I
> thought there was some technical reason they could not be combined.)
Well, our sys requirement is servlet 2.3 now. I haven't tried this yet, so there may be a technical reason it can't be
done. Well, thinking about it, if both were part of action 1, and according to maven, each subproject can have only one
artifact, I guess we should leave them.
> * Faces doesn't compile against the latest code. It's complaining
> about RequestUtils.selectModule(...). Right now, it depends on Struts
> 1.2.2. Also, its
> Maven 1 build is not finished. It's probably best to leave it separate for now.
No problem, I can fix this. I've been going through the code as I might want to port something similar for Action 2.
> I can't take on the reorganization project, but I have time to help
> with the build if you need it. I made some comments in the proposal
> thread about removing the svn:externals, etc.
Ok, I'll look that up again. Thanks for the help,
Don
>
> And, thanks. :)
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: Towards a stable 1.3 release
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/31/06, Don Brown <mr...@twdata.org> wrote:
> It isn't the jars I'm talking about, it is the multiple release
> processes: the plan, the checklists, the voting, the testing. I'd much
> rather do it once on a large project than 6 times on small ones.
>
> As for the risk of being held up, I think that is a much easier risk to
> manage. I'm perfectly comfortable with
> a) quickly fixing the problem
> b) deferring it to the next release
> c) backing out the offending code for the release
> and each of those operations can take only a few minutes. To assume a
> release must have no known issues is not always realistic.
>
> I guess what I'm saying is I'm willing to be the release manager for
> 1.3.1, but I'm looking to do as little work as possible :)
There were no objections to your proposed reorganization, so IMO the
thing to do is try it and see what happens. Preferably in the test
repo. :) We don't need history for this, so svn export/svn import
should do it. (https://svn.apache.org/repos/test) If not, maybe Sean
can help; he did the same thing for MyFaces before they switched to
Maven 2.
Minor issues:
* I think Struts EL and Taglib should stay in separate jars because
you only need Struts EL in a Servlet 2.3 environment. (Further, I
thought there was some technical reason they could not be combined.)
* Faces doesn't compile against the latest code. It's complaining
about RequestUtils.selectModule(...). Right now, it depends on Struts
1.2.2. Also, its
Maven 1 build is not finished. It's probably best to leave it separate for now.
I can't take on the reorganization project, but I have time to help
with the build if you need it. I made some comments in the proposal
thread about removing the svn:externals, etc.
And, thanks. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Don Brown <mr...@twdata.org>.
Ted Husted wrote:
> On 3/31/06, Don Brown <mr...@twdata.org> wrote:
>> Bottom line, the fewer subprojects and even "modules", the quicker a GA
>> release will happen and the easier the project will be to manage.
>
> Having done the release both ways, I don't see that multiple JARs is a
> problem. The work of creating a release is managing the plan, ensuring
> that all the relevent issues are resolved, checking the dependencies,
> and testing the code. Running the builds is mechanical and easy to
> automate.
It isn't the jars I'm talking about, it is the multiple release
processes: the plan, the checklists, the voting, the testing. I'd much
rather do it once on a large project than 6 times on small ones.
As for the risk of being held up, I think that is a much easier risk to
manage. I'm perfectly comfortable with
a) quickly fixing the problem
b) deferring it to the next release
c) backing out the offending code for the release
and each of those operations can take only a few minutes. To assume a
release must have no known issues is not always realistic.
I guess what I'm saying is I'm willing to be the release manager for
1.3.1, but I'm looking to do as little work as possible :)
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Ted Husted <te...@gmail.com>.
On 3/31/06, Don Brown <mr...@twdata.org> wrote:
> Bottom line, the fewer subprojects and even "modules", the quicker a GA
> release will happen and the easier the project will be to manage.
Having done the release both ways, I don't see that multiple JARs is a
problem. The work of creating a release is managing the plan, ensuring
that all the relevent issues are resolved, checking the dependencies,
and testing the code. Running the builds is mechanical and easy to
automate.
It's not uncommon for a project our size to distribute multiple JARs.
Spring is probably the best example. The question is whether the
version numbers of the JARs move together or move in synch.
For the 1.3.0 build, we kept the JARs in synch, so that we would have
a common baseline. Of course, because we had so much code to release
at once, it took just as long as all the other releases. We were ready
to go once before, back in November, but we held up all the code in
all the JARs for another four months because of one dependency used by
one new feature in the "Extras" JAR. Same old. Same old. One wrinkle,
and none of the wallpaper goes up.
I can't step up to the plate on the quality vote for the 1.3.0 builds
myself. If someone else is interested, I'd suggest calling for a vote
on 1.3.0, and we will see what happens.
Then, when someone is ready to do a 1.3.1 build, we can decide whether
to continue keeping all the "classic" JARs together, or whether we
want to start tagging the JARs separately.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Ted Husted <te...@gmail.com>.
On 3/31/06, Don Brown <mr...@twdata.org> wrote:
> We are _way_ overdue on this release and I'm now hearing some literally
> don't think it will _ever_ be finished, and worse, that we don't care.
Historically, we run 18 to 24 months between stable releases. Even the
initial release, when we had a greenfield, took 13 months. From that
perspective, 1.3 is right on time :)
May 2000 - 0.5
Jun 2001 - 1.0
Jun 2003 - 1.1
Sep 2004 - 1.2
xxx 2006 - 1.3
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Ted Husted <te...@gmail.com>.
I'm not aware of any additional work that needs to be done.
AFAIK, it's just a matter of calling for a quality vote.
In my own case, my work schedule isn't leaving me much discretionary
time, and so I must leave it to someone else to call for the quality
vote and complete the release.
If someone wants to slice and dice the subprojects a different way,
that's fine with me. (+0) But I don't see why that would make anything
go faster. The work is done. Someone just has to pull the switch, but
I can't step up to do that myself right now.
-Ted.
On 3/31/06, Don Brown <mr...@twdata.org> wrote:
> Ok, as I understand the current system, we'd need a GA release of all
> the subprojects, including Action 1, in order to declare a GA 1.3 release.
>
> How much work does those involved think this will be? If a bit, I'm
> thinking it might be easier in the long run to go ahead, consolidate the
> subprojects, and even merge a few like taglibs and EL. Then, we can
> push for a single release instead of having to roll and evaluate the 6
> subprojects, each might take a few releases to get GA.
>
> I'm willing to defer to those who have been doing all the hard work to
> get this far, and I'd like to help do whatever it takes to get a stable
> release out there. I'm just wondering if one larger release will be
> quicker and easier than 6 releases. In fact, here is an idea at how to
> getting a release out ASAP and make Action easier to manage:
> - Put all subprojects under Action 1
> - Merge Faces into Extras
> - Merge EL into taglibs
> - Get strict with tickets - only let bugs hold us up, and then, only
> ones we agree should hold us back. Most projects ship with bugs, just
> we'd make sure to document them.
>
> Bottom line, the fewer subprojects and even "modules", the quicker a GA
> release will happen and the easier the project will be to manage. We
> are _way_ overdue on this release and I'm now hearing some literally
> don't think it will _ever_ be finished, and worse, that we don't care.
>
> Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Ted Husted <te...@gmail.com>.
On 3/31/06, James Mitchell <jm...@apache.org> wrote:
> I also want to ask how everyone feels about our current build
> process. Are you using Ant, Maven 1 or Maven 2?
I used Maven 1 for the 1.3.0 builds, and it worked just fine.
> At this point we should probably take a vote and finalize a plan to
> merge [Action 1 subprojects] what we can.
With the proviso that +1 means, as always, that "I will help."
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by Greg Reddin <gr...@apache.org>.
On Mar 31, 2006, at 7:33 AM, James Mitchell wrote:
> I also want to ask how everyone feels about our current build
> process. Are you using Ant, Maven 1 or Maven 2?
Mostly Maven 1. I'm trying to move towards Maven 2, but for some
reason I can't get the tests to run for M2 (with Standalone Tiles at
least) The reason is because of some kind of horked JAXP
configuration on my computer. I haven't taken the time to diagnose
it. There's one advantage of having multiple build systems in place.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Towards a stable 1.3 release
Posted by James Mitchell <jm...@apache.org>.
On Mar 31, 2006, at 1:10 AM, Don Brown wrote:
> Ok, as I understand the current system, we'd need a GA release of
> all the subprojects, including Action 1, in order to declare a GA
> 1.3 release.
>
> How much work does those involved think this will be? If a bit,
> I'm thinking it might be easier in the long run to go ahead,
> consolidate the subprojects, and even merge a few like taglibs and
> EL. Then, we can push for a single release instead of having to
> roll and evaluate the 6 subprojects, each might take a few
> releases to get GA.
>
I'm curious about the relationship between a 'release' and a
'artifact'. Does a single artifact (e.g. struts-taglib-x.y.z.jar)
require it's own separate release? Is this a requirement?
I also want to ask how everyone feels about our current build
process. Are you using Ant, Maven 1 or Maven 2?
I'm not against merging subprojects, especially if it means
simplifying the build and dependencies. When we initially setup the
Maven 1 build, most subproject's build configuration simply inherited
from the master (which get's svn:external'd into each). This
approach reduces a lot of confusion between project interdependencies.
At this point we should probably take a vote and finalize a plan to
merge (as suggested below) what we can.
> I'm willing to defer to those who have been doing all the hard work
> to get this far, and I'd like to help do whatever it takes to get a
> stable release out there. I'm just wondering if one larger release
> will be quicker and easier than 6 releases. In fact, here is an
> idea at how to getting a release out ASAP and make Action easier to
> manage:
> - Put all subprojects under Action 1
What do you mean exactly? Since there isn't a directory called
'action1', I can only assume you mean to put them all under the same
named release, the 'Action 1' release and not actually moving (svn
mv) them.
If so, I'd be +1
> - Merge Faces into Extras
By this, I assume you mean physically 'svn mv' the source and modify/
merge the dependencies for the build. Also +1
> - Merge EL into taglibs
+1 again (Does that affect our minimum supported servlet spec?)
> - Get strict with tickets - only let bugs hold us up, and then,
> only ones we agree should hold us back. Most projects ship with
> bugs, just we'd make sure to document them.
>
Agreed.
> Bottom line, the fewer subprojects and even "modules", the quicker
> a GA release will happen and the easier the project will be to
> manage. We are _way_ overdue on this release and I'm now hearing
> some literally don't think it will _ever_ be finished, and worse,
> that we don't care.
>
It's funny how 'being excited about something new' somehow translates
into 'not caring about something else'. I find this to be pretty
characteristic of nay-sayers and negative people in general (e.g. our
trolls).
I agree 100% that we are overdue for a release and I'd like to help
make that happen.
> Don
>
--
James Mitchell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org