buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Smiley <>
Subject Good stuff in Java classpath
Date Fri, 08 Oct 2010 02:01:13 GMT
I found a workaround. :)

You can stuff the jars that will be packaged into Java.classpath EVEN if they don't exist

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?  


 define "something" do
    compile stuff....
    package stuff...
    set up the classpath including the NONEXISTENT packaged archives ...<====

    task "somelatertask" => :package do             # the packaged archives exist now
         deps.each do |dep| 
# <== succeeds if class exists

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
# 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
> If I do the following
>       puts "CLASSPATH"
>       p Java.classpath 
> I get
> [["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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message