struts 2.1.8 builds
i am seeing this error with xwork 2.1.6 package phase
WARNING: Result class [com.opensymphony.xwork2.result.NullResult] doesn't exist
(ClassNotFoundException) at result-type -
file:\xwork-2.1.6\src\xwork-parent\core\target\test-classes\com\opensymphony\xwork2\spring\xwork-autowire.xml:9:67,
ignoring
java.lang.ClassNotFoundException: com.opensymphony.xwork2.result.NullResult
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at
org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:103)
at
com.opensymphony.xwork2.util.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:146)
at
com.opensymphony.xwork2.ObjectFactory.getClassInstance(ObjectFactory.java:96)
at
com.opensymphony.xwork2.spring.SpringObjectFactory.getClassInstance(SpringObjectFactory.java:212)
at
com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.verifyResultType(XmlConfigurationProvider.java:519)
at
com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.addResultTypes(XmlConfigurationProvider.java:490)
at
com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.addPackage(XmlConfigurationProvider.java:446)
at
com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadPackages(XmlConfigurationProvider.java:264)
at
com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:193)
at
com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:55)
at
com.opensymphony.xwork2.util.XWorkTestCaseHelper.loadConfigurationProviders(XWorkTestCaseHelper.java:65)
at
com.opensymphony.xwork2.XWorkTestCase.loadConfigurationProviders(XWorkTestCase.java:54)
at
com.opensymphony.xwork2.spring.interceptor.ActionAutowiringInterceptorTest.testSetAutowireType(ActionAutowiringInterceptorTest.java:43)
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:597)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:552)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:411)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:785)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:114)
at org.testng.TestRunner.privateRun(TestRunner.java:693)
at org.testng.TestRunner.run(TestRunner.java:574)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:241)
at org.testng.SuiteRunner.run(SuiteRunner.java:145)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:901)
at org.testng.TestNG.runSuitesLocally(TestNG.java:863)
at org.testng.TestNG.run(TestNG.java:613)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:155)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
this happens with test generation from xwork 2.1.6 where the test fails and
package fails to build the jar
(jar:jar does build xwork-2.1.6.jar but skips testcase validation)
Martin
______________________________________________
standard caveats apply
> Date: Fri, 2 Oct 2009 09:23:49 -0700
> Subject: Re: zip problems with 2.1.8
> From: musa...@gmail.com
> To: dev@struts.apache.org
>
> If we can't get the help from people in the user list, then I would
> say we do what you are suggesting, but we take it to the "extreme" a
> bit, meaning, that when we think the code is ready to be frozen for a
> release, we cut a build(with tag, staging repo and all) and let people
> in dev@ know about it, then a month later or so, whenever we feel like
> it is pretty decent to assume we are in the clear, we can call a vote
> on it. I think that's would give us more confidence in what we are
> voting for.
>
> musachy
>
> On Fri, Oct 2, 2009 at 9:14 AM, Martin Cooper <mart...@apache.org> wrote:
> > On Thu, Oct 1, 2009 at 10:50 PM, Wes Wannemacher <w...@wantii.com> wrote:
> >> On Fri, Oct 2, 2009 at 1:25 AM, Martin Cooper <mart...@apache.org> wrote:
> >>> On Thu, Oct 1, 2009 at 10:00 PM, Musachy Barroso <musa...@gmail.com>
> >>> wrote:
> >>>> I still don't understand why we don't let users know that there is a
> >>>> build that we are testing so we get more eyes on it, before we call it
> >>>> a GA. Is there any practical reason? or is it just the way it has
> >>>> always been done?
> >>>
> >>> It is supposed to be posted as a test build on the dev list only, for
> >>> exactly that purpose. It doesn't get posted to the user list because
> >>> it's not a release until it's voted on, and only releases are intended
> >>> for use by users (as opposed to developers).
> >>>
> >>> One thing that seems to have changed is that the RM is sending out
> >>> only a single message, combining the "here it is" and the "vote"
> >>> messages into one. We used to send out one message to the dev list
> >>> saying that the build was available, and then some number of days
> >>> later, start a vote thread, assuming the build had not been shown to
> >>> be bad in the meantime. Check out the dev list archives and you'll see
> >>> what I mean.
> >>>
> >>> It seems to me that it would be good to go back to that two-stage
> >>> process. The only reason I can recall for moving away from it was that
> >>> some people wanted to get releases out faster, and didn't like the
> >>> delay caused by waiting for a few days before starting the vote.
> >>> Frankly I think that rushing releases is just not worth it if they end
> >>> up having to be retracted later because of problems. (That does not do
> >>> anything for our image as a quality framework either, if we keep
> >>> having to pull releases that we originally claimed were GA quality.)
> >>>
> >>
> >> First, I thought the consensus was that we weren't pulling this
> >> release. Personally, I could go either way.
> >
> > Ditto. I am also OK either way in this situation.
> >
> >> On one hand, the docs zip
> >> is bad, but on the other hand, we have been sitting on well over 100
> >> closed JIRAs. Which brings me to my second point. I think just as much
> >> or more damage is done by not performing releases in a timely fashion.
> >> I would like to get closer to the 'release early, release often' agile
> >> style. I can see your point Martin, and I'm not necessarily arguing
> >> against it, but we do need to meet somewhere in the middle and get
> >> bugfixes out to our users. I'll wager anyone that there are more
> >> messages that include "the fix is in trunk" than there have been GA
> >> releases pulled.
> >
> > First, let me be clear. I am *not* advocating for slowing down the
> > rate at which we put out releases. I am all for "release early,
> > release often".
> >
> > What I would argue against, though, is the notion that collapsing the
> > cycle we previously had (announce a build, allow some time for people
> > to check it out, call a vote and decide whether it is GA or beta or
> > should stay just a test build and not be a release at all) into a
> > single step ("here is it, quick, is it GA?") meaningfully slows down
> > the process. Unless you're on a tear and releasing a new expected-GA
> > release every week to two, using our previous release mechanics does
> > *not* significantly slow down the process, and does have significant
> > potential for increasing the confidence in the quality that we end up
> > assigning to that build.
> >
> >> That being said, I get the feeling sometimes that we waste a lot of
> >> time over-analyzing. I think people are scared to contribute because
> >> they are worried about screwing things up. I enjoy working on this
> >> stuff and I enjoy using Struts, but I think we need to foster more
> >> participation with the users (I mean, they are java devs too!).
> >
> > To some extent, I agree. We do need to encourage participation. The
> > only caveats are that we have to assume that people interested in
> > helping with Struts development are reading the dev list (that is, we
> > cannot enlist the user list population in testing pre-release code),
> > and, in my opinion, we should have a high degree of confidence when we
> > label something as GA, since that has significant implications for our
> > users.
> >
> >> I will
> >> stick to whatever waiting periods for votes, etc. but I personally
> >> want to see things move a little faster and I'm trying pretty hard to
> >> encourage that by example. I think it's much more productive to
> >> concentrate on moving forward than it is to add more
> >> discussions/feedback each time we hit a glitch. The last two builds
> >> (2.1.7 & 2.1.8) have been broken because of environmental problems,
> >> not code. My gut reaction is that this is due to our release process
> >> and release mechanics growing out of control. Doing a release includes
> >> quite a few artifacts and as we found out this time, it is not near as
> >> robustly automated as it needs to be.
> >
> > Some portions of the timing are part of the ASF process (e.g. votes
> > being open for 72 hours) that we must abide by. Others, such as
> > announcing a test build and allowing some time before starting a vote,
> > are for us to decide. As I said above, I am happy for us to move
> > quickly. But I also believe that we can move quickly without rushing.
> >
> > --
> > Martin Cooper
> >
> >
> >> -Wes
> >>
> >>
> >> --
> >> Wes Wannemacher
> >>
> >> Head Engineer, WanTii, Inc.
> >> Need Training? Struts, Spring, Maven, Tomcat...
> >> Ask me for a quote!
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> >> For additional commands, e-mail: dev-h...@struts.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> > For additional commands, e-mail: dev-h...@struts.apache.org
> >
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/
