buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <>
Subject Re: Odd stuff in Java classpath
Date Thu, 07 Oct 2010 22:22:04 GMT
Hi Ed,

The Java.classpath is a little finicky because it can't be changed once RJB
has been loaded, and that loading usually happens after the buildfile has
been read but before buildr starts running tasks.

For you purpose, I would suggest running an external Java process where you
can more easily control the classpath.

Here's an example,

define :foo do

  compile.with ...
  test.with ...

  task :validate do ["org.example.CheckInjection", "-file context.xml"],
      :classpath => [ compile.dependencies,, all_libs, ... ]

Project.local_task :validate

After which you can run:

buildr foo:validate

to validate if you injection context is valid.


On Thu, 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
> # 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
> 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