I get the following error when trying to run CategorizationSuite on the trunk (as of 37406 or so): java.io.InputStream is null c.a.util.AssertionError: java.io.InputStream is null at c.a.util.Assert.exists(Assert.java:179) at c.a.runtime.AbstractConfig.require(AbstractConfig.java:67) at c.a.runtime.RuntimeConfig.getConfig(RuntimeConfig.java:60) at c.a.tools.junit.extensions.BaseTestSetup.setUp(BaseTestSetup.java:94) at c.a.tools.junit.extensions.BaseTestSetup$1.protect(BaseTestSetup.java:71) The offendingline in RuntimeConfig is s_config.require("ccm-core/runtime.properties"); This tries to load the file "ccm-core/runtime.properties" and fails, because the classloader can't find it. The reason this same code doesn't fail in a running server is because the file is deployed into the Resin's "conf" directory: $ cat $CCM_HOME/conf/ccm-core/runtime.properties # Generated by com.arsdigita.packaging.ConfigTool #Mon Oct 27 16:07:00 EST 2003 waf.runtime.jdbc_url=jdbc\:postgresql\:cat?user\=postgres Resin makes sure the conf/ directory is available to its classloader. When running "ant -Djunit.suite=CategorizationSuite.class", all we have is whatever Ant put on the classpath. I added System.err.println ("java.class.path=" + System.getProperty("java.class.path")); before the point of failure. After removing all the .jar and .zip files, the classpath looks like so $CCM_DEV_HOME/core/build/classes $CCM_DEV_HOME/core/build/sql $CCM_DEV_HOME/core/pdl $CCM_DEV_HOME/core/build/tests/classes One possible way to resolve this is change build.xml so that runtime.properties gets copied someplace where the classloader can find it.
as of 37410, $CCM_HOME/conf is in the build.xml classpath
I grabbed the updated RPM from http://park-street.boston.redhat.com/test/module-ccm-devel-dev.html this morning and did rpm -Uvh --replacepkgs --replacefiles ccm-devel-2.0.0-1.noarch.rpm to pick up your fix. It seems that my Ant is a bit old. I'm getting BUILD FAILED The <property> task doesn't support the "classpathref" attribute. This is for <property classpathref="ccm.base.classpath" resource="/ccm-core/runtime.properties"/> I checked the manual and this attribute does seem to be supported http://ant.apache.org/manual/CoreTasks/property.html I have ant-1.5-5jpp installed. What version of Ant are you running?
I am reporting a different issue, but it falls under the same general description, so I'm filing it here rather than opening a new ticket. (Should be changed from from QA_READY to REOPENED.) I temporarily hacked around the Ant issue reported in my previous comment by changing the above-mentioned line like so: <property classpath="/var/ccm-devel/web/vadim/dev/conf" resource="ccm-core/runtime.properties"/> The unit tests can now progress a little further before blowing up with the following exception: java.lang.ClassNotFoundException: com.arsdigita.cms.Initializer at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:183) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:115) at com.arsdigita.util.Classes.loadClass(Classes.java:48) at com.arsdigita.util.Classes.newInstance(Classes.java:146) at com.arsdigita.runtime.Startup.<init>(Startup.java:92) at com.arsdigita.tools.junit.extensions.BaseTestSetup.setUp(BaseTestSetup.java:96) This happens because the Startup class attempts the following: $ p4 print //core-platform/dev/src/com/arsdigita/runtime/Startup.java#1 | grep -v //core | nl -ba - | head -n 95 | tail -n 15 81 final DataCollection inits = session.retrieve 82 ("com.arsdigita.runtime.Initializer"); 83 84 // XXX not doing dependency sort here yet 85 86 while (inits.next()) { 87 if (s_log.isDebugEnabled()) { 88 s_log.debug("adding: " + (String) inits.get("className")); 89 } 90 add((Initializer) Classes.newInstance 91 ((String) inits.get("className"))); 92 } 93 94 inits.close(); 95 On my system, the following initializers are registered: # select class_name from inits; class_name -------------------------------- com.arsdigita.core.Initializer com.arsdigita.cms.Initializer (2 rows) Note, however, that "com.arsdigita.cms.Initializer" is not on the classpath, when I run $ ant -Djunit.suite=CategorizationSuite.class runtests The (non-jar, non-zip) elements of the classpath are: $CCM_DEV_HOME/core/build/classes $CCM_DEV_HOME/core/build/sql $CCM_DEV_HOME/core/pdl $CCM_DEV_HOME/core/build/tests/classes $CCM_DEV_HOME/conf Missing from this is $CCM_DEV_HOME/cms/build/classes Put a little more generally, the problem is that prior to the landing of the test-packaging branch, we had a way of specifying the last initializer that must be run. At this point, the system attempts to run all the registered initializers, regardless of the fact that I want to run my unit test against core only - I don't CMS to be initialized.
The issue with the "classpathref" attribute not being supported in some versions of Ant has been fixed by Dennis. I p4 sync'ed to //tools/ccmbuild/devel/dev/...@37456 or thereabouts and rebuilt the ccm-devel RPM. The build.xml file generated from the updated build-template.xsl works fine now. The issue with "com.arsdigita.cms.Initializer" seems to have been fixed as well. Don't remember what changelist fixed that particular issue.
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future. Moving to ON_QA.
closing old CCM bugs