You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2007/03/13 19:09:48 UTC
Another bad Maven day
Something changed in the Maven unit test class loading....
Instrumentation args no longer work... Somehow I think this is
related to the new version of the surefire plugin that I noticed was
loaded on March 7 :-(
Andrus
[INFO] Surefire report directory: /Users/andrus/work/cayenne/itests/
pojo/target/surefire-reports
*** CayenneAgent starting...
org.apache.maven.surefire.booter.SurefireExecutionException:
org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
java.lang.ExceptionInInitializerError: null; nested exception is
org.apache.maven.surefire.testset.TestSetFailedException:
org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
java.lang.ExceptionInInitializerError: null
org.apache.maven.surefire.testset.TestSetFailedException:
org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
java.lang.ExceptionInInitializerError: null
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance
(Constructor.java:494)
at junit.framework.TestSuite.createTest(TestSuite.java:131)
at junit.framework.TestSuite.addTestMethod(TestSuite.java:114)
at junit.framework.TestSuite.<init>(TestSuite.java:75)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance
(Constructor.java:494)
at
org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject
(JUnitTestSet.java:151)
at org.apache.maven.surefire.junit.JUnitTestSet.getTestCount
(JUnitTestSet.java:247)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSet
s(AbstractDirectoryTestSuite.java:104)
at
org.apache.maven.surefire.Surefire.createSuiteFromDefinition
(Surefire.java:150)
at org.apache.maven.surefire.Surefire.run(Surefire.java:111)
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:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
(SurefireBooter.java:290)
at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:818)
Caused by: java.lang.NullPointerException
at org.apache.cayenne.itest.pojo.PojoTestCase.<clinit>
(PojoTestCase.java:35)
... 22 more
Fwd: Another bad Maven day
Posted by Craig L Russell <Cr...@Sun.COM>.
Some crosstalk from OpenJPA which was also bitten by the maven
openfire [sic] bug.
Craig
Begin forwarded message:
> From: Marc Prud'hommeaux <mp...@apache.org>
> Date: March 13, 2007 10:10:28 PM PDT
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Another bad Maven day
> Reply-To: open-jpa-dev@incubator.apache.org
>
> Mike-
>
> Thanks for the tip. Adding <useSystemClassLoader> seems to fix the
> problem so I've gone ahead and added that to our pom.xml.
>
>
>
> On Mar 13, 2007, at 8:05 PM, Michael Dick wrote:
>
>> I think we're running into a side effect of
>> http://jira.codehaus.org/browse/SUREFIRE-301 (just a guess though).
>>
>> I was able to get the tests to run by going back to surefire 2.2,
>> or setting
>> useSystemClassLoader to true in the surefire configuration options.
>>
>> Either way should work. If we set the useSystemClassLoader config
>> option we
>> can pick up new versions of surefire in the mean time. Then again
>> maybe
>> we're better off with a version that we know works.
>>
>> -Mike
>>
>> On 3/13/07, Craig L Russell <Cr...@sun.com> wrote:
>>>
>>> The cayenne guys just hard coded their dependency on surefire to
>>> 2.2.
>>>
>>> I don't know if the maven surefire folks are aware of this issue. I
>>> personally don't know who to talk to over there...
>>>
>>> Craig
>>>
>>> On Mar 13, 2007, at 6:56 PM, Marc Prud'hommeaux wrote:
>>>
>>> > Craig-
>>> >
>>> > Yes, there do appear to be problems. If I clobber my repository
>>> (so
>>> > that the latest surefire plugin is downloaded) and try to run the
>>> > tests, everything fails with "java.lang.ClassNotFoundException:
>>> > org.apache.openjpa.util.CacheMap".
>>> >
>>> > I'll try to look into it tonight...
>>> >
>>> >
>>> >
>>> > On Mar 13, 2007, at 6:17 PM, Craig L Russell wrote:
>>> >
>>> >> The surefire plugin was just updated from 2.2 to 2.3 and the
>>> >> instrumentation no longer works (for the cayenne project at
>>> least).
>>> >>
>>> >> Anyone know whether this affects us?
>>> >>
>>> >> Craig
>>> >>
>>> >> Begin forwarded message:
>>> >>
>>> >>> From: Andrus Adamchik <an...@objectstyle.org>
>>> >>> Date: March 13, 2007 11:09:48 AM PDT
>>> >>> To: dev@cayenne.apache.org
>>> >>> Subject: Another bad Maven day
>>> >>> Reply-To: dev@cayenne.apache.org
>>> >>>
>>> >>> Something changed in the Maven unit test class loading....
>>> >>> Instrumentation args no longer work... Somehow I think this is
>>> >>> related to the new version of the surefire plugin that I noticed
>>> >>> was loaded on March 7 :-(
>>> >>>
>>> >>> Andrus
>>> >>>
>>> >>>
>>> >>> [INFO] Surefire report directory: /Users/andrus/work/cayenne/
>>> >>> itests/pojo/target/surefire-reports
>>> >>> *** CayenneAgent starting...
>>> >>> org.apache.maven.surefire.booter.SurefireExecutionException:
>>> >>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>>> >>> java.lang.ExceptionInInitializerError: null; nested exception is
>>> >>> org.apache.maven.surefire.testset.TestSetFailedException:
>>> >>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>>> >>> java.lang.ExceptionInInitializerError: null
>>> >>> org.apache.maven.surefire.testset.TestSetFailedException:
>>> >>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>>> >>> java.lang.ExceptionInInitializerError: null
>>> >>> java.lang.ExceptionInInitializerError
>>> >>> at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0
>>> >>> (Native Method)
>>> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>>> >>> (NativeConstructorAccessorImpl.java:39)
>>> >>> at
>>> >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>>> >>> (DelegatingConstructorAccessorImpl.java:27)
>>> >>> at java.lang.reflect.Constructor.newInstance
>>> >>> (Constructor.java:494)
>>> >>> at junit.framework.TestSuite.createTest
>>> (TestSuite.java:131)
>>> >>> at junit.framework.TestSuite.addTestMethod
>>> (TestSuite.java:
>>> >>> 114)
>>> >>> at junit.framework.TestSuite.<init>(TestSuite.java:75)
>>> >>> at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0
>>> >>> (Native Method)
>>> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>>> >>> (NativeConstructorAccessorImpl.java:39)
>>> >>> at
>>> >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>>> >>> (DelegatingConstructorAccessorImpl.java:27)
>>> >>> at java.lang.reflect.Constructor.newInstance
>>> >>> (Constructor.java:494)
>>> >>> at
>>> >>> org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject
>>> >>> (JUnitTestSet.java:151)
>>> >>> at
>>> >>> org.apache.maven.surefire.junit.JUnitTestSet.getTestCount
>>> >>> (JUnitTestSet.java:247)
>>> >>> at
>>> >>>
>>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTes
>>> >>> tSets(AbstractDirectoryTestSuite.java:104)
>>> >>> at
>>> >>> org.apache.maven.surefire.Surefire.createSuiteFromDefinition
>>> >>> (Surefire.java:150)
>>> >>> at org.apache.maven.surefire.Surefire.run
>>> (Surefire.java:111)
>>> >>> 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:585)
>>> >>> at
>>> >>>
>>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
>>> >>> (SurefireBooter.java:290)
>>> >>> at org.apache.maven.surefire.booter.SurefireBooter.main
>>> >>> (SurefireBooter.java:818)
>>> >>> Caused by: java.lang.NullPointerException
>>> >>> at org.apache.cayenne.itest.pojo.PojoTestCase.<clinit>
>>> >>> (PojoTestCase.java:35)
>>> >>> ... 22 more
>>> >>>
>>> >>
>>> >> Craig Russell
>>> >> Architect, Sun Java Enterprise System http://java.sun.com/
>>> products/
>>> >> jdo
>>> >> 408 276-5638 mailto:Craig.Russell@sun.com
>>> >> P.S. A good JDO? O, Gasp!
>>> >>
>>> >
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Another bad Maven day
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Mike-
Thanks for the tip. Adding <useSystemClassLoader> seems to fix the
problem so I've gone ahead and added that to our pom.xml.
On Mar 13, 2007, at 8:05 PM, Michael Dick wrote:
> I think we're running into a side effect of
> http://jira.codehaus.org/browse/SUREFIRE-301 (just a guess though).
>
> I was able to get the tests to run by going back to surefire 2.2,
> or setting
> useSystemClassLoader to true in the surefire configuration options.
>
> Either way should work. If we set the useSystemClassLoader config
> option we
> can pick up new versions of surefire in the mean time. Then again
> maybe
> we're better off with a version that we know works.
>
> -Mike
>
> On 3/13/07, Craig L Russell <Cr...@sun.com> wrote:
>>
>> The cayenne guys just hard coded their dependency on surefire to 2.2.
>>
>> I don't know if the maven surefire folks are aware of this issue. I
>> personally don't know who to talk to over there...
>>
>> Craig
>>
>> On Mar 13, 2007, at 6:56 PM, Marc Prud'hommeaux wrote:
>>
>> > Craig-
>> >
>> > Yes, there do appear to be problems. If I clobber my repository (so
>> > that the latest surefire plugin is downloaded) and try to run the
>> > tests, everything fails with "java.lang.ClassNotFoundException:
>> > org.apache.openjpa.util.CacheMap".
>> >
>> > I'll try to look into it tonight...
>> >
>> >
>> >
>> > On Mar 13, 2007, at 6:17 PM, Craig L Russell wrote:
>> >
>> >> The surefire plugin was just updated from 2.2 to 2.3 and the
>> >> instrumentation no longer works (for the cayenne project at
>> least).
>> >>
>> >> Anyone know whether this affects us?
>> >>
>> >> Craig
>> >>
>> >> Begin forwarded message:
>> >>
>> >>> From: Andrus Adamchik <an...@objectstyle.org>
>> >>> Date: March 13, 2007 11:09:48 AM PDT
>> >>> To: dev@cayenne.apache.org
>> >>> Subject: Another bad Maven day
>> >>> Reply-To: dev@cayenne.apache.org
>> >>>
>> >>> Something changed in the Maven unit test class loading....
>> >>> Instrumentation args no longer work... Somehow I think this is
>> >>> related to the new version of the surefire plugin that I noticed
>> >>> was loaded on March 7 :-(
>> >>>
>> >>> Andrus
>> >>>
>> >>>
>> >>> [INFO] Surefire report directory: /Users/andrus/work/cayenne/
>> >>> itests/pojo/target/surefire-reports
>> >>> *** CayenneAgent starting...
>> >>> org.apache.maven.surefire.booter.SurefireExecutionException:
>> >>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>> >>> java.lang.ExceptionInInitializerError: null; nested exception is
>> >>> org.apache.maven.surefire.testset.TestSetFailedException:
>> >>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>> >>> java.lang.ExceptionInInitializerError: null
>> >>> org.apache.maven.surefire.testset.TestSetFailedException:
>> >>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>> >>> java.lang.ExceptionInInitializerError: null
>> >>> java.lang.ExceptionInInitializerError
>> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
>> >>> (Native Method)
>> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>> >>> (NativeConstructorAccessorImpl.java:39)
>> >>> at
>> >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>> >>> (DelegatingConstructorAccessorImpl.java:27)
>> >>> at java.lang.reflect.Constructor.newInstance
>> >>> (Constructor.java:494)
>> >>> at junit.framework.TestSuite.createTest(TestSuite.java:
>> 131)
>> >>> at junit.framework.TestSuite.addTestMethod
>> (TestSuite.java:
>> >>> 114)
>> >>> at junit.framework.TestSuite.<init>(TestSuite.java:75)
>> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
>> >>> (Native Method)
>> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>> >>> (NativeConstructorAccessorImpl.java:39)
>> >>> at
>> >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>> >>> (DelegatingConstructorAccessorImpl.java:27)
>> >>> at java.lang.reflect.Constructor.newInstance
>> >>> (Constructor.java:494)
>> >>> at
>> >>> org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject
>> >>> (JUnitTestSet.java:151)
>> >>> at
>> >>> org.apache.maven.surefire.junit.JUnitTestSet.getTestCount
>> >>> (JUnitTestSet.java:247)
>> >>> at
>> >>>
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTes
>> >>> tSets(AbstractDirectoryTestSuite.java:104)
>> >>> at
>> >>> org.apache.maven.surefire.Surefire.createSuiteFromDefinition
>> >>> (Surefire.java:150)
>> >>> at org.apache.maven.surefire.Surefire.run
>> (Surefire.java:111)
>> >>> 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:585)
>> >>> at
>> >>>
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
>> >>> (SurefireBooter.java:290)
>> >>> at org.apache.maven.surefire.booter.SurefireBooter.main
>> >>> (SurefireBooter.java:818)
>> >>> Caused by: java.lang.NullPointerException
>> >>> at org.apache.cayenne.itest.pojo.PojoTestCase.<clinit>
>> >>> (PojoTestCase.java:35)
>> >>> ... 22 more
>> >>>
>> >>
>> >> Craig Russell
>> >> Architect, Sun Java Enterprise System http://java.sun.com/
>> products/
>> >> jdo
>> >> 408 276-5638 mailto:Craig.Russell@sun.com
>> >> P.S. A good JDO? O, Gasp!
>> >>
>> >
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
Re: Another bad Maven day
Posted by Michael Dick <mi...@gmail.com>.
I think we're running into a side effect of
http://jira.codehaus.org/browse/SUREFIRE-301 (just a guess though).
I was able to get the tests to run by going back to surefire 2.2, or setting
useSystemClassLoader to true in the surefire configuration options.
Either way should work. If we set the useSystemClassLoader config option we
can pick up new versions of surefire in the mean time. Then again maybe
we're better off with a version that we know works.
-Mike
On 3/13/07, Craig L Russell <Cr...@sun.com> wrote:
>
> The cayenne guys just hard coded their dependency on surefire to 2.2.
>
> I don't know if the maven surefire folks are aware of this issue. I
> personally don't know who to talk to over there...
>
> Craig
>
> On Mar 13, 2007, at 6:56 PM, Marc Prud'hommeaux wrote:
>
> > Craig-
> >
> > Yes, there do appear to be problems. If I clobber my repository (so
> > that the latest surefire plugin is downloaded) and try to run the
> > tests, everything fails with "java.lang.ClassNotFoundException:
> > org.apache.openjpa.util.CacheMap".
> >
> > I'll try to look into it tonight...
> >
> >
> >
> > On Mar 13, 2007, at 6:17 PM, Craig L Russell wrote:
> >
> >> The surefire plugin was just updated from 2.2 to 2.3 and the
> >> instrumentation no longer works (for the cayenne project at least).
> >>
> >> Anyone know whether this affects us?
> >>
> >> Craig
> >>
> >> Begin forwarded message:
> >>
> >>> From: Andrus Adamchik <an...@objectstyle.org>
> >>> Date: March 13, 2007 11:09:48 AM PDT
> >>> To: dev@cayenne.apache.org
> >>> Subject: Another bad Maven day
> >>> Reply-To: dev@cayenne.apache.org
> >>>
> >>> Something changed in the Maven unit test class loading....
> >>> Instrumentation args no longer work... Somehow I think this is
> >>> related to the new version of the surefire plugin that I noticed
> >>> was loaded on March 7 :-(
> >>>
> >>> Andrus
> >>>
> >>>
> >>> [INFO] Surefire report directory: /Users/andrus/work/cayenne/
> >>> itests/pojo/target/surefire-reports
> >>> *** CayenneAgent starting...
> >>> org.apache.maven.surefire.booter.SurefireExecutionException:
> >>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
> >>> java.lang.ExceptionInInitializerError: null; nested exception is
> >>> org.apache.maven.surefire.testset.TestSetFailedException:
> >>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
> >>> java.lang.ExceptionInInitializerError: null
> >>> org.apache.maven.surefire.testset.TestSetFailedException:
> >>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
> >>> java.lang.ExceptionInInitializerError: null
> >>> java.lang.ExceptionInInitializerError
> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
> >>> (Native Method)
> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
> >>> (NativeConstructorAccessorImpl.java:39)
> >>> at
> >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> >>> (DelegatingConstructorAccessorImpl.java:27)
> >>> at java.lang.reflect.Constructor.newInstance
> >>> (Constructor.java:494)
> >>> at junit.framework.TestSuite.createTest(TestSuite.java:131)
> >>> at junit.framework.TestSuite.addTestMethod(TestSuite.java:
> >>> 114)
> >>> at junit.framework.TestSuite.<init>(TestSuite.java:75)
> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
> >>> (Native Method)
> >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
> >>> (NativeConstructorAccessorImpl.java:39)
> >>> at
> >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> >>> (DelegatingConstructorAccessorImpl.java:27)
> >>> at java.lang.reflect.Constructor.newInstance
> >>> (Constructor.java:494)
> >>> at
> >>> org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject
> >>> (JUnitTestSet.java:151)
> >>> at
> >>> org.apache.maven.surefire.junit.JUnitTestSet.getTestCount
> >>> (JUnitTestSet.java:247)
> >>> at
> >>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTes
> >>> tSets(AbstractDirectoryTestSuite.java:104)
> >>> at
> >>> org.apache.maven.surefire.Surefire.createSuiteFromDefinition
> >>> (Surefire.java:150)
> >>> at org.apache.maven.surefire.Surefire.run(Surefire.java:111)
> >>> 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:585)
> >>> at
> >>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
> >>> (SurefireBooter.java:290)
> >>> at org.apache.maven.surefire.booter.SurefireBooter.main
> >>> (SurefireBooter.java:818)
> >>> Caused by: java.lang.NullPointerException
> >>> at org.apache.cayenne.itest.pojo.PojoTestCase.<clinit>
> >>> (PojoTestCase.java:35)
> >>> ... 22 more
> >>>
> >>
> >> Craig Russell
> >> Architect, Sun Java Enterprise System http://java.sun.com/products/
> >> jdo
> >> 408 276-5638 mailto:Craig.Russell@sun.com
> >> P.S. A good JDO? O, Gasp!
> >>
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
Re: Another bad Maven day
Posted by Craig L Russell <Cr...@Sun.COM>.
The cayenne guys just hard coded their dependency on surefire to 2.2.
I don't know if the maven surefire folks are aware of this issue. I
personally don't know who to talk to over there...
Craig
On Mar 13, 2007, at 6:56 PM, Marc Prud'hommeaux wrote:
> Craig-
>
> Yes, there do appear to be problems. If I clobber my repository (so
> that the latest surefire plugin is downloaded) and try to run the
> tests, everything fails with "java.lang.ClassNotFoundException:
> org.apache.openjpa.util.CacheMap".
>
> I'll try to look into it tonight...
>
>
>
> On Mar 13, 2007, at 6:17 PM, Craig L Russell wrote:
>
>> The surefire plugin was just updated from 2.2 to 2.3 and the
>> instrumentation no longer works (for the cayenne project at least).
>>
>> Anyone know whether this affects us?
>>
>> Craig
>>
>> Begin forwarded message:
>>
>>> From: Andrus Adamchik <an...@objectstyle.org>
>>> Date: March 13, 2007 11:09:48 AM PDT
>>> To: dev@cayenne.apache.org
>>> Subject: Another bad Maven day
>>> Reply-To: dev@cayenne.apache.org
>>>
>>> Something changed in the Maven unit test class loading....
>>> Instrumentation args no longer work... Somehow I think this is
>>> related to the new version of the surefire plugin that I noticed
>>> was loaded on March 7 :-(
>>>
>>> Andrus
>>>
>>>
>>> [INFO] Surefire report directory: /Users/andrus/work/cayenne/
>>> itests/pojo/target/surefire-reports
>>> *** CayenneAgent starting...
>>> org.apache.maven.surefire.booter.SurefireExecutionException:
>>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>>> java.lang.ExceptionInInitializerError: null; nested exception is
>>> org.apache.maven.surefire.testset.TestSetFailedException:
>>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>>> java.lang.ExceptionInInitializerError: null
>>> org.apache.maven.surefire.testset.TestSetFailedException:
>>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>>> java.lang.ExceptionInInitializerError: null
>>> java.lang.ExceptionInInitializerError
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
>>> (Native Method)
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>>> (NativeConstructorAccessorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>>> (DelegatingConstructorAccessorImpl.java:27)
>>> at java.lang.reflect.Constructor.newInstance
>>> (Constructor.java:494)
>>> at junit.framework.TestSuite.createTest(TestSuite.java:131)
>>> at junit.framework.TestSuite.addTestMethod(TestSuite.java:
>>> 114)
>>> at junit.framework.TestSuite.<init>(TestSuite.java:75)
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
>>> (Native Method)
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>>> (NativeConstructorAccessorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>>> (DelegatingConstructorAccessorImpl.java:27)
>>> at java.lang.reflect.Constructor.newInstance
>>> (Constructor.java:494)
>>> at
>>> org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject
>>> (JUnitTestSet.java:151)
>>> at
>>> org.apache.maven.surefire.junit.JUnitTestSet.getTestCount
>>> (JUnitTestSet.java:247)
>>> at
>>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTes
>>> tSets(AbstractDirectoryTestSuite.java:104)
>>> at
>>> org.apache.maven.surefire.Surefire.createSuiteFromDefinition
>>> (Surefire.java:150)
>>> at org.apache.maven.surefire.Surefire.run(Surefire.java:111)
>>> 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:585)
>>> at
>>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
>>> (SurefireBooter.java:290)
>>> at org.apache.maven.surefire.booter.SurefireBooter.main
>>> (SurefireBooter.java:818)
>>> Caused by: java.lang.NullPointerException
>>> at org.apache.cayenne.itest.pojo.PojoTestCase.<clinit>
>>> (PojoTestCase.java:35)
>>> ... 22 more
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Another bad Maven day
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Craig-
Yes, there do appear to be problems. If I clobber my repository (so
that the latest surefire plugin is downloaded) and try to run the
tests, everything fails with "java.lang.ClassNotFoundException:
org.apache.openjpa.util.CacheMap".
I'll try to look into it tonight...
On Mar 13, 2007, at 6:17 PM, Craig L Russell wrote:
> The surefire plugin was just updated from 2.2 to 2.3 and the
> instrumentation no longer works (for the cayenne project at least).
>
> Anyone know whether this affects us?
>
> Craig
>
> Begin forwarded message:
>
>> From: Andrus Adamchik <an...@objectstyle.org>
>> Date: March 13, 2007 11:09:48 AM PDT
>> To: dev@cayenne.apache.org
>> Subject: Another bad Maven day
>> Reply-To: dev@cayenne.apache.org
>>
>> Something changed in the Maven unit test class loading....
>> Instrumentation args no longer work... Somehow I think this is
>> related to the new version of the surefire plugin that I noticed
>> was loaded on March 7 :-(
>>
>> Andrus
>>
>>
>> [INFO] Surefire report directory: /Users/andrus/work/cayenne/
>> itests/pojo/target/surefire-reports
>> *** CayenneAgent starting...
>> org.apache.maven.surefire.booter.SurefireExecutionException:
>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>> java.lang.ExceptionInInitializerError: null; nested exception is
>> org.apache.maven.surefire.testset.TestSetFailedException:
>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>> java.lang.ExceptionInInitializerError: null
>> org.apache.maven.surefire.testset.TestSetFailedException:
>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>> java.lang.ExceptionInInitializerError: null
>> java.lang.ExceptionInInitializerError
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
>> (Native Method)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>> (NativeConstructorAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>> (DelegatingConstructorAccessorImpl.java:27)
>> at java.lang.reflect.Constructor.newInstance
>> (Constructor.java:494)
>> at junit.framework.TestSuite.createTest(TestSuite.java:131)
>> at junit.framework.TestSuite.addTestMethod(TestSuite.java:
>> 114)
>> at junit.framework.TestSuite.<init>(TestSuite.java:75)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
>> (Native Method)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>> (NativeConstructorAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>> (DelegatingConstructorAccessorImpl.java:27)
>> at java.lang.reflect.Constructor.newInstance
>> (Constructor.java:494)
>> at
>> org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject
>> (JUnitTestSet.java:151)
>> at
>> org.apache.maven.surefire.junit.JUnitTestSet.getTestCount
>> (JUnitTestSet.java:247)
>> at
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTest
>> Sets(AbstractDirectoryTestSuite.java:104)
>> at
>> org.apache.maven.surefire.Surefire.createSuiteFromDefinition
>> (Surefire.java:150)
>> at org.apache.maven.surefire.Surefire.run(Surefire.java:111)
>> 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:585)
>> at
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
>> (SurefireBooter.java:290)
>> at org.apache.maven.surefire.booter.SurefireBooter.main
>> (SurefireBooter.java:818)
>> Caused by: java.lang.NullPointerException
>> at org.apache.cayenne.itest.pojo.PojoTestCase.<clinit>
>> (PojoTestCase.java:35)
>> ... 22 more
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Fwd: Another bad Maven day
Posted by Craig L Russell <Cr...@Sun.COM>.
The surefire plugin was just updated from 2.2 to 2.3 and the
instrumentation no longer works (for the cayenne project at least).
Anyone know whether this affects us?
Craig
Begin forwarded message:
> From: Andrus Adamchik <an...@objectstyle.org>
> Date: March 13, 2007 11:09:48 AM PDT
> To: dev@cayenne.apache.org
> Subject: Another bad Maven day
> Reply-To: dev@cayenne.apache.org
>
> Something changed in the Maven unit test class loading....
> Instrumentation args no longer work... Somehow I think this is
> related to the new version of the surefire plugin that I noticed
> was loaded on March 7 :-(
>
> Andrus
>
>
> [INFO] Surefire report directory: /Users/andrus/work/cayenne/itests/
> pojo/target/surefire-reports
> *** CayenneAgent starting...
> org.apache.maven.surefire.booter.SurefireExecutionException:
> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
> java.lang.ExceptionInInitializerError: null; nested exception is
> org.apache.maven.surefire.testset.TestSetFailedException:
> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
> java.lang.ExceptionInInitializerError: null
> org.apache.maven.surefire.testset.TestSetFailedException:
> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
> java.lang.ExceptionInInitializerError: null
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
> (Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance
> (Constructor.java:494)
> at junit.framework.TestSuite.createTest(TestSuite.java:131)
> at junit.framework.TestSuite.addTestMethod(TestSuite.java:114)
> at junit.framework.TestSuite.<init>(TestSuite.java:75)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
> (Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance
> (Constructor.java:494)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject
> (JUnitTestSet.java:151)
> at org.apache.maven.surefire.junit.JUnitTestSet.getTestCount
> (JUnitTestSet.java:247)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestS
> ets(AbstractDirectoryTestSuite.java:104)
> at
> org.apache.maven.surefire.Surefire.createSuiteFromDefinition
> (Surefire.java:150)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:111)
> 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:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
> (SurefireBooter.java:290)
> at org.apache.maven.surefire.booter.SurefireBooter.main
> (SurefireBooter.java:818)
> Caused by: java.lang.NullPointerException
> at org.apache.cayenne.itest.pojo.PojoTestCase.<clinit>
> (PojoTestCase.java:35)
> ... 22 more
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Another bad Maven day
Posted by Michael Gentry <bl...@gmail.com>.
11. Hire contractors to ride the dead horse.
That one hits way too close to home at the moment ...
As for Maven ... I'm not an expert on it, but I never had trouble
building in the pre-Maven days ...
/dev/mrg
On 3/13/07, Ahmed Mohombe <am...@yahoo.com> wrote:
> > Something changed in the Maven unit test class loading....
> > Instrumentation args no longer work... Somehow I think this is related
> > to the new version of the surefire plugin that I noticed was loaded on
> > March 7 :-(
> This fits to Maven like a glove:
> http://www.thehumorarchives.com/joke/Beating_a_Dead_Horse
>
> Ahmed.
>
>
Re: Another bad Maven day
Posted by Ahmed Mohombe <am...@yahoo.com>.
> Something changed in the Maven unit test class loading....
> Instrumentation args no longer work... Somehow I think this is related
> to the new version of the surefire plugin that I noticed was loaded on
> March 7 :-(
This fits to Maven like a glove:
http://www.thehumorarchives.com/joke/Beating_a_Dead_Horse
Ahmed.
Ivy [Was: Another bad Maven day]
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 13, 2007, at 11:59 PM, Aristedes Maniatis wrote:
> If so, I've ready some nice things about the Apache Ivy project for
> dependency management in ant.
Read the Ivy docs. Looks nice - just like Maven does to an
uninitiated person :-) In fact it does look a bit like Maven in
terminology and approach. But at least it seems to concentrate on a
single problem of dependency management, instead of taking over your
build system.
So there is a chance that we can preserve the ability to develop
modules one-by-one in Eclipse and otherwise. I hope the Eclipse
plugin [1] is of better quality than its Maven counterpart.
[1] http://www.jaya.free.fr/ivyde/download.html
Andrus
Re: Another bad Maven day
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I'll try to find time this weekend and revert the build system to Ant
> (based on 2.0 but following the new project structure).
Using "parallel" might improve the build speed a little.
http://www.testearly.com/2007/03/13/coordinating-ant-targets-for-faster-builds/
The Cayenne build doesn't seem to use it so far.
Ahmed.
Re: Another bad Maven day
Posted by Ahmed Mohombe <am...@yahoo.com>.
> One question though - are we allowed to have LGPL dependencies in SVN,
> if we don't release them? Anyone knows that?
ClickFramework is using a simple "get-deps" taks to download all required jars:
http://click.svn.sourceforge.net/viewvc/click/trunk/click/build/build.xml?view=markup#l_344
This way, there's no need to put in SVN jar files, so there are for sure *no* license issues.
Since this is manually triggered by the user(with no maven "magic") it's pretty simple to control
and fix if something goes wrong (or even debug with the ant debugger for Eclipse and NB).
Ahmed.
Re: Another bad Maven day
Posted by Mike Kienenberger <mk...@gmail.com>.
Ugh. Yes, I'm still using Eclipse 3.1.2. I know that I'm wrong, but
it seems like I'm constantly upgrading Eclipse (which is always a
time-consuming processes).
I still have a version of Eclipse 3.0 installed that I use for
maintaining older projects.
On 3/15/07, Kevin Menard <km...@servprise.com> wrote:
> > -----Original Message-----
> > From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> > Sent: Wednesday, March 14, 2007 11:41 AM
> > To: dev@cayenne.apache.org
> > Subject: Re: Another bad Maven day
> >
> > Yeah ... it is just that something happens once a week at least.
> > Really tired of broken builds, Eclipse Maven plugin breaking
> > command- line Maven and vice versa,
>
> Another potential issue may be the following email. I'm not sure who
> still runs eclipse 3.1 (I think Mike mentioned he did), but you may have
> to upgrade to 3.2 to use the plugin in the near future.
>
> --
> From Eugene Kuleshov (one of the primary eclipse plugin devs) on
> 3/12/07:
>
> Folks,
>
> I have to admit that I won't be able to maintain compatibility with
> Eclipse 3.1 (not to mention 3.0).
>
> So, if anyone is willing to commit to testing and maintaining support
> for that Eclipse version (including contributing fixes), please raise
> your voice.
>
> regards,
> Eugene
>
RE: Another bad Maven day
Posted by Kevin Menard <km...@servprise.com>.
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Wednesday, March 14, 2007 11:41 AM
> To: dev@cayenne.apache.org
> Subject: Re: Another bad Maven day
>
> Yeah ... it is just that something happens once a week at least.
> Really tired of broken builds, Eclipse Maven plugin breaking
> command- line Maven and vice versa,
Another potential issue may be the following email. I'm not sure who
still runs eclipse 3.1 (I think Mike mentioned he did), but you may have
to upgrade to 3.2 to use the plugin in the near future.
--
>From Eugene Kuleshov (one of the primary eclipse plugin devs) on
3/12/07:
Folks,
I have to admit that I won't be able to maintain compatibility with
Eclipse 3.1 (not to mention 3.0).
So, if anyone is willing to commit to testing and maintaining support
for that Eclipse version (including contributing fixes), please raise
your voice.
regards,
Eugene
Re: Another bad Maven day
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 14, 2007, at 6:27 PM, Mike Kienenberger wrote:
> Andrus,
>
> While I'm certainly in favor of going back to an ant-based build
> system, another solution to this problem might be hardcoding specific
> plugin versions in maven as stated by Dain.
Yeah ... it is just that something happens once a week at least.
Really tired of broken builds, Eclipse Maven plugin breaking command-
line Maven and vice versa, developer complaints and an unknown number
of people who are discouraged to contribute to Cayenne because they
can't build it. Some time back I posted a list of reasons why we
would want to stay on Maven, but my patience with this technology is
running thin. The voice of reason tells me that we have to stick with
the crap build system we've got (and maybe I'll listen this time),
but sometimes I just can't hold it :-/
Whatever we do, it has to be done on a branch first of course, and
there will be a maven component to it (at least for cayenne cgen+
maven plugin). So this promises to be fun already.
Andrus
Re: Another bad Maven day
Posted by Mike Kienenberger <mk...@gmail.com>.
Andrus,
While I'm certainly in favor of going back to an ant-based build
system, another solution to this problem might be hardcoding specific
plugin versions in maven as stated by Dain.
On 3/14/07, Andrus Adamchik <an...@objectstyle.org> wrote:
> I'll try to find time this weekend and revert the build system to Ant
> (based on 2.0 but following the new project structure). If I can do
> it in two days, then bye-bye Maven. Later we can improve it with Ivy,
> etc. For now I am planning manual dependency handling.
>
> One question though - are we allowed to have LGPL dependencies in
> SVN, if we don't release them? Anyone knows that?
>
> Andrus
>
>
> On Mar 13, 2007, at 11:59 PM, Aristedes Maniatis wrote:
> > On 14/03/2007, at 5:21 AM, Andrus Adamchik wrote:
> >
> >> While I am on that pessimistic Maven rant ... Continuous
> >> integration (the maven way) somehow includes the underlying build
> >> system made of dozens of plugins constantly updated by multiple
> >> third parties. Maybe we should revert to Ant ?
> >
> > Firstly, I found this: https://maven-repository-
> > importer.dev.java.net/source/browse/*checkout*/maven-repository-
> > importer/maven-repository-importer/doc/index.html
> >
> > This is a plugin which supposedly makes it easy to publish to maven
> > repositories from ant. But I haven't tried it, so I don't know how
> > workable it is.
> >
> > Secondly, Cayenne dependencies are pretty simple aren't they? Is it
> > as simple as having a /lib folder and a VERSIONS.txt file which
> > tracks what version of each lib we are using? Or is there something
> > more complex involved here? If so, I've ready some nice things
> > about the Apache Ivy project for dependency management in ant.
> >
> > Ari
> >
> >
> >
> > -------------------------->
> > Aristedes Maniatis
> > phone +61 2 9660 9700
> > PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
>
>
Re: Another bad Maven day
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 14, 2007, at 12:54 PM, Andrus Adamchik wrote:
> I'll try to find time this weekend and revert the build system to
> Ant (based on 2.0 but following the new project structure). If I
> can do it in two days, then bye-bye Maven.
Every time I say something about finding time, it immediately becomes
clear I don't have any :-(
Now I cooled down a bit and feel like spending whatever time I have
on feature development is still the best choice for now. Doesn't mean
somebody else can't try to accomplish this.
Andrus
Re: Another bad Maven day
Posted by Mike Kienenberger <mk...@gmail.com>.
I do not think we're allowed to have LGPL dependencies in svn. I've
seen other threads recommending no jar files in svn, but this appears
to be a matter of opinion rather than policy.
On 3/14/07, Andrus Adamchik <an...@objectstyle.org> wrote:
> I'll try to find time this weekend and revert the build system to Ant
> (based on 2.0 but following the new project structure). If I can do
> it in two days, then bye-bye Maven. Later we can improve it with Ivy,
> etc. For now I am planning manual dependency handling.
>
> One question though - are we allowed to have LGPL dependencies in
> SVN, if we don't release them? Anyone knows that?
>
> Andrus
>
>
> On Mar 13, 2007, at 11:59 PM, Aristedes Maniatis wrote:
> > On 14/03/2007, at 5:21 AM, Andrus Adamchik wrote:
> >
> >> While I am on that pessimistic Maven rant ... Continuous
> >> integration (the maven way) somehow includes the underlying build
> >> system made of dozens of plugins constantly updated by multiple
> >> third parties. Maybe we should revert to Ant ?
> >
> > Firstly, I found this: https://maven-repository-
> > importer.dev.java.net/source/browse/*checkout*/maven-repository-
> > importer/maven-repository-importer/doc/index.html
> >
> > This is a plugin which supposedly makes it easy to publish to maven
> > repositories from ant. But I haven't tried it, so I don't know how
> > workable it is.
> >
> > Secondly, Cayenne dependencies are pretty simple aren't they? Is it
> > as simple as having a /lib folder and a VERSIONS.txt file which
> > tracks what version of each lib we are using? Or is there something
> > more complex involved here? If so, I've ready some nice things
> > about the Apache Ivy project for dependency management in ant.
> >
> > Ari
> >
> >
> >
> > -------------------------->
> > Aristedes Maniatis
> > phone +61 2 9660 9700
> > PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
>
>
Re: Another bad Maven day
Posted by Andrus Adamchik <an...@objectstyle.org>.
I'll try to find time this weekend and revert the build system to Ant
(based on 2.0 but following the new project structure). If I can do
it in two days, then bye-bye Maven. Later we can improve it with Ivy,
etc. For now I am planning manual dependency handling.
One question though - are we allowed to have LGPL dependencies in
SVN, if we don't release them? Anyone knows that?
Andrus
On Mar 13, 2007, at 11:59 PM, Aristedes Maniatis wrote:
> On 14/03/2007, at 5:21 AM, Andrus Adamchik wrote:
>
>> While I am on that pessimistic Maven rant ... Continuous
>> integration (the maven way) somehow includes the underlying build
>> system made of dozens of plugins constantly updated by multiple
>> third parties. Maybe we should revert to Ant ?
>
> Firstly, I found this: https://maven-repository-
> importer.dev.java.net/source/browse/*checkout*/maven-repository-
> importer/maven-repository-importer/doc/index.html
>
> This is a plugin which supposedly makes it easy to publish to maven
> repositories from ant. But I haven't tried it, so I don't know how
> workable it is.
>
> Secondly, Cayenne dependencies are pretty simple aren't they? Is it
> as simple as having a /lib folder and a VERSIONS.txt file which
> tracks what version of each lib we are using? Or is there something
> more complex involved here? If so, I've ready some nice things
> about the Apache Ivy project for dependency management in ant.
>
> Ari
>
>
>
> -------------------------->
> Aristedes Maniatis
> phone +61 2 9660 9700
> PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
Re: Another bad Maven day
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 14/03/2007, at 5:21 AM, Andrus Adamchik wrote:
> While I am on that pessimistic Maven rant ... Continuous
> integration (the maven way) somehow includes the underlying build
> system made of dozens of plugins constantly updated by multiple
> third parties. Maybe we should revert to Ant ?
Firstly, I found this: https://maven-repository-importer.dev.java.net/
source/browse/*checkout*/maven-repository-importer/maven-repository-
importer/doc/index.html
This is a plugin which supposedly makes it easy to publish to maven
repositories from ant. But I haven't tried it, so I don't know how
workable it is.
Secondly, Cayenne dependencies are pretty simple aren't they? Is it
as simple as having a /lib folder and a VERSIONS.txt file which
tracks what version of each lib we are using? Or is there something
more complex involved here? If so, I've ready some nice things about
the Apache Ivy project for dependency management in ant.
Ari
-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
Re: Another bad Maven day
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 13, 2007, at 8:09 PM, Andrus Adamchik wrote:
> Something changed in the Maven unit test class loading....
> Instrumentation args no longer work... Somehow I think this is
> related to the new version of the surefire plugin that I noticed
> was loaded on March 7 :-(
>
> Andrus
While I am on that pessimistic Maven rant ... Continuous integration
(the maven way) somehow includes the underlying build system made of
dozens of plugins constantly updated by multiple third parties. Maybe
we should revert to Ant ?
Andrus
Re: Another bad Maven day
Posted by Andrus Adamchik <an...@objectstyle.org>.
I hardcoded the version of surefire in the pom and it works now.
Andrus
On Mar 14, 2007, at 12:26 AM, Dain Sundstrom wrote:
> I ran into a problem similar problem with maven the other day....
> The maven project released a new version (2.3) of the surefire test
> plugin. This plugin changed the class loader model among other
> stuff. It appears that the plugin now has a child first delegation
> model on, which means, for example, that classes loaded by the
> javaagent are not visible to test classes.
>
> Ultimately, I was not able to code around all the changes and
> simply "fixed" the situation by hard coding the plugin to version 2.2.
>
> -dain
>
> On Mar 13, 2007, at 11:09 AM, Andrus Adamchik wrote:
>
>> Something changed in the Maven unit test class loading....
>> Instrumentation args no longer work... Somehow I think this is
>> related to the new version of the surefire plugin that I noticed
>> was loaded on March 7 :-(
>>
>> Andrus
>>
>>
>> [INFO] Surefire report directory: /Users/andrus/work/cayenne/
>> itests/pojo/target/surefire-reports
>> *** CayenneAgent starting...
>> org.apache.maven.surefire.booter.SurefireExecutionException:
>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>> java.lang.ExceptionInInitializerError: null; nested exception is
>> org.apache.maven.surefire.testset.TestSetFailedException:
>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>> java.lang.ExceptionInInitializerError: null
>> org.apache.maven.surefire.testset.TestSetFailedException:
>> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
>> java.lang.ExceptionInInitializerError: null
>> java.lang.ExceptionInInitializerError
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
>> (Native Method)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>> (NativeConstructorAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>> (DelegatingConstructorAccessorImpl.java:27)
>> at java.lang.reflect.Constructor.newInstance
>> (Constructor.java:494)
>> at junit.framework.TestSuite.createTest(TestSuite.java:131)
>> at junit.framework.TestSuite.addTestMethod(TestSuite.java:
>> 114)
>> at junit.framework.TestSuite.<init>(TestSuite.java:75)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
>> (Native Method)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance
>> (NativeConstructorAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance
>> (DelegatingConstructorAccessorImpl.java:27)
>> at java.lang.reflect.Constructor.newInstance
>> (Constructor.java:494)
>> at
>> org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject
>> (JUnitTestSet.java:151)
>> at
>> org.apache.maven.surefire.junit.JUnitTestSet.getTestCount
>> (JUnitTestSet.java:247)
>> at
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTest
>> Sets(AbstractDirectoryTestSuite.java:104)
>> at
>> org.apache.maven.surefire.Surefire.createSuiteFromDefinition
>> (Surefire.java:150)
>> at org.apache.maven.surefire.Surefire.run(Surefire.java:111)
>> 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:585)
>> at
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
>> (SurefireBooter.java:290)
>> at org.apache.maven.surefire.booter.SurefireBooter.main
>> (SurefireBooter.java:818)
>> Caused by: java.lang.NullPointerException
>> at org.apache.cayenne.itest.pojo.PojoTestCase.<clinit>
>> (PojoTestCase.java:35)
>> ... 22 more
>
Re: Another bad Maven day
Posted by Dain Sundstrom <da...@iq80.com>.
I ran into a problem similar problem with maven the other day.... The
maven project released a new version (2.3) of the surefire test
plugin. This plugin changed the class loader model among other
stuff. It appears that the plugin now has a child first delegation
model on, which means, for example, that classes loaded by the
javaagent are not visible to test classes.
Ultimately, I was not able to code around all the changes and simply
"fixed" the situation by hard coding the plugin to version 2.2.
-dain
On Mar 13, 2007, at 11:09 AM, Andrus Adamchik wrote:
> Something changed in the Maven unit test class loading....
> Instrumentation args no longer work... Somehow I think this is
> related to the new version of the surefire plugin that I noticed
> was loaded on March 7 :-(
>
> Andrus
>
>
> [INFO] Surefire report directory: /Users/andrus/work/cayenne/itests/
> pojo/target/surefire-reports
> *** CayenneAgent starting...
> org.apache.maven.surefire.booter.SurefireExecutionException:
> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
> java.lang.ExceptionInInitializerError: null; nested exception is
> org.apache.maven.surefire.testset.TestSetFailedException:
> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
> java.lang.ExceptionInInitializerError: null
> org.apache.maven.surefire.testset.TestSetFailedException:
> org.apache.cayenne.itest.pojo.ExposedPkTest; nested exception is
> java.lang.ExceptionInInitializerError: null
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
> (Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance
> (Constructor.java:494)
> at junit.framework.TestSuite.createTest(TestSuite.java:131)
> at junit.framework.TestSuite.addTestMethod(TestSuite.java:114)
> at junit.framework.TestSuite.<init>(TestSuite.java:75)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0
> (Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance
> (Constructor.java:494)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject
> (JUnitTestSet.java:151)
> at org.apache.maven.surefire.junit.JUnitTestSet.getTestCount
> (JUnitTestSet.java:247)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestS
> ets(AbstractDirectoryTestSuite.java:104)
> at
> org.apache.maven.surefire.Surefire.createSuiteFromDefinition
> (Surefire.java:150)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:111)
> 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:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
> (SurefireBooter.java:290)
> at org.apache.maven.surefire.booter.SurefireBooter.main
> (SurefireBooter.java:818)
> Caused by: java.lang.NullPointerException
> at org.apache.cayenne.itest.pojo.PojoTestCase.<clinit>
> (PojoTestCase.java:35)
> ... 22 more
>