You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Dan Becker (JIRA)" <de...@tuscany.apache.org> on 2009/02/05 22:10:59 UTC
[jira] Commented: (TUSCANY-2806) Modules in the build depend on
modules later on in the build
[ https://issues.apache.org/jira/browse/TUSCANY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670907#action_12670907 ]
Dan Becker commented on TUSCANY-2806:
-------------------------------------
I see this issue as well. I updated to trunk revision 741267 and I see
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running calculator.CalculatorTestCase
Feb 5, 2009 2:49:59 PM org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher
Util collectClasspathEntries
INFO: Runtime classpath: 1 JAR from E:\t\java\sca\modules\node-launcher-equinox\
target
Feb 5, 2009 2:49:59 PM org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher
Util collectClasspathEntries
INFO: Runtime classpath: 6 JARs from E:\t\java\sca\modules\node-launcher-equinox
Feb 5, 2009 2:49:59 PM org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher
Util collectClassLoaderClasspathEntries
INFO: Runtime classpath: 1 JAR from application classpath.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.813 sec <<< FA
ILURE!
calculator.CalculatorTestCase Time elapsed: 0 sec <<< ERROR!
java.lang.IllegalStateException: java.lang.NullPointerException
at org.apache.tuscany.sca.node.equinox.launcher.EquinoxHost.start(Equino
xHost.java:329)
at org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.<init>(Node
Launcher.java:62)
at org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.newInstance
(NodeLauncher.java:71)
at calculator.CalculatorTestCase.setUpBeforeClass(CalculatorTestCase.jav
a:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
Method.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal
lable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe
thod.java:41)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.
java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.ja
va:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
tSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.java:127)
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(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:338)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:997)
Caused by: java.lang.NullPointerException
at org.apache.tuscany.sca.node.equinox.launcher.EquinoxHost.start(Equino
xHost.java:289)
... 23 more
This is on Windows with Sun JDK 1.6.0_11. I'll report in a moment how the subsequent build runs.
> Modules in the build depend on modules later on in the build
> -------------------------------------------------------------
>
> Key: TUSCANY-2806
> URL: https://issues.apache.org/jira/browse/TUSCANY-2806
> Project: Tuscany
> Issue Type: Bug
> Reporter: ant elder
> Priority: Blocker
> Fix For: Java-SCA-2.0-M1
>
>
> Modules in the build depend on modules later on in the build which means when building them they either fail if its the first time you are building or if the later on module has been changed then the change isn't used until a subsequent build. I think this is one of the reasons we're having so many build problems - you make a change run a build and its fine so check it in, but the changed wasn't used and its not till the next build it gets picked up and you can see if the change was ok or not.
> I think we need to move some thing out of the sca build into separate build and releasable artifacts and other things restructure the build so it runs in a better order.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.