I found a workaround. :)
You can stuff the jars that will be packaged into Java.classpath EVEN if they
don't exist (yet).
When they DO exist, and you are checking a release or running tests, the
classpath becomes correct and it works.
It doesn't seem to have any other ill effects. Not sure why Java.classpath
needs to be set so early in the game. Is that a design flaw?
pseudocode
.....
define "something" do
...
compile stuff....
package stuff...
set up the classpath including the NONEXISTENT packaged archives ...<====
end
task "somelatertask" => :package do # the packaged archives
exist now
.....
deps.each do |dep|
Java.java.lang.Class.forName(dep.class).asSubclass(Java.java.lang.Class.forName(dep.subclass))
# <== succeeds if class exists
end
--Ed
PS Certainly better than trying to build my own classloader in Java invoked in
Ruby....
On Oct 7, 2010, at 2:51 PM, Ed Smiley wrote:
> I am seeing, depending on the context of where I am in the build state,
> different behavior of the Java object's class path.
>
> Why this matters to me:
> My build not only complies and packages Java source, but generates a large
> number of xml configuration files with classnames for dependency injection.
> I want to have the developer have the option of turning on a test that all
> referenced classes are instantiatable.
>
> Now when I access a class in any of my compilation dependencies I can get to
> the Java.classpath object and insert the values into it.
> Then any class in any of those jars can be invoked. Basically something like
> this works, when invoked at the end of each subproject:
>
> Java.classpath << all_libs # a little more complicated, but like this, and
> this works
> Java.java.lang.Class.forName(dep.class).asSubclass(Java.java.lang.Class.forName(dep.subclass))
> # subclass is Object if not specified, this too works
>
> So my dependency injection, which is distributed with the components can be
> validated against any of the classes it is compiled against. However I want
> to also distribute custom classes with the artifacts.
> However, I cannot make each subproject have a circular dependency on
> :package, which is what happens. To get the packaged components validated
> against the configuration files, I need to arrange the dependencies such that
> the check is done in a custom task that depends on :package, so that I can
> add in checks with the created artifacts. There's no problem in setting the
> Java classpath, but it is no longer honored, and classes that used to work,
> now don't.
>
> If I do the following
> puts "CLASSPATH"
> p Java.classpath
>
> Java.java.lang.System.out.println(Java.java.lang.System.getProperty("java.class.path"))
>
>
> I get
> CLASSPATH
> [["org.apache.ant:ant:jar:1.8.0", "org.apache.ant:ant-launcher:jar:1.8.0",
> "org.apache.ant:ant-trax:jar:1.8.0"],
> ["/Library/Ruby/Gems/1.8/gems/buildr-1.4.2/lib/buildr/java"],
> ["isis-toolkit/client-server.jar", "isis-toolkit/common.jar",
> "isis-toolkit/document-aserver.jar", "isis-toolkit/document-client.jar",
> "isis-toolkit/document-processor.jar", "isis-toolkit/netstore.jar",
> "isis-toolkit/search-server.jar", "isis-toolkit/server.jar",
> "isis-toolkit/software-server.jar", "isis-toolkit/transport-server.jar",
> "isis-toolkit/user-server.jar", "isis-toolkit/util.jar"]]
>
> /Users/esmiley/.m2/repository/org/apache/ant/ant/1.8.0/ant-1.8.0.jar:/Users/esmiley/.m2/repository/org/apache/ant/ant-launcher/1.8.0/ant-launcher-1.8.0.jar:/Users/esmiley/.m2/repository/org/apache/ant/ant-trax/1.8.0/ant-trax-1.8.0.jar:/Library/Ruby/Gems/1.8/gems/buildr-1.4.2/lib/buildr/java
>
> In this new context, where it appears to need to be, it appears that I can
> set the classpath until the cows come home in the Java object, but it is not
> being honored. The classes that passed the test before now throw
> NoClassDefFoundErrors.
>
>
> --Ed
