[gradle-user] Runtime ClassLoader Instead of Build ClassLoader
I'd like to call a Java class, but use the runtime classloader instead of the build classloader for resolving and executing the class. Is there an easy way to do this? The wider background: I'm executing org.jruby.Main#main to execute JRuby scripts. I'd like those scripts to use the runtime classloader so I don't have to keep building up the buildscript.dependencies closure. -- ~~ Robert Fischer, Smokejumper IT Consulting. Enfranchised Mind Blog http://EnfranchisedMind.com/blog Grails Expert Retainer Services http://smokejumperit.com/grails-retainer/ - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Runtime ClassLoader Instead of Build ClassLoader
I'd like to provide the dependencies specified in the dependencies closure, not by the stuff in buildscript.dependencies. ~~ Robert Fischer, Smokejumper IT Consulting. Enfranchised Mind Blog http://EnfranchisedMind.com/blog Grails Expert Retainer Services http://smokejumperit.com/grails-retainer/ Adam Murdoch wrote: Robert Fischer wrote: I'd like to call a Java class, but use the runtime classloader instead of the build classloader for resolving and executing the class. Is there an easy way to do this? Depends what do you mean by the 'runtime classloader'. What stuff do you need to be visible (or not visible)? - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Exec a Shell Command?
You should probably use an AtomicBoolean for running.
Is there an up-to-date description of how to build a plugin? If so,
I'll make an exec plugin to do this kind of stuff. Assuming it's okay
I build off of the provided code.
~~ Robert.
Jim Moore wrote:
FWIW, I wrote a method that gives me better control than I saw elsewhere:
void runCmd(String cmd, File baseDir) {
println cmd
def sout = new StringBuffer()
def serr = new StringBuffer()
def outProc = Runtime.runtime.exec(cmd, [] as String[], baseDir)
def running = true
def bufferPrinter = {buffer -
def lastIndex = 0
while(running) {
def length = buffer.length()
if (length lastIndex) {
print buffer.subSequence(lastIndex, length)
lastIndex = length
}
Thread.sleep(100)
}
}
Thread.start bufferPrinter.curry(sout)
Thread.start bufferPrinter.curry(serr)
outProc.consumeProcessOutput(sout, serr)
try {
outProc.waitFor()
}
finally {
running = false
}
if (outProc.exitValue()) {
println Error code: ${outProc.exitValue()}
System.exit(1)
}
}
On Wed, Nov 18, 2009 at 9:04 AM, Robert Fischer
robert.fisc...@smokejumperit.com
mailto:robert.fisc...@smokejumperit.com wrote:
How can I exec a shell command and see the output? Normally, the
Ant exec task works fine for this, but when I invoke 'exec' in
Gradle, I don't get any output to the screen. Is there some
equivalent to Gant's execute tool?
~~ Robert.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Exec a Shell Command?
Found the plugin stuff in the user guide. Amazing how much stuff is in
there.
Where did you find the documentation for consumeProcessOutput?
~~ Robert.
Robert Fischer wrote:
You should probably use an AtomicBoolean for running.
Is there an up-to-date description of how to build a plugin? If so,
I'll make an exec plugin to do this kind of stuff. Assuming it's
okay I build off of the provided code.
~~ Robert.
Jim Moore wrote:
FWIW, I wrote a method that gives me better control than I saw
elsewhere:
void runCmd(String cmd, File baseDir) {
println cmd
def sout = new StringBuffer()
def serr = new StringBuffer()
def outProc = Runtime.runtime.exec(cmd, [] as String[], baseDir)
def running = true
def bufferPrinter = {buffer -
def lastIndex = 0
while(running) {
def length = buffer.length()
if (length lastIndex) {
print buffer.subSequence(lastIndex, length)
lastIndex = length
}
Thread.sleep(100)
}
}
Thread.start bufferPrinter.curry(sout)
Thread.start bufferPrinter.curry(serr)
outProc.consumeProcessOutput(sout, serr)
try {
outProc.waitFor()
}
finally {
running = false
}
if (outProc.exitValue()) {
println Error code: ${outProc.exitValue()}
System.exit(1)
}
}
On Wed, Nov 18, 2009 at 9:04 AM, Robert Fischer
robert.fisc...@smokejumperit.com
mailto:robert.fisc...@smokejumperit.com wrote:
How can I exec a shell command and see the output? Normally, the
Ant exec task works fine for this, but when I invoke 'exec' in
Gradle, I don't get any output to the screen. Is there some
equivalent to Gant's execute tool?
~~ Robert.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[gradle-user] More Source Set Issues
I have three source sets: main, javacc, ast. They need to be compiled in that order, and each needs to have access to the classes generated by the previous ones. Specifying task dependencies doesn't get the classes added to the classpath. If I try to add the files to configurations.compile (like in Example 28.7. Generated file dependencies of the 0.8 user manual), I get circular task dependencies. So how should I go about specifying these dependencies? I'd really rather not break things out into multiple projects, because they're simply not that distinct (they share the same dependencies, will end up packaged into the same JAR, etc., etc.). I just need a particular compilation order. (BTW, the reason I need the particular compilation order is because the AST is written in Scala and the javacc is written in Java. The javacc depends on the AST, which means compileJava depends on compileScala, which is a circular dependency. I can't seem to remove compileJava from compileScala's dependency list: compileScala.dependsOn().remove(compileJava) doesn't seem to do anything. If I could break the bad assumption that compileScala depends on compileJava, I wouldn't need the distinct source sets and could move on with my life.) ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Source Sets
The question is: How does one specify additional source sets than the
main and test source set?
My understanding was that having a ./src/sourceSetName/java folder was
sufficient to have a source set named sourceSet. In practice, I've
needed a sourceSet closure and duplicate sourceSetName call within
that closure. I'm trying to decide if the practice is demonstratingt a
bug (sourceSetName should be derived, but it isn't), or if it's a
failure of my understanding (the duplicate sourceSetName is necessary,
and I just missed something in the documentation which said as much).
~~ Robert.
Steve Ebersole wrote:
On Thu, 2009-11-19 at 09:09 -0500, Robert Fischer wrote:
I've added this directory to my project:
./src/javacc/java
Inside there are a bunch of Java files in their package directories.
However, when I execute this line in build.gradle:
sourceSets.each { println Source Set: $it }
I get this result:
Source Set: source set main
Source Set: source set test
Adding this line to build.gradle:
sourceSets {
javacc
}
Solves the problem, but I thought sourceSets were supposed to be
generated by configuration. Was I wrong? If not, should I JIRA this?
Not sure what you mean by generated by configuration. Certain plugins
understand certain conventions:
http://www.gradle.org/0.8/docs/userguide/userguide_single.html#N112C9
The Java plugin defines two standard source sets, called main and test.
The main source set contains your production source code, which is
compiled and assembled into a JAR file. The test source set contains
your unit test source code, which is compiled and executed using JUnit
or TestNG.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Source Sets
Yeah, looks like I'm just messed up. I thought that while there were
predefined sourceSets, there might also be implicitly derived source sets.
Actually, that wouldn't be too hard to implement as a meta-plugin. Hrm.
~~ Robert.
Paul Speed wrote:
Yeah, pretty sure that understanding is incorrect.
The sourceSets that are predefined are setup by the plugins. If you
specify the Java plugin then you get certain sourceSets. As you've
discovered you can define your own.
My own familiarity comes because I nearly completely reset where the
defaults end up pointing because my project is not in src/main/java
relative to the project directory.
-Paul
Robert Fischer wrote:
I didn't want to see the files. The point is that if I don't explicitly
specify javacc in the sourceSets closure, there is no javacc source
set in my project. This is true despite the existence of
./src/javacc/java, which I understood to specify a javacc source set
conventionally. Is that understanding wrong?
~~ Robert.
Paul Speed wrote:
Robert Fischer wrote:
I've added this directory to my project:
./src/javacc/java
Inside there are a bunch of Java files in their package directories.
However, when I execute this line in build.gradle:
sourceSets.each { println Source Set: $it }
I think if you want to see the files then you need to call:
sourceSets.each { println Source Set: $it.files }
-Paul
I get this result:
Source Set: source set main
Source Set: source set test
Adding this line to build.gradle:
sourceSets {
javacc
}
Solves the problem, but I thought sourceSets were supposed to be
generated by configuration. Was I wrong? If not, should I JIRA this?
~~ Robert.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Exec a Shell Command?
Yeah, that's what I ended up doing: it'll be out on GitHub presently.
~~ Robert.
Adam Murdoch wrote:
Robert Fischer wrote:
How can I exec a shell command and see the output? Normally, the Ant
exec task works fine for this, but when I invoke 'exec' in Gradle,
I don't get any output to the screen.
The Ant exec task logs the output at info level, so its only visible
when you run Gradle with the -i command-line option. There's a JIRA
issue to improve this behaviour:
http://jira.codehaus.org/browse/GRADLE-376
You can always use the execllent stuff that Groovy provides to execute
commands. Here's an example which executes a class from the current
project:
task exec(dependsOn: sourceSets.main.runtimeClasspath) { task -
Process proc = [java, -cp,
task.project.sourceSets.main.runtimeClasspath.asPath,
my.MainClass].execute()
proc.consumeProcessErrorStream(System.err)
proc.consumeProcessOutputStream(System.out)
if (proc.waitFor() != 0) {
throw new RuntimeException('exec failed')
}
}
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] More Source Set Issues
Steve Ebersole wrote: On Thu, 2009-11-19 at 17:46 -0500, Robert Fischer wrote: Ahh. If I did anything particularly interesting with javacc, I would make it a plugin. At this point in the build, though, it's just a collection of Java source files. I do have that shell-exec command which is a plugin and which I will be sharing. BTW, this is why I name things foo, bar, and baz all the time. People read into names and put assumptions on what's going on. I'd argue that in convention-based environments names are extremely important ;) In a build, you betcha if I see a source directory named antlr but with no antlr grammars I'd be a bit perplexed. Granted: I'm talking about writing up examples and asking for help from mailing lists. If you don't obscure the variable names, people end up thinking you're questions about javacc grammars and not about source set inter-dependencies. ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] More Source Set Issues
compileScala.dependsOn.remove('compileJava')
Tried that -- didn't seem to do anything.
~~ Robert.
Adam Murdoch wrote:
Robert Fischer wrote:
I have three source sets: main, javacc, ast. They need to be
compiled in that order, and each needs to have access to the classes
generated by the previous ones. Specifying task dependencies doesn't
get the classes added to the classpath. If I try to add the files to
configurations.compile (like in Example 28.7. Generated file
dependencies of the 0.8 user manual), I get circular task dependencies.
So how should I go about specifying these dependencies? I'd really
rather not break things out into multiple projects, because they're
simply not that distinct (they share the same dependencies, will end
up packaged into the same JAR, etc., etc.). I just need a particular
compilation order.
(BTW, the reason I need the particular compilation order is because
the AST is written in Scala and the javacc is written in Java. The
javacc depends on the AST, which means compileJava depends on
compileScala, which is a circular dependency. I can't seem to remove
compileJava from compileScala's dependency list:
compileScala.dependsOn().remove(compileJava) doesn't seem to do
anything.
This should do what you want:
compileScala.dependsOn.remove('compileJava')
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] [ANN] GitHub: RobertFischer/gradle-plugins
It'd be nice to define a convention, so we could say something like
packages=com.smokejumperit.gradle.plugins, and then when
usePlugin('fooBar') hits, after all other resolutions fail, a resolution
against com.smokejumperit.gradle.plugins.FooBarPlugin would be
attempted. Would make releasing plugins a lot easier.
~~ Robert.
Helmut Denk wrote:
hi robert,
*1* = plugin-build
my build.gradle for the plugin-build:
(you may have to adjust the dependencys if
you use another version of gradle)
usePlugin('groovy')
sourceCompatibility = 1.5
targetCompatibility = 1.5
group = 'com.myCompany.gradle'
version = 'x.y'
manifest.mainAttributes(provider: 'myCompany')
repositories {
flatDir(dirs: file('lib'))
}
dependencies {
groovy(':groovy-all:1.6.4')
compile(':slf4j-api:1.5.8')
compile(':gradle-core:0.9-SNAPSHOT')
compile(':ivy:2.1.0-rc2')
testCompile(':logback-classic:0.9.17')
testCompile(':logback-core:0.9.17')
testCompile(':junit:4.7')
}
*2* = plugin.properties
in $GRADLE_HOME/plugin.properties i add the line:
custom-plugin=com.mycompany.gradle.MyCustomPlugin
there should be a note about plugin.properties in the
reference-guide.
gruesse
Robert Fischer wrote:
Do you have some documentation on that? Like where the
plugins.properties file is or what line you add to it? Or what the JAR
consists of?
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[gradle-user] Upload via SCP
The user guide (Table 29.1) says that I need 'org.apache.maven.wagon:wagon-scp:1.0-beta-2' for scp upload. But there is no such beast, at least not in the maven central repo. Is there a different repo I should use, or am I missing something? ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Upload via SCP
Okay, I changed to using wagon-ssh (the docs should be fixed), and now I'm getting this error when I attempt to upload: Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying artifact: Unsupported Protocol: 'scp': Cannot find wagon which supports the requested protocol: scp at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:94) at org.apache.maven.artifact.ant.DeployTask.doExecute(DeployTask.java:117) ... 28 common frames omitted Caused by: org.apache.maven.wagon.TransferFailedException: Unsupported Protocol: 'scp': Cannot find wagon which supports the requested protocol: scp at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:191) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80) ... 29 common frames omitted Caused by: org.apache.maven.wagon.UnsupportedProtocolException: Cannot find wagon which supports the requested protocol: scp at org.apache.maven.artifact.manager.DefaultWagonManager.getWagon(DefaultWagonManager.java:135) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:185) ... 31 common frames omitted Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagonscp. Upgrading to the most recent beta (1.0-beta-6) doesn't help. Is anyone actually successfully uploading using scp? Can I see the configuration file? My build file is at: http://github.com/RobertFischer/gradle-plugins/blob/master/build.gradle ~~ Robert. Robert Fischer wrote: The user guide (Table 29.1) says that I need 'org.apache.maven.wagon:wagon-scp:1.0-beta-2' for scp upload. But there is no such beast, at least not in the maven central repo. Is there a different repo I should use, or am I missing something? ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] [ANN] SmokejumperIT Gradle-Plugins 0.1
I'm starting to release my plugins, and I've figured out a reasonably simple way for people to use them. See my README here: http://github.com/RobertFischer/gradle-plugins/blob/master/README.md Currently, I've released two plugins: ClassLoaders and Exec. They allow you to gain access to a classloader based on a configuration and execute shell scripts (respectively). A RunJRuby and a Cucumber plugin are coming presently. The goal will be to eat Cuke4Duke's lunch: I've been underwhelmed with Cuke4Duke's ease-of-use. Also thinking about a Conventional plugin, which would add source sets based on the existence of directories, use the ~/.m2 repo, and maybe do a few other standard stunts. And, finally, I'm considering two ease-of-use plugins: com.smokejumperit.gradle.AllPlugins (which simply pulls in all the plugins in the com.smokejumperit.gradle suite) and com.smokejumperit.gradle.FavoritePlugins (which pulls in all my favorite plugins with some pre-configuration). Just FYI, Gradle is featuring prominently in my book on Polyglot Programming. :) ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] [ANN] SmokejumperIT Gradle-Plugins 0.1
Sure: will do. I'm working on getting my Cuke plugin running right now, but as soon as that's functioning, I'll update the Cookbook with more on the ClassLoader, Env, RunJRuby, and Cuke plugins. ~~ Robert. Tomek Kaczanowski wrote: Hi Robert, thanks for the plugins ! Could you please check what I just added to Cookbook (http://docs.codehaus.org/display/GRADLE/Cookbook#Cookbook-plugins) and fill the missing gaps (short info on ClassLoader plugin is required). Also, as you plan to provide new plugins it would be very good for the gradle community if you could add some information on each to the cookbook (apart from informing us on the mailing list). -- Tomek 2009/11/26 Robert Fischer robert.fisc...@smokejumperit.com: I'm starting to release my plugins, and I've figured out a reasonably simple way for people to use them. See my README here: http://github.com/RobertFischer/gradle-plugins/blob/master/README.md Currently, I've released two plugins: ClassLoaders and Exec. They allow you to gain access to a classloader based on a configuration and execute shell scripts (respectively). A RunJRuby and a Cucumber plugin are coming presently. The goal will be to eat Cuke4Duke's lunch: I've been underwhelmed with Cuke4Duke's ease-of-use. Also thinking about a Conventional plugin, which would add source sets based on the existence of directories, use the ~/.m2 repo, and maybe do a few other standard stunts. And, finally, I'm considering two ease-of-use plugins: com.smokejumperit.gradle.AllPlugins (which simply pulls in all the plugins in the com.smokejumperit.gradle suite) and com.smokejumperit.gradle.FavoritePlugins (which pulls in all my favorite plugins with some pre-configuration). Just FYI, Gradle is featuring prominently in my book on Polyglot Programming. :) ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] Adding clean directories (Q 2 of 2)
Is there a way to add directories to the list of those that should be cleaned? If not, what's the easiest way to specify additional actions when clean is run? ~~ Robert.
[gradle-user] Sub-Project Not Archiving Non-Main Source Sets?
In one of my sub-projects, I have three sourceSets: a, b, main. When I execute :subproject:jar, however, I only get the main bit archived into the jar: neither the a or b sourceSets make it in. I've got *.class files in ./build/classes/a and ./build/classes/b - they just don't make it. Any idea why that might be, or how I might work around it? ~~ Robert.
Re: [gradle-user] Re: Sub-Project Not Archiving Non-Main Source Sets?
IIRC, that resulted in only sourceSets.b.classesDir getting into the jar.
But I'll double-check.
~~ Robert.
On 19 August 2010 13:37, TheKaptain kelly...@gmail.com wrote:
You should be able to add to the jar definition as a workaround:
jar {
from sourceSets.a.classesDir
from sourceSets.b.classesDir
}
Haven't tried it in action, but that should work to incorporate your other
source sets into the jar.
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Sub-Project-Not-Archiving-Non-Main-Source-Sets-tp2639915p2641294.html
Sent from the gradle-user mailing list archive at Nabble.com.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[gradle-user] Run After?
Is there a way to tell Gradle, If task A is being executed, make sure to run task B after task A? I specifically don't want to make Task A a dependency on B (it shouldn't run every time), but I'd like it to run them together now and again, and when that happens they need to run in a certain order. ~~ Robert.
Re: [gradle-user] Run After?
I suppose that'll work for the time being. As long as nobody expects
gradle a b to work.
~~ Robert.
On 20 August 2010 16:00, Jim Moore moore@gmail.com wrote:
Depends on your need, but it sounds like you simply need
task c(dependsOn: [a, b]) {}
On Fri, Aug 20, 2010 at 3:51 PM, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
Is there a way to tell Gradle, If task A is being executed, make sure to
run task B after task A? I specifically don't want to make Task A a
dependency on B (it shouldn't run every time), but I'd like it to run them
together now and again, and when that happens they need to run in a certain
order.
~~ Robert.
-Jim Moore
Re: [gradle-user] Run After?
But then if I do gradle a, I'll always get b run, too, right?
~~ Robert.
On 20 August 2010 16:37, Matthias Bohlen infom...@mbohlen.de wrote:
How about a.doLast(b) ? Does that work?
Am 20.08.2010 um 22:10 schrieb Robert Fischer:
I suppose that'll work for the time being. As long as nobody expects
gradle a b to work.
~~ Robert.
On 20 August 2010 16:00, Jim Moore moore@gmail.com wrote:
Depends on your need, but it sounds like you simply need
task c(dependsOn: [a, b]) {}
On Fri, Aug 20, 2010 at 3:51 PM, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
Is there a way to tell Gradle, If task A is being executed, make sure to
run task B after task A? I specifically don't want to make Task A a
dependency on B (it shouldn't run every time), but I'd like it to run them
together now and again, and when that happens they need to run in a certain
order.
~~ Robert.
-Jim Moore
Re: [gradle-user] Confused on defining tasks.
Off the top of my head, I think the first case is supposed to be:
task cleanAll(type:Delete) {
}
~~ Robert.
On 20 August 2010 20:29, Eric Berry elbe...@gmail.com wrote:
I was defining a 'cleanAll' task and I ran into a little confusion with the
Task definition syntax described here:
http://www.gradle.org/0.9-rc-1/docs/userguide/more_about_tasks.html
If I define my task like this:
[code]
task(cleanAll, type: Delete) {
delete(some dir)
}
[/code]
It doesn't work. However defining it as below does:
[code]
task(cleanAll, type:Delete) {
delete(some dir)
}
[/code]
I thought these two formats were interchangeable and resulted in the same
thing? When should one be used vs. the other?
I'm using Gradle 0.9-rc-1
Thanks,
Eric
--
Learn from the past. Live in the present. Plan for the future.
Blog: http://www.townsfolkdesigns.com/blogs/elberry
jEdit http://www.jedit.org - Programmer's Text Editor
Bazaar http://bazaar.canonical.com - Version Control for Humans
Re: [gradle-user] osgi manifest question (osgi gradle plugin)
There's a bunch of sane defaults in BND. Based on that error, it sounds like your OSGi framework isn't exposing all the runtime packages it should be. You can add packages for the framework to provide by adding them to the org.osgi.framework.system.packages.extra system property. What are you asking for in the jar/manifest version of your build? ~~ Robert. On 20 August 2010 21:49, phil swenson phil.swen...@gmail.com wrote: I'm using the osgi plugin to create a jar equivalent to what our production build creates. Using the osgi plugin ends up with a manifest that has much more stuff in it that I expect. I assume the BND tool resolves a bunch of stuff that we don't know about as our production build manifest is handcoded? This make sense? Anyway, when I try to install the OSGi bundle I get this: osgi start 148 org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: I mport-Package: com.sun.jndi.ldap; version=0.0.0 at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle. java:1313) at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(Ab any thoughts on where I can find the com.sun.jndi.ldap bundle (it's not in our repo) and why the manifest is much bigger than what I ask for in the jar/manifest section of the build? thanks phil - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Run After?
Requirements:
1) If the user asks for both a and b to be run, I'd like to run b
before a -- due to Gradle's internal ordering, a is coming before b,
and that's causing issues in the build.
2) I want to be able to run b without a executing.
3) I want to be able to run a without b executing.
Suggestions so far are:
A) Don't ever ask for both a and b to be run simultaneously, but instead
only ever ask for task c to run, which will run b then a. This is an
okay solution as long as I'm explicit in wanting to call a and b. If
they are implicitly called, I'll have to hack around the ordering at that
point.
B) Attach a to the end of b. Which violates requirement #2.
So is there a better solution?
The explicit use case is: as a part of my pull everything together phase,
I want to run a clean on everything, then a jar on everything. So I have
dependencies on every subproject's clean and jar. The issue is that I'm
getting the following ordering:
:runtime:jar
:lang:clean
:lang:jar
:runtime:clean
:makeDistribution
The result being that the jar for runtime is blown away before
makeDistribution can get to it.
I'd really rather avoid having to call clean every time I call jar, and
certainly don't want to have to call jar every time I call clean.
~~ Robert.
On 20 August 2010 20:36, Jim Moore moore@gmail.com wrote:
Yes.
gradle c would work. gradle a b would work. Adding b at the end of
a would work. And I can think of half a dozen other ways of solving the
problem as stated with slightly different implications. Without an actual
use-case, all that can be talked about is vague generalities. If none of
the current suggestions makes it clear Oh, I can adapt it in *this* way to
my problem then a clearer statement of the problem is needed...
On Fri, Aug 20, 2010 at 4:40 PM, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
But then if I do gradle a, I'll always get b run, too, right?
~~ Robert.
On 20 August 2010 16:37, Matthias Bohlen infom...@mbohlen.de wrote:
How about a.doLast(b) ? Does that work?
Am 20.08.2010 um 22:10 schrieb Robert Fischer:
I suppose that'll work for the time being. As long as nobody expects
gradle a b to work.
~~ Robert.
On 20 August 2010 16:00, Jim Moore moore@gmail.com wrote:
Depends on your need, but it sounds like you simply need
task c(dependsOn: [a, b]) {}
On Fri, Aug 20, 2010 at 3:51 PM, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
Is there a way to tell Gradle, If task A is being executed, make sure
to run task B after task A? I specifically don't want to make Task A a
dependency on B (it shouldn't run every time), but I'd like it to run them
together now and again, and when that happens they need to run in a
certain
order.
~~ Robert.
-Jim Moore
-Jim Moore
Re: [gradle-user] Run After?
That variant on A works. Thanks! I'm looking forward to the explicit
ordering, since I'm now extremely wary about any time the clean task and
any other task might be in the same Gradle run.
~~ Robert.
On 21 August 2010 17:40, Adam Murdoch a...@gradle.biz wrote:
On 22/08/10 2:05 AM, Robert Fischer wrote:
Requirements:
1) If the user asks for both a and b to be run, I'd like to run b
before a -- due to Gradle's internal ordering, a is coming before b,
and that's causing issues in the build.
2) I want to be able to run b without a executing.
3) I want to be able to run a without b executing.
Suggestions so far are:
A) Don't ever ask for both a and b to be run simultaneously, but
instead only ever ask for task c to run, which will run b then a.
This is an okay solution as long as I'm explicit in wanting to call a and
b. If they are implicitly called, I'll have to hack around the ordering
at that point.
B) Attach a to the end of b. Which violates requirement #2.
So is there a better solution?
The explicit use case is: as a part of my pull everything together
phase, I want to run a clean on everything, then a jar on everything. So I
have dependencies on every subproject's clean and jar.
You can usually trick Gradle into running things in the correct order. In
your case, you might separate the dependencies onto separate tasks. For
example, in the root project:
task cleanAll {
dependsOn subprojects*.clean
}
task jarAll {
dependsOn subprojects*.jar
}
task buildAll {
dependsOn cleanAll, jarAll
}
Running the 'buildAll' task will run all the dependencies for 'cleanAll'
and then all the dependencies for 'jarAll'.
At some point before Gradle 1.0 we will provide some way to state that the
a project's 'clean' task must run before any of the other tasks of the
project. There's a few options for how this might look. The Java plugin will
specify this out-of-the-box, so things should just work.
The issue is that I'm getting the following ordering:
:runtime:jar
:lang:clean
:lang:jar
:runtime:clean
:makeDistribution
The result being that the jar for runtime is blown away before
makeDistribution can get to it.
I'd really rather avoid having to call clean every time I call jar,
and certainly don't want to have to call jar every time I call clean.
~~ Robert.
On 20 August 2010 20:36, Jim Moore moore@gmail.com wrote:
Yes.
gradle c would work. gradle a b would work. Adding b at the end
of a would work. And I can think of half a dozen other ways of solving the
problem as stated with slightly different implications. Without an actual
use-case, all that can be talked about is vague generalities. If none of
the current suggestions makes it clear Oh, I can adapt it in *this* way to
my problem then a clearer statement of the problem is needed...
On Fri, Aug 20, 2010 at 4:40 PM, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
But then if I do gradle a, I'll always get b run, too, right?
~~ Robert.
On 20 August 2010 16:37, Matthias Bohlen infom...@mbohlen.de wrote:
How about a.doLast(b) ? Does that work?
Am 20.08.2010 um 22:10 schrieb Robert Fischer:
I suppose that'll work for the time being. As long as nobody expects
gradle a b to work.
~~ Robert.
On 20 August 2010 16:00, Jim Moore moore@gmail.com wrote:
Depends on your need, but it sounds like you simply need
task c(dependsOn: [a, b]) {}
On Fri, Aug 20, 2010 at 3:51 PM, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
Is there a way to tell Gradle, If task A is being executed, make sure
to run task B after task A? I specifically don't want to make Task A a
dependency on B (it shouldn't run every time), but I'd like it to run
them
together now and again, and when that happens they need to run in a
certain
order.
~~ Robert.
-Jim Moore
-Jim Moore
--
Adam Murdoch
Gradle Developerhttp://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consultinghttp://www.gradle.biz
Re: [gradle-user] Re: Eclipse plugin why is assemble or jar required in a multiproject setup.
I don't know anything about the Eclipse plugin, but here's a shot in the dark. If you have projects with dependencies on other projects, it's the jars resulting from those other projects that are added to the classpath. So that will cause the jar to be generated, even if the task at hand doesn't explicitly state it is necessary. ~~ Robert. On 27 August 2010 09:01, Jason Hatton jashat...@gmail.com wrote: I was hoping to get a reply on this and haven't yet. I was wondering if maybe I haven't described the problem well enough. Anybody out there? :) Thanks, Jas On Mon, Aug 23, 2010 at 1:09 PM, Jason Hatton jashat...@gmail.com wrote: I was wondering if there was it is safe to turn off the jar or assemble task requirement when generating the Eclipse files? Is this even a requirement of the plugin, have I accidentally made this be a requirement? It doesn't seem reasonable for just generating Eclipse project files that the assemble task is needed. Our project is running 0.8 and is a multi-project Eclipse WTP setup. Thanks, Jas - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] osgiManifest does not work outside of default jar task
Does your problem go away if you explicitly depend on jar? Also,
watch the execution of the tasks - is a clean being executed between
jar and onejarJar?
~~ Robert.
On 27 August 2010 10:46, Lars Heuer he...@semagia.com wrote:
Hi all,
During my build I create an additional jar which contains all
dependencies (they are added via jarjar).
That works so far, but I cannot use the osgiManifest in my task:
task onejarJar(type: Jar, dependsOn: repack ) {
baseName = jar.baseName + '-onejar'
from $buildDir/onejar
manifest = osgiManifest {
from(jar.manifest)
instruction 'Bundle-Activator', 'mypack.Activator'
instruction 'Import-Package', '!mypack.*, *'
}
}
Leads to:
Could not copy MANIFEST.MF to 'build\tmp\onejarJar\MANIFEST.MF'.
(Stacktrace below)
If I use
manifest = project.manifest {
from(jar.manifest)
}
everything is fine.
Thanks in advance and best regards,
Lars
Stacktrace:
* Exception is:
org.gradle.api.GradleException: Could not copy MANIFEST.MF to
'build\tmp\onejarJar\MANIFEST.MF'.
at
org.gradle.api.internal.file.AbstractFileTreeElement.copyTo(AbstractFileTreeEle
ment.java:70)
at
org.gradle.api.internal.file.MapFileTree$FileVisitDetailsImpl.getFile(MapFileTr
ee.java:125)
at
org.gradle.api.internal.file.AbstractFileTree$1.visitFile(AbstractFileTree.java
:38)
at
org.gradle.api.internal.file.AbstractFileTree$FilteredFileTree$1.visitFile(Abst
ractFileTree.java:135)
at
org.gradle.api.internal.file.MapFileTree$Visit.visit(MapFileTree.java:95)
at org.gradle.api.internal.file.MapFileTree.visit(MapFileTree.java:60)
at
org.gradle.api.internal.file.AbstractFileTree$FilteredFileTree.visit(AbstractFi
leTree.java:126)
at
org.gradle.api.internal.file.AbstractFileTree.getFiles(AbstractFileTree.java:36
)
at
org.gradle.api.internal.file.CompositeFileCollection.getFiles(CompositeFileColl
ection.java:37)
at
org.gradle.api.internal.file.CompositeFileCollection.getFiles(CompositeFileColl
ection.java:37)
at
org.gradle.api.internal.file.CompositeFileCollection.getFiles(CompositeFileColl
ection.java:37)
at
org.gradle.api.internal.file.AbstractFileCollection.iterator(AbstractFileCollec
tion.java:60)
at
org.gradle.api.internal.changedetection.DefaultFileSnapshotter.snapshot(Default
FileSnapshotter.java:42)
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$Hist
oricExecution.calcCurrentState(DefaultTaskArtifactStateRepository.java:140)
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$Hist
oricExecution.isUpToDate(DefaultTaskArtifactStateRepository.java:150)
at
org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository$Task
ArtifactStateImpl.isUpToDate(DefaultTaskArtifactStateRepository.java:289)
at
org.gradle.api.internal.changedetection.ShortCircuitTaskArtifactStateRepository
$1.isUpToDate(ShortCircuitTaskArtifactStateRepository.java:35)
at
org.gradle.api.internal.project.taskfactory.ExecutionShortCircuitTaskExecuter.e
xecute(ExecutionShortCircuitTaskExecuter.java:40)
at
org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:
57)
at
org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:35
)
at
org.gradle.api.internal.tasks.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMo
stOnceTaskExecuter.java:32)
at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:231)
at
org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecu
ter.java:167)
at
org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecute
r.java:160)
at
org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.
java:78)
at
org.gradle.execution.TaskNameResolvingBuildExecuter.execute(TaskNameResolvingBu
ildExecuter.java:161)
at
org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.ja
va:54)
at
org.gradle.execution.DelegatingBuildExecuter.execute(DelegatingBuildExecuter.ja
va:54)
at
org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLaun
cher.java:153)
at
org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.j
ava:107)
at
org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:
75)
at org.gradle.launcher.Main.execute(Main.java:93)
at org.gradle.launcher.Main.main(Main.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja
va:25)
at
Re: [gradle-user] gradle performance/scalability with lots of subprojects
From my personal experience, I think that it will get linearly (not exponentially) worse. But yes, this is an issue in Gradle. ~~ Robert. On 6 September 2010 08:28, Magnus Rundberget mrundber...@hotmail.comwrote: Hi, We've chosen gradle for our new build system and we've started the journey from maven 1 (!) to gradle. We have a very granular structure at the moment, with about 80-90 leaf projects producing output artifacts (and obviously lots of interdependencies going on + lots of 3rd party dependencies). In the short term I don't think restructuring our project structure and associated directory structure is an option. In the longer term it will be consolidated. I've ported about 40 of the simpler projects to one large gradle multiproject build. However there is starting to be a fairly substantial overhead in initialization before actually doing anything in terms of building. Doing gradle -t on a subprojsct now takes around 10,5 seconds, same for gradle clean. I've tried the same on the gradle branch (Im obviously aware its work in progress) using a gradle daemon. gradle -t on a subproject here takes about 6,5 seconds (after running it 2 times first:- Little more background; - I'm currently using a locally installed nexus repository for all my third party dependencies - I'm running cygwin on windows xp - Using gradle 0.9 rc1 From running gradle -t -i, I've made the following observations from the log; - Evaluate root project uses about 2 seconds - Summing up resolution report resolve is almost 4 seconds (typically something like resolution report :: resolve 266ms :: artifacts dl 0ms) The questions; 1) Should I assume that the overhead will get exponentially worse if adding the remaining 40-50 subprojects ? 2) Anything I could do to reduce the overhead whilst still getting the benefits of incremental builds (ie without having to resort to splitting into many more multiprojects?) 3) When can I hope for a working version of 0.9.1 with gradle daemon working on windows ? :-) Any pointers would be appreciated. cheers Magnus
[gradle-user] [ANN] JavaCC added to SJIT Gradle Plugins
The 0.6.2 release of my Gradle Plugins includes support for JavaCC and JJTree. More information in the README: http://github.com/RobertFischer/gradle-plugins/blob/master/README.md ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] OSGI plugin questions
If you already have a Manifest file generated, you're going to have to configure the jar task's manifest file given the existing one. I'm not entirely sure about the best way to do that. What's your purpose in including the Apache-Commons JAR file within your generated JAR? You can, of course, add the JAR file itself into your JAR by adding the JAR into the resources source set, but unless I'm mistaken, the classloader won't know how to load classes from that internal JAR. The other option is to create a fat jar by merging the other jar and your generated jar. That can cause problems with licensing, if you're not careful. ~~ Robert. On 8 October 2010 15:33, Alessandro Novarini a.novar...@sourcesense.comwrote: Hi all, Reading both gradle and bnd documentation didn't help me to find answers to the following questions, I hope you can turn the light on and make me see the truth on the OSGI plugin: Instructing properly the plugin The gradle documentation says: The classes in the classes dir are analyzed regarding there package dependencies and the packages they expose. Based on this the Import-Package and the Export-Package values of the OSGi Manifest are calculated. I can't understand what I have to do in this situation, because neither Import-Package nor Export-Package instructions are included in the generated manifest file. So, how does the plugin know which are the packages to be imported and which are the ones to export? Private Package instruction In the example 26.2 of the gradle documentation the instruction 'Private-Package has a list of packages explicitly written. In my example I want to make private the package org.apache.commons.*, so that in the manifest file I'll see org.apache.commons.beanutils, org.apache.commons.beanutils.converters etc. etc. The wildcard * doesn't expand the package list, all I see in the manifest is the string org.apache.commons.*. Is there a way to achieve this goal? Including dependencies Continuing with the example above, is there a way to include the jar of apache-commons in my jar using some feature of the plugin? Or should I add in some way scripting my build? All these questions came out because I already have a manifest file of this project generated by the maven plugin (that uses bnd as well), and I would like to reproduce the exact output using gradle, but I'm far from the expected. Thank you in advance Ale - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] OSGI plugin questions
The reason the jar-in-jar thing works is because it's specified using
Bundle-ClassPath: that works just for the JAR being run as an OSGi bundle,
and won't help you if you execute the JAR directly or from outside of OSGi.
I'd suggest adding the dependencies from the configuration into the jar
task's from properties, although that might you get you into
resolution-time issues.
What is failing to happen with that configuration? It looks like it'd work
for me.
~~ Robert.
On 11 October 2010 11:34, Alessandro Novarini a.novar...@sourcesense.comwrote:
Thank you for your reply.
I'll try to explain better my purpose here, my fault in the previous
mail, sorry:
I have a java project built using maven; this project is an osgi
bundle, and it's built using maven-bundle-plugin, which in turn uses
bnd like osgi plugin for gradle.
What I would like to do is to create a package with gradle that's the
exact copy of the one generated using maven.
The manifest created by maven is the following:
Manifest-Version: 1.0
Export-Package:
com.acme.prj;uses:=org.w3c.dom.ls
,javax.xml.parsers,org.w3c.dom,org.w3c.dom.bootstrap;version=0.0.1
Private-Package:
org.apache.commons.beanutils,org.apache.commons.beanutils.converters,org.apache.commons.beanutils.expression,org.apache.commons.beanutils.locale,org.apache.commons.beanutils.locale.converters,org.apache.commons.collections,org.apache.commons.digester,org.apache.commons.digester.parser,org.apache.commons.digester.plugins,org.apache.commons.digester.plugins.strategies,org.apache.commons.digester.substitution,org.apache.commons.digester.xmlrules,org.apache.commons.logging,org.apache.commons.logging.impl
Ignore-Package: org.apache.log,org.apache.avalon.framework.logger
Bundle-ClassPath:
.,commons-beanutils-1.8.0.jar,commons-digester-2.0.jar,commons-logging-1.1.1.jar
Built-By: me
Tool: Bnd-0.0.255
Bundle-Name: acme - useless project
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.6.0_20
Bundle-Version: 0.0.1
Bnd-LastModified: 1286810196596
Embed-Transitive: true
Bundle-ManifestVersion: 2
Embed-Dependency: commons-*;scope=compile|runtime
Import-Package:
com.acme.prj;version=0.0.1,javax.servlet,javax.xml.parsers,javax.xml.validation,org.apache.commons.collections.comparators,org.apache.commons.collections.keyvalue,org.apache.commons.collections.list,org.apache.commons.collections.set,org.apache.log4j,org.w3c.dom,org.w3c.dom.bootstrap,
org.w3c.dom.ls,org.xml.sax,org.xml.sax.helpers
Bundle-SymbolicName: com.acme.prj
The configuration in the pom.xml is the following:
configuration
instructions
Export-Packagecom.acme.prj.*;version=${pom.version}/Export-Package
Import-Package!org.apache.log|org.apache.avalon.framework.logger,*/Import-Package
Embed-Dependencycommons-*;scope=compile|runtime/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
/instructions
/configuration
The critical parts to me, because I can't figure out how I can
reproduce them with gradle, are the Import,Export and Private Package
and the Embed-Dependency. Taking and copying them 'as is' doesn't
work; here my last attempt:
jar {
manifest {
version = 2.3
name = 'overwrittenSpecialOsgiName'
instruction 'Embed-Dependency', 'commons-*;scope=compile|runtime'
instruction 'Private-Package', 'org.apache.commons.*'
instruction 'Export-Package', com.acme.prj.*;version=$version
instruction 'Import-Package',
'!org.apache.log|org.apache.avalon.framework.logger,*'
instruction 'Embed-Transitive', 'true'
}
}
The jar inside the jar thing, well, I really don't know why it was
done in that way, but for sure it works, and honestly I can't think
another way to put a dependency that's not shared among all bundles in
a different way.
I apologize for this - too - long email, I hope you don't get bored
while reading, but I don't have a clue at the moment.
Thanks again for the kind support
Ale
On Mon, Oct 11, 2010 at 4:37 PM, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
If you already have a Manifest file generated, you're going to have to
configure the jar task's manifest file given the existing one. I'm not
entirely sure about the best way to do that.
What's your purpose in including the Apache-Commons JAR file within your
generated JAR? You can, of course, add the JAR file itself into your JAR
by
adding the JAR into the resources source set, but unless I'm mistaken,
the
classloader won't know how to load classes from that internal JAR.
The other option is to create a fat jar by merging the other jar and your
generated jar. That can cause problems with licensing, if you're not
careful.
~~ Robert.
On 8 October 2010 15:33, Alessandro Novarini a.novar...@sourcesense.com
wrote:
Hi all,
Reading both gradle and bnd documentation didn't help me to find
answers to the following questions, I hope you can turn the light on
and make me see
Re: [gradle-user] OSGI plugin questions
You'll have to write the classpath stuff manually, although that's not a bad
idea for a plugin to provide (stay tuned...). What else, specifically, are
you looking to add into your Manifest file?
~~ Robert.
On 11 October 2010 12:01, Alessandro Novarini a.novar...@sourcesense.comwrote:
Yes, the package was meant to be just an osgi bundle, there is no way
to run it as a stand-alone app anyway.
I'll try to follow your advice for the dependency issue.
When I run gradle assemble I get the following manifest:
Manifest-Version: 1.0
Export-Package:
com.acme.prj;uses:=org.apache.commons.digester,javax.xml.parsers,
org.w3c.dom.ls,org.w3c.dom,org.w3c.dom.bootstrap;version=2.3
Private-Package: org.apache.commons.*
Tool: Bnd-0.0.384
Bundle-Name: overwrittenSpecialOsgiName
Created-By: 1.6.0_20 (Apple Inc.)
Bundle-Version: 2.3
Bnd-LastModified: 1286812061592
Embed-Transitive: true
Bundle-ManifestVersion: 2
Import-Package:
com.acme.prj;version=2.3,javax.xml.parsers,org.apache.commons.digester;version=2.1,org.w3c.dom,org.w3c.dom.bootstrap,
org.w3c.dom.ls
Bundle-SymbolicName: .something
Embed-Dependency: commons-*;scope=compile|runtime
Some differences are found in the values related to each package
instruction, and there's no dependency jar included in the final
package, of course.
You've caught a good point noticing that there's no Bundle-ClassPath
instruction; is it something I have to write explicitly in the plugin
configuration or it's supposed to exist because the dependencies?
Thank you very much for you time and consideration
Ale
On Mon, Oct 11, 2010 at 5:40 PM, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
The reason the jar-in-jar thing works is because it's specified using
Bundle-ClassPath: that works just for the JAR being run as an OSGi
bundle,
and won't help you if you execute the JAR directly or from outside of
OSGi.
I'd suggest adding the dependencies from the configuration into the jar
task's from properties, although that might you get you into
resolution-time issues.
What is failing to happen with that configuration? It looks like it'd
work
for me.
~~ Robert.
On 11 October 2010 11:34, Alessandro Novarini
a.novar...@sourcesense.com
wrote:
Thank you for your reply.
I'll try to explain better my purpose here, my fault in the previous
mail, sorry:
I have a java project built using maven; this project is an osgi
bundle, and it's built using maven-bundle-plugin, which in turn uses
bnd like osgi plugin for gradle.
What I would like to do is to create a package with gradle that's the
exact copy of the one generated using maven.
The manifest created by maven is the following:
Manifest-Version: 1.0
Export-Package:
com.acme.prj;uses:=org.w3c.dom.ls
,javax.xml.parsers,org.w3c.dom,org.w3c.dom.bootstrap;version=0.0.1
Private-Package:
org.apache.commons.beanutils,org.apache.commons.beanutils.converters,org.apache.commons.beanutils.expression,org.apache.commons.beanutils.locale,org.apache.commons.beanutils.locale.converters,org.apache.commons.collections,org.apache.commons.digester,org.apache.commons.digester.parser,org.apache.commons.digester.plugins,org.apache.commons.digester.plugins.strategies,org.apache.commons.digester.substitution,org.apache.commons.digester.xmlrules,org.apache.commons.logging,org.apache.commons.logging.impl
Ignore-Package: org.apache.log,org.apache.avalon.framework.logger
Bundle-ClassPath:
.,commons-beanutils-1.8.0.jar,commons-digester-2.0.jar,commons-logging-1.1.1.jar
Built-By: me
Tool: Bnd-0.0.255
Bundle-Name: acme - useless project
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.6.0_20
Bundle-Version: 0.0.1
Bnd-LastModified: 1286810196596
Embed-Transitive: true
Bundle-ManifestVersion: 2
Embed-Dependency: commons-*;scope=compile|runtime
Import-Package:
com.acme.prj;version=0.0.1,javax.servlet,javax.xml.parsers,javax.xml.validation,org.apache.commons.collections.comparators,org.apache.commons.collections.keyvalue,org.apache.commons.collections.list,org.apache.commons.collections.set,org.apache.log4j,org.w3c.dom,org.w3c.dom.bootstrap,
org.w3c.dom.ls,org.xml.sax,org.xml.sax.helpers
Bundle-SymbolicName: com.acme.prj
The configuration in the pom.xml is the following:
configuration
instructions
Export-Packagecom.acme.prj.*;version=${pom.version}/Export-Package
Import-Package!org.apache.log|org.apache.avalon.framework.logger,*/Import-Package
Embed-Dependencycommons-*;scope=compile|runtime/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
/instructions
/configuration
The critical parts to me, because I can't figure out how I can
reproduce them with gradle, are the Import,Export and Private Package
and the Embed-Dependency. Taking and copying them 'as is' doesn't
work; here my last attempt:
jar {
manifest {
version = 2.3
name = 'overwrittenSpecialOsgiName
Re: [gradle-user] OSGI plugin questions
Don't do it manually. That's just bad, bad, bad. Have it generated by the Gradle script instead. Once you have the classpath generated within the Gradle script, you can move that code into a plugin very easily. I'm more than happy to help you out on that point, but better you do it than me, because you're getting paid for this work whereas it will be sucking up my free time (and will have to wait until after I get more confidence in my Maven Proxy and OneJar plugins). ~~ Robert. On 11 October 2010 14:09, Alessandro Novarini a.novar...@sourcesense.comwrote: I would be more than happy if I could install that project and make it work. So for now I'll write the classpath manually, but I guess this won't convince the devs in my company to get rid of that bunch of useless xml ( but I'll keep trying ) Thank you Ale -- Robert Fischer robert.fisc...@smokejumperit.com kirjoitti 11.10.2010 kello 19.22: You'll have to write the classpath stuff manually, although that's not a bad idea for a plugin to provide (stay tuned...). What else, specifically, are you looking to add into your Manifest file? ~~ Robert. On 11 October 2010 12:01, Alessandro Novarini a.novar...@sourcesense.com a.novar...@sourcesense.com wrote: Yes, the package was meant to be just an osgi bundle, there is no way to run it as a stand-alone app anyway. I'll try to follow your advice for the dependency issue. When I run gradle assemble I get the following manifest: Manifest-Version: 1.0 Export-Package: com.acme.prj;uses:=org.apache.commons.digester,javax.xml.parsers, org.w3c.dom.ls,org.w3c.dom,org.w3c.dom.bootstrap;version=2.3 Private-Package: org.apache.commons.* Tool: Bnd-0.0.384 Bundle-Name: overwrittenSpecialOsgiName Created-By: 1.6.0_20 (Apple Inc.) Bundle-Version: 2.3 Bnd-LastModified: 1286812061592 Embed-Transitive: true Bundle-ManifestVersion: 2 Import-Package: com.acme.prj;version=2.3,javax.xml.parsers,org.apache.commons.digester;version=2.1,org.w3c.dom,org.w3c.dom.bootstrap, org.w3c.dom.ls Bundle-SymbolicName: .something Embed-Dependency: commons-*;scope=compile|runtime Some differences are found in the values related to each package instruction, and there's no dependency jar included in the final package, of course. You've caught a good point noticing that there's no Bundle-ClassPath instruction; is it something I have to write explicitly in the plugin configuration or it's supposed to exist because the dependencies? Thank you very much for you time and consideration Ale On Mon, Oct 11, 2010 at 5:40 PM, Robert Fischer robert.fisc...@smokejumperit.comrobert.fisc...@smokejumperit.com wrote: The reason the jar-in-jar thing works is because it's specified using Bundle-ClassPath: that works just for the JAR being run as an OSGi bundle, and won't help you if you execute the JAR directly or from outside of OSGi. I'd suggest adding the dependencies from the configuration into the jar task's from properties, although that might you get you into resolution-time issues. What is failing to happen with that configuration? It looks like it'd work for me. ~~ Robert. On 11 October 2010 11:34, Alessandro Novarini a.novar...@sourcesense.com a.novar...@sourcesense.com wrote: Thank you for your reply. I'll try to explain better my purpose here, my fault in the previous mail, sorry: I have a java project built using maven; this project is an osgi bundle, and it's built using maven-bundle-plugin, which in turn uses bnd like osgi plugin for gradle. What I would like to do is to create a package with gradle that's the exact copy of the one generated using maven. The manifest created by maven is the following: Manifest-Version: 1.0 Export-Package: com.acme.prj;uses:=org.w3c.dom.ls ,javax.xml.parsers,org.w3c.dom,org.w3c.dom.bootstrap;version=0.0.1 Private-Package: org.apache.commons.beanutils,org.apache.commons.beanutils.converters,org.apache.commons.beanutils.expression,org.apache.commons.beanutils.locale,org.apache.commons.beanutils.locale.converters,org.apache.commons.collections,org.apache.commons.digester,org.apache.commons.digester.parser,org.apache.commons.digester.plugins,org.apache.commons.digester.plugins.strategies,org.apache.commons.digester.substitution,org.apache.commons.digester.xmlrules,org.apache.commons.logging,org.apache.commons.logging.impl Ignore-Package: org.apache.log,org.apache.avalon.framework.logger Bundle-ClassPath: .,commons-beanutils-1.8.0.jar,commons-digester-2.0.jar,commons-logging-1.1.1.jar Built-By: me Tool: Bnd-0.0.255 Bundle-Name: acme - useless project Created-By: Apache Maven Bundle Plugin Build-Jdk: 1.6.0_20 Bundle-Version: 0.0.1 Bnd-LastModified: 1286810196596 Embed-Transitive: true Bundle-ManifestVersion: 2 Embed-Dependency: commons-*;scope=compile|runtime Import-Package: com.acme.prj;version=0.0.1,javax.servlet,javax.xml.parsers
Re: [gradle-user] Gradle and Java ME
This is getting a bit OT, but here goes. I'm not sure what harnessing the WTK means, but isn't the whole purpose of Java's VM approach to minimize architectural changes like 32 vs. 64 bit? ~~ Robert. On 13 October 2010 11:31, Russel Winder rus...@russel.org.uk wrote: Baruch, On Wed, 2010-10-13 at 17:26 +0200, Baruch Sadogursky wrote: it shouldn't be that difficult. You can use antenna's tasks from Gradle programatically (in Groovy). Indeed, Antenna is clearly part of the mix, but the problem is managing the entire Java infrastructure on a 64-bit system where you have to ensure everything runs with a 32-bit JVM. Not to mention properly harnessing the WTK. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net sip%3arussel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [gradle-user] how to zip sources into zip file
Gretar-
Mind sharing that plugin? I was hoping there was something that would
produce source and doc archives for me.
~~ Robert.
On 15 October 2010 11:19, Gretar Arnason gretarr...@gmail.com wrote:
I'm using the following in a Plugin extending 'java' plugin for 0.9-rc-1 -
uploading to a maven repo:
void apply(Project target){
...
target.task(['type': Zip], 'sourceJar') {
baseName = baseName + -src
extension = 'jar'
from target.sourceSets.main.java,
target.sourceSets.main.resources
}
target.artifacts {
archives(target.sourceJar) {classifier = 'sources'}
}
...
}
should be translatable to a build.gradle script
regards
gretar
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] src/test or extra test project ?
I go for a hybrid route: I have the most basic unit test code (and ScalaCheck) living alongside my code, and any kind of integrative or functional tests living elsewhere. This allows me to easily run some key sanity checking code, and to only have to recompile that smaller subset when I want to check those changes quickly. ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] Maven-Proxy [was: Performance problem with simple build script and several Maven repos]
I was playing around with integrating (an updated version of) a Maven-Proxy
daemon with Gradle, so you'd just hit the one proxy from all your builds.
This makes things a lot faster and enables off-line mode (only hit
localhost most of the time), and is also be nicer to all the poor
repositories that you're beating the crap out of every time you build.
The down side is that you lose the ability to limit what repositories you
visit to check for artifacts: in terms of security/theory/whatever, all
projects practically check the superset of all repositories that were used
by build scripts. But the check is only made once an hour per non-snapshot
artifact, so that's fine for performance.
Unfortunately, I had some issues with the conversation between Maven-Proxy
and Gradle, and then life got crazy with school, so I put it on the back
burner.
If you're interested in checking out that code, fork my Gradle-Plugins repo
on GitHub.
~~ Robert.
On 8 November 2010 16:18, Paul Speed psp...@users.sourceforge.net wrote:
On 11/8/2010 4:14 PM, Adam Murdoch wrote:
On 08/11/2010, at 5:12 PM, Paul Speed wrote:
On 11/8/2010 1:10 AM, Adam Murdoch wrote:
There's a few things we'd like to change in Gradle to help deal with
this problem:
* Add some better diagnostics, so you can see which
dependencies/repositories are taking the time. For example, dependency
resolution might be integrated into the profiling report.
* Provide a way to specify which repository (or repositories) to use for
a given dependency. This would allow you to optimise how Gradle searches
for your dependencies.
* Deep integration with the dependency management. This would let you do
things such as providing your own caching strategies.
Those would be nice.
Maybe there's already a way to do this, but my personal wish would be
to be able to temporarily disable all remote access, like on the
command line or something.
For example, sometimes my internet connection goes down and it kills
my build time-wise unless I go and manually comment out the
repositories. In this case, I already have all of the dependencies I
need, I just want to disable the rolling check for snapshots in remote
repositories. Sometimes it's just that one of the repos in my list
goes down and it would be nice to just ignore them all for a while.
Is there maybe already a way to do this?
Not really. I've not tried this, but you should be able to set the
snapshot timeout for each repository to 'never'. For example:
import org.gradle.api.internal.artifacts.ivyservice.GradleIBiblioResolver
if (project.hasProperty('offline') {
repositories.withType(GradleIBiblioResolver).allObjects { repository -
repository.snapshotTimeout = GradleIBiblioResolver.NEVER
}
}
This isn't really an 'offline' mode as such. It just reduces the
likelihood that Gradle will try hit the network.
Again, by providing deep integration with the dependency management
system, you'll be able to easily add code which can short-circuit any or
all of the repositories, and so implement an 'offline' mode.
Perhaps better than a manual mode that you have to set, would be if
Gradle could better detect and deal with unreachable repositories. For
example:
* Apply more sensible timeouts, rather than the TCP timeout. For
example, when checking for an updated snapshot, wait maybe 15 seconds.
Perhaps combine this with parallel resolution.
This would be good... though without parallel resolution this would still
add a minute and a half or so to some of my builds when I'm offline for
some reason.
* Add something to the Gradle UIs which would let you skip dependency
resolution when Gradle is just checking for updates. For example, you
might be able to do ctrl-s, say, to skip resolution.
* The Gradle daemon resolves dependencies in the background, so that
when you execute a build, it already knows the status of each
repository, and whether there are any updates.
Neither of those would help me personally, unfortunately.
I've been meaning to look through things a bit deeper to understand why an
offline switch is hard/impossible... or what it would take to add one,
etc.. In the mean time, I may at least try the resolver trick above to see
if it improves things when I'm unplugged.
-Paul
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[gradle-user] Less Sensitive Jar?
Every time I run my compile, I get the following order of steps: :ashlar-compiler:ensureJavaccHome UP-TO-DATE :ashlar-compiler:makeJavaccSrcDir SKIPPED :ashlar-compiler:generateFromJJTree UP-TO-DATE :ashlar-compiler:generateFromJavacc UP-TO-DATE :ashlar-lang:compileJava UP-TO-DATE :ashlar-lang:compileGroovy UP-TO-DATE :ashlar-lang:processResources UP-TO-DATE :ashlar-lang:classes UP-TO-DATE :ashlar-lang:jar :ashlar-shared:compileJava UP-TO-DATE :ashlar-shared:compileScala UP-TO-DATE :ashlar-shared:processResources UP-TO-DATE :ashlar-shared:classes UP-TO-DATE :ashlar-shared:jar :ashlar-compiler:compileJavacc ... Now, since ashlar-lang and ashlar-shared both updated their jar, all the following dependencies are going to have to be redone. How would I go about telling the jar tasks to not execute if classes and processResources were both up to date and there is a jar already in existence? ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Less Sensitive Jar?
Using gradle -i, it tipped me off that the manifest file had changed.
Looks like the osgi plugin is generating the manifest a bit
aggressively: even if there is no change in the content of the
manifest file, the timestamp ends up updated on it.
Boo.
~~ Robert.
On 17 November 2010 16:25, Adam Murdoch a...@gradle.biz wrote:
On 18/11/2010, at 7:34 AM, Robert Fischer wrote:
Every time I run my compile, I get the following order of steps:
:ashlar-compiler:ensureJavaccHome UP-TO-DATE
:ashlar-compiler:makeJavaccSrcDir SKIPPED
:ashlar-compiler:generateFromJJTree UP-TO-DATE
:ashlar-compiler:generateFromJavacc UP-TO-DATE
:ashlar-lang:compileJava UP-TO-DATE
:ashlar-lang:compileGroovy UP-TO-DATE
:ashlar-lang:processResources UP-TO-DATE
:ashlar-lang:classes UP-TO-DATE
:ashlar-lang:jar
:ashlar-shared:compileJava UP-TO-DATE
:ashlar-shared:compileScala UP-TO-DATE
:ashlar-shared:processResources UP-TO-DATE
:ashlar-shared:classes UP-TO-DATE
:ashlar-shared:jar
:ashlar-compiler:compileJavacc
...
Now, since ashlar-lang and ashlar-shared both updated their jar, all
the following dependencies are going to have to be redone. How would
I go about telling the jar tasks to not execute if classes and
processResources were both up to date and there is a jar already in
existence?
The jar task will do this already, unless there are additional input files
to the jar task which have changed, or something about the output file has
changed, such as its name. Are you perhaps using a timestamp in your version
property? This will mean that the jar file name will change each time you
run Gradle, and so the jar task will need to rebuild it. Either way if you
run Gradle with -i you will get some log messages telling you why Gradle has
decided to run the jar task. You might start with that to fix the problem.
Assuming you're using a timestamp in your version, some workarounds:
* Don't include the version in the jar file name. For example:
jar.archiveName = ${project.name}.jar. This won't affect the name the jar
will end up with when you publish it to a repository. It will, however,
affect the name if you bundle the jar into an archive, such as a war.
*Don't use a timestamp in your version. You could use -SNAPSHOT instead. For
the Gradle build, we use the timestamp of the most recently changed source
file.
Currently, this is a limitation of the incremental build implementation.
There are some things we might change in Gradle to address the problem:
* Use the classes directory rather than the jar when compiling against a
project dependency.
* Introduce the concept of a classpath. For example, when a task has a
classpath as its input, it doesn't matter if the name of a jar has changed,
only that it's contents and position in the classpath are the same as last
time.
* Ignore resources in the classpath when compiling (so you can have, for
example, a version.properties resource that contains a build time
timestamp).
* Create a 'version' plugin, which would provide a few different versioning
schemes, including some which are incremental build friendly. Perhaps we
might have a scheme which is timestamp based, but where the timestamp
changes only when some source changes.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Less Sensitive Jar?
Done: http://jira.codehaus.org/browse/GRADLE-1227
~~ Robert.
On 17 November 2010 16:56, Adam Murdoch a...@gradle.biz wrote:
On 18/11/2010, at 8:52 AM, Robert Fischer wrote:
Using gradle -i, it tipped me off that the manifest file had changed.
Looks like the osgi plugin is generating the manifest a bit
aggressively: even if there is no change in the content of the
manifest file, the timestamp ends up updated on it.
Could you add a JIRA issue for this?
~~ Robert.
On 17 November 2010 16:25, Adam Murdoch a...@gradle.biz wrote:
On 18/11/2010, at 7:34 AM, Robert Fischer wrote:
Every time I run my compile, I get the following order of steps:
:ashlar-compiler:ensureJavaccHome UP-TO-DATE
:ashlar-compiler:makeJavaccSrcDir SKIPPED
:ashlar-compiler:generateFromJJTree UP-TO-DATE
:ashlar-compiler:generateFromJavacc UP-TO-DATE
:ashlar-lang:compileJava UP-TO-DATE
:ashlar-lang:compileGroovy UP-TO-DATE
:ashlar-lang:processResources UP-TO-DATE
:ashlar-lang:classes UP-TO-DATE
:ashlar-lang:jar
:ashlar-shared:compileJava UP-TO-DATE
:ashlar-shared:compileScala UP-TO-DATE
:ashlar-shared:processResources UP-TO-DATE
:ashlar-shared:classes UP-TO-DATE
:ashlar-shared:jar
:ashlar-compiler:compileJavacc
...
Now, since ashlar-lang and ashlar-shared both updated their jar, all
the following dependencies are going to have to be redone. How would
I go about telling the jar tasks to not execute if classes and
processResources were both up to date and there is a jar already in
existence?
The jar task will do this already, unless there are additional input files
to the jar task which have changed, or something about the output file has
changed, such as its name. Are you perhaps using a timestamp in your version
property? This will mean that the jar file name will change each time you
run Gradle, and so the jar task will need to rebuild it. Either way if you
run Gradle with -i you will get some log messages telling you why Gradle has
decided to run the jar task. You might start with that to fix the problem.
Assuming you're using a timestamp in your version, some workarounds:
* Don't include the version in the jar file name. For example:
jar.archiveName = ${project.name}.jar. This won't affect the name the jar
will end up with when you publish it to a repository. It will, however,
affect the name if you bundle the jar into an archive, such as a war.
*Don't use a timestamp in your version. You could use -SNAPSHOT instead. For
the Gradle build, we use the timestamp of the most recently changed source
file.
Currently, this is a limitation of the incremental build implementation.
There are some things we might change in Gradle to address the problem:
* Use the classes directory rather than the jar when compiling against a
project dependency.
* Introduce the concept of a classpath. For example, when a task has a
classpath as its input, it doesn't matter if the name of a jar has changed,
only that it's contents and position in the classpath are the same as last
time.
* Ignore resources in the classpath when compiling (so you can have, for
example, a version.properties resource that contains a build time
timestamp).
* Create a 'version' plugin, which would provide a few different versioning
schemes, including some which are incremental build friendly. Perhaps we
might have a scheme which is timestamp based, but where the timestamp
changes only when some source changes.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[gradle-user] [ANN] DepNames Plugin
http://enfranchisedmind.com/blog/posts/gradle-depnames/ As part of the 0.6.7 release of Gradle-Plugins, there's a new game in town: the DepNames plugin. It allows you to define dependency keywords globally and/or in the root project, and then to use keywords to define dependencies (instead of the whole specification string). It's really nice for multi-project set-ups and to stash away common configurations. ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] Re: [ANN] DepNames Plugin
The 0.6.8 version will allow GString-style interpolation in the values. ~~ Robert. On 20 November 2010 11:58, Robert Fischer robert.fisc...@smokejumperit.com wrote: http://enfranchisedmind.com/blog/posts/gradle-depnames/ As part of the 0.6.7 release of Gradle-Plugins, there's a new game in town: the DepNames plugin. It allows you to define dependency keywords globally and/or in the root project, and then to use keywords to define dependencies (instead of the whole specification string). It's really nice for multi-project set-ups and to stash away common configurations. ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Released some gradle plugins open source
Thank you very much! I was just looking for something like the repository plugin. Now, if git just had some kind of external mechanism a la svn... ~~ Robert. On 21 November 2010 11:00, Yan (pongasoft) y...@pongasoft.com wrote: Hello Guys First of all I wanted to express my deep gratitude for creating such an amazing build framework. I started by porting my own project to gradle (http://kiwidoc.com) and then I used gradle for all the open source projects I just released on github (https://github.com/linkedin). So I have spent quite some time with it including writing plugins. And I must say I am very impressed, even with the code itself (as I had to look into the code to try to understand some parts of the framework better). Anyway, just wanted to share the fact that I just open sourced the gradle plugins I wrote: https://github.com/linkedin/gradle-plugins I think that the 'org.linkedin.repository' and 'org.linkedin.release' plugins will hopefully become obsolete when gradle 1.0 is relased :) Kind regards Yan Pujante LinkedIn co-founder. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: [ANN] DepNames Plugin
Yeah, I was working off of maps, too, but it got to be pretty lame when I started to copy the map into a second project. I'm thinking about creating a freezeDepNames (or something) task which would generate one canonical list and drop it into the current project root directory. That'd allow you to keep an explicit record of the artifacts in shared projects, and would prevent changes in the global configuration from effecting your local. Although adding versions to your keys would accomplish that latter part, too (e.g. commons_lang_2_5). ~~ Robert. On 21 November 2010 14:38, Joern Huxhorn jhuxh...@googlemail.com wrote: Nice one, I'm currently doing this using maps, see https://github.com/huxi/lilith/blob/master/dependencyDefinitions.gradle Something like your plugin would be nice if included in the Gradle base, too. I'm quite happy with my current solution since it's already a vast improvement compared to the maven dependencyManagement - but your plugin looks promising. Cheers, Joern. On 20.11.2010, at 18:22, Robert Fischer wrote: The 0.6.8 version will allow GString-style interpolation in the values. ~~ Robert. On 20 November 2010 11:58, Robert Fischer robert.fisc...@smokejumperit.com wrote: http://enfranchisedmind.com/blog/posts/gradle-depnames/ As part of the 0.6.7 release of Gradle-Plugins, there's a new game in town: the DepNames plugin. It allows you to define dependency keywords globally and/or in the root project, and then to use keywords to define dependencies (instead of the whole specification string). It's really nice for multi-project set-ups and to stash away common configurations. ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Released some gradle plugins open source
Oh, you have no idea how happy you just made me. ~~ Robert. On 21 November 2010 18:10, Luke Daley l...@ldaley.com wrote: On 22/11/2010, at 2:05 AM, Robert Fischer wrote: Thank you very much! I was just looking for something like the repository plugin. Now, if git just had some kind of external mechanism a la svn... Git submodules. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] task dependency order
Yeah, we really don't want dependsOn to imply an ordering, because
else builds will just end up being a broken mess of unnecessary
bookkeeping. It would also kill the ability to do concurrent build
steps (should we have such a thing).
~~ Robert.
On 24 November 2010 10:16, Dierk König dierk.koe...@canoo.com wrote:
See the user guide.
Dependencies are in no guaranteed order.
The current order in alphabetical to have the same sequence with every
build, but that is an implementation detail.
The execution order is defined when the output-input characteristic requires
it.
cheers
Dierk
Am 24.11.2010 um 16:09 schrieb Gretar Arnason:
Hi, I've was just trying out something and was wondering if the following is
an expected behavior (using 0.9-rc-2)
in build.gradle file:
task a {
println a
}
task b {
println b
}
task c (dependsOn: [b,a]) {
println c
}
gives me the the output when running gradle -q c:
a
b
c
I was expecting to see:
b
a
c
Is my intuition just wrong?
I would think that the order of dependencies should be respected if the
tasks being depended on do not have any dependencies defined themselves.
If I'm wrong about this can someone then explain here to me then what I
should expect and why?
How could I get the same effect without adding explicit dependency between a
and b?
Thanks
gretar
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] task dependency order
dependency-order-by-declaration-sequence is in my eyes one of the features that makes so many ANT builds difficult to maintain. You need to know the whole build to safely make a tiny change in the dependency chain and you have to make those changes more often. You even have to know the whole build to _use_ it correctly! This is what I was getting at in saying that dependency ordering becomes a mess of fragile bookkeeping. Conflicting dependency resolutions orders—argh! ~~ Robert. On 24 November 2010 17:20, Dierk König dierk.koe...@canoo.com wrote: The execution order is defined when the output-input characteristic requires it. I'm probably not familiar enough with gradle to know exactly what you mean by 'output-input characteristic' could you elaborate further Gradle tasks can define what they take as input and what they produce as output. And many tasks do. If task x produces an output artifact that is consumed as input by task y then a dependency on both x and y is guaranteed to be in executed sequence: first x, second y (unless the output is up to date and x can be skipped). x - artifact - y a.dependsOn = [y, x] // declare the 'what', not the 'how' This behavior is one of the distinctively mindful design choices of Gradle. Imagine the sequence of dependsOn declarations would define the order. You can get a conflict with the output-input chain sequence. Now - who wins? That in my opinion is the best example where imposing an order-by-declaration-sequence limits the build system. It is not the main reason, though. The reason - on an architectural level - is that dependencies _have_ no order by nature. Also, with an imposed order, you would care too much about the how where you should rather care about than the what. cheers Dierk P.S. dependency-order-by-declaration-sequence is in my eyes one of the features that makes so many ANT builds difficult to maintain. You need to know the whole build to safely make a tiny change in the dependency chain and you have to make those changes more often. You even have to know the whole build to _use_ it correctly! P.P.S. In case you haven't guessed, yet: I love Gradle! Kudos to Hans and Adam! - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Incremental build and dependencies?
What are the semantics you are trying to communicate here? What are
you trying to accomplish?
~~ Robert.
On 27 November 2010 17:48, Steven Devijver sdevij...@yahoo.fr wrote:
Hey,
I have these tasks:
def my_dir = test_dir
task A(type: Delete) {
delete = my_dir
}
task B(dependsOn: A) {
outputs.upToDateWhen {
file(my_dir).exists()
}
doFirst {
ant.mkdir dir: my_dir
}
}
I was assuming that when a task is up-to-date its dependencies wouldn't be
executed. However, B is never up-to-date because the upToDateWhen closure is
executed before B is executed but not before A is executed. A is always
executed regardless of B's outputs.
Is there a way of avoiding B's dependencies are executed when its outputs
are up-to-date?
Thanks
Steven
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] avoid skipping tests
The easiest way is to call clean and/or delete the build directory and/or delete the .gradle directory. Your CI server should probably be working from a clean check-out (at least reasonably frequently...) anyway. ~~ Robert. On 30 November 2010 15:37, Marcus Better mar...@better.se wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, my Hudson build server does not like it when tests are sometimes skipped in a build because the classes didn't change. How can I make sure the tests run for each build? Cheers, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkz1YKQACgkQXjXn6TzcAQlj7QCfSN8eHpJhsFY1PGYIImm313ka ERcAnA4it+60e5/rl061znf5+opXYhde =E3eI -END PGP SIGNATURE- - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] Java Agent?
How can I use a Java agent when executing my tests? ~~ Robert.
Re: [gradle-user] Java Agent?
I'll give that a shot: thanks!
~~ Robert.
On 30 November 2010 17:32, Adam Murdoch a...@gradle.biz wrote:
On 01/12/2010, at 7:44 AM, Robert Fischer wrote:
How can I use a Java agent when executing my tests?
Probably, but I've not tried it. You should just be able to use the
appropriate jvm args:
test {
jvmargs '-javaagent:blah'
}
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
Re: [gradle-user] calling task multiple times with different parameters
Since the user is never calling these things individually, I probably
wouldn't approach this as a bunch of tasks. Instead, I'd probably
create one Gradle task to accomplish this and then use the Ant zip
task through the project's ant property.
http://ant.apache.org/manual/Tasks/zip.html
~~ Robert.
On 3 December 2010 09:38, richardm richard.mur...@orchard-systems.co.uk wrote:
Is is possible to call a task in Gradle with different parameters? I've got
a zip task which I'd like to call several times. The project below defines
a single zip task which uses a properties file to apply filters during the
zip. I need to create 4 zip files like this (the only differences are the
zip names and the properties file used to filter with). Is it possible to
do this with one task and call it four times with different parameters?
project(':jboss') {
Properties jboss4LiveProps = new Properties()
jboss4LiveProps.load(new
FileInputStream($projectDir/property-files/jboss4-live.properties))
dependsOn(':otherProject')
filesToDeploy = dir('files_to_deploy')
task zipIt(type: Zip, dependsOn: filesToDeploy) {
baseName = 'jboss-4.0.2-live'
destinationDir = file(files_to_deploy)
from ('jboss-4.0.2-master') {
include **/*.xml, **/*.bat, **/*.sh, **/*properties
filter(ReplaceTokens, tokens: jboss4LiveProps)
into 'jboss-4.0.2-live'
}
from .
}
task build(dependsOn: 'zipIt')
}
--
View this message in context:
http://gradle.1045684.n5.nabble.com/calling-task-multiple-times-with-different-parameters-tp3290970p3290970.html
Sent from the gradle-user mailing list archive at Nabble.com.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[gradle-user] Compile But Not Runtime Dependency?
I have a jar that I use to mock some code for compiling, but then do
not want that mock jar on the classpath for runtime: the functionality
is provided by a javaagent. What's the recommended way to handle
this? I'm not sure how to redefine the runtime configuration to
exclude the jar, so I tried to implement it by mangling the classpath
of compile tasks:
configurations {
java7Mock
}
dependencies {
java7Mock jsr292Mock
}
tasks.withType(AbstractCompile).allTasks { Task t -
t.classpath = t.classpath + t.project.configurations.java7Mock
}
That, however, fails with the following message:
Cause: Failed to notify action.
Cause: Cannot invoke method plus() on null object
So I tried this:
tasks.withType(AbstractCompile).allTasks { Task t -
if(t.classpath) {
t.classpath = t.classpath + t.project.configurations.java7Mock
} else {
t.classpath = t.project.configurations.java7Mock
}
}
I figured that the other necessary dependencies would be queued up
later, but I actually didn't get anything *but* the java7Mock at that
point.
So, recommendations as to how to approach this? Am I going about it all wrong?
~~ Robert.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Gradle Plugin for a new framework
Is your question how to define new SourceSets representing particular folders?
If so, see 21.7 in the User Guide:
http://gradle.org/0.9-rc-3/docs/userguide/java_plugin.html#sec:source_sets
~~ Robert.
On 9 December 2010 06:09, rajmahendra rajmahen...@gmail.com wrote:
Hi
I am creating a Gradle plugin for first time for a new Framework.
i am trying to create a project structure for the framework.
i can create a project using a build.gradle as...
task create-dirs {
sourceSets.all*.java.srcDirs*.each { it.mkdirs() }
sourceSets.all*.resources.srcDirs*.each { it.mkdirs() }
}
I want to add my project structure into soruceSets so i can create my
project folders somethign like
src/main/myfolder
how to add my structure into sourceSets througth Plugin
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Gradle-Plugin-for-a-new-framework-tp3298741p3298741.html
Sent from the gradle-user mailing list archive at Nabble.com.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: question about urlresolver
Unfortunately, Ivy needs a patterns for artifacts, and those are far from standard on GitHub. If you can define them, though, for a particular project, then you should be able to specify a resolver without too much difficulty. ~~ Robert. On 8 December 2010 19:40, Benjamin Muschko benjamin.musc...@gmail.com wrote: I am trying to resolve a JAR file from GitHub but have the same issue. Is there any kind of workaround to make this work? It would be great to use the GitHub download section as repository. Thanks, Ben -- View this message in context: http://gradle.1045684.n5.nabble.com/question-about-urlresolver-tp3259653p3298305.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] Re: Compile But Not Runtime Dependency?
For the record, I've implemented this work-around:
configurations { java7Mock }
dependencies {
java7Mock jsr292Mock
}
gradle.taskGraph.whenReady {
tasks.withType(AbstractCompile).allTasks { Task t -
t.classpath = t.classpath + t.project.configurations.java7Mock
}
}
But it makes my spidey-sense tingle: it doesn't seem right to be
injecting the new element onto the classpath after the whole task
graph is resolved.
~~ Robert.
On 9 December 2010 13:19, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
I have a jar that I use to mock some code for compiling, but then do
not want that mock jar on the classpath for runtime: the functionality
is provided by a javaagent. What's the recommended way to handle
this? I'm not sure how to redefine the runtime configuration to
exclude the jar, so I tried to implement it by mangling the classpath
of compile tasks:
configurations {
java7Mock
}
dependencies {
java7Mock jsr292Mock
}
tasks.withType(AbstractCompile).allTasks { Task t -
t.classpath = t.classpath + t.project.configurations.java7Mock
}
That, however, fails with the following message:
Cause: Failed to notify action.
Cause: Cannot invoke method plus() on null object
So I tried this:
tasks.withType(AbstractCompile).allTasks { Task t -
if(t.classpath) {
t.classpath = t.classpath + t.project.configurations.java7Mock
} else {
t.classpath = t.project.configurations.java7Mock
}
}
I figured that the other necessary dependencies would be queued up
later, but I actually didn't get anything *but* the java7Mock at that
point.
So, recommendations as to how to approach this? Am I going about it all
wrong?
~~ Robert.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Compile But Not Runtime Dependency?
Won't having testCompile extend compileWithExtraStuff result in
testRuntime also containing the extra stuff?
~~ Robert.
On 9 December 2010 15:51, Adam Murdoch a...@gradle.biz wrote:
On 10/12/2010, at 5:19 AM, Robert Fischer wrote:
I have a jar that I use to mock some code for compiling, but then do
not want that mock jar on the classpath for runtime: the functionality
is provided by a javaagent. What's the recommended way to handle
this? I'm not sure how to redefine the runtime configuration to
exclude the jar, so I tried to implement it by mangling the classpath
of compile tasks:
configurations {
java7Mock
}
dependencies {
java7Mock jsr292Mock
}
tasks.withType(AbstractCompile).allTasks { Task t -
t.classpath = t.classpath + t.project.configurations.java7Mock
}
This approach is a bit too dependent on order, and so you're running into
problems with things being null or empty.
I think the best option is to mess with the compile and runtime classpaths
of the appropriate source sets. Here's an example:
configurations {
extraStuff
compileWithExtraStuff { extendsFrom compile, extraStuff }
}
dependencies {
extraStuff ''
}
sourceSets.main {
compileClasspath = configurations.compileWithExtraStuff
}
This adds the dependency to the compile classpath only, ie it won't be added
to runtime, testCompile, testRuntime, etc
You could add something like this to include the dependency in the
testCompile and testRuntime classpaths:
configurations {
testCompile { extendsFrom extraStuff }
}
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Gradle Plugin for a new framework
What does your plugin code look like right now? ~~ Robert. On 13 December 2010 06:11, rajmahendra rajmahen...@gmail.com wrote: yes, But i like to have this inside my plugin. i dont want to tell my user to do this in his build.gradle -- View this message in context: http://gradle.1045684.n5.nabble.com/Gradle-Plugin-for-a-new-framework-tp3298741p3302960.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Multiple downloads of the same jar in a multi project build.
This is a problem with snapshots, not repositories. By default, the cache is never used for snapshots because, y'know, they're snapshots and subject to change. Try setting the snapshot timeout to one minute and see if that solves the repeated downloads in a single build: http://www.mail-archive.com/user@gradle.codehaus.org/msg05444.html ~~ Robert. On 10 December 2010 13:42, Dave King djk...@gmail.com wrote: So we have a large project that uses multiple sub projects and uses jars that we produce from other separate projects in house. When we update one of the core jars we see each sub project do a download of the jar. so for each sub project we see: Download http://buildmaster:8081/nexus/content/groups/public-snapshots/com.elluminate.classroom/classroom-util/1.0-SNAPSHOT/ivy.xml Download http://buildmaster:8081/nexus/content/groups/public-snapshots/com.elluminate.classroom/classroom-util/1.0-SNAPSHOT/classroom-util-1.0-SNAPSHOT-sources.jar Download http://buildmaster:8081/nexus/content/groups/public-snapshots/com.elluminate.classroom/classroom-util/1.0-SNAPSHOT/classroom-util-1.0-SNAPSHOT.jar I would have expected that we'd see that once and then it would be found in the cache. Is this expected behavior or do we have a problem? This isn't a big deal for those of who are on the LAN with the build master machine, but we're spread from Vancouver to New York and we're trying to speed up the build for remote users. - Peace Dave - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Default Memory Settings?
For one, it will mess with people who set their own Xmx values via $GRADLE_OPTS and $JAVA_OPTS. ~~ Robert. On 15 December 2010 20:18, Dave King djk...@gmail.com wrote: We've been hitting some very strange errors, turns out they were memory related. In the shell script all we had to do was uncomment the lines: @rem set GRADLE_OPTS=%GRADLE_OPTS% -Xmx512m @rem set JAVA_OPTS=%JAVA_OPTS% -Xmx512m It wasn't obvious that the issues were memory related. Some util developers swallow error messages and just say something bad happened eh. or something not too far from that. So what would it hurt to uncomment those lines by default? BTW uncommenting those lines was a huge boost to performance, from 25% to well over 200% depending on the machine. - Peace Dave - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Default Memory Settings?
Is there any specification on whether the first or last -Xmx argument is the one used by the JVM? I presume it's the last (the last -D specification is taken), but that may not be a safe assumption. If it's the last, then simply inverting the arguments would work fine for everyone: @rem set GRADLE_OPTS=-Xmx512m %GRADLE_OPTS% @rem set JAVA_OPTS=-Xmx512m %JAVA_OPTS% ~~ Robert. On 16 December 2010 01:01, Dave King djk...@gmail.com wrote: True for some existing users, but I expect far more new users would trip over it just as we did. The docs those vars should mention the defaults in the scripts and where to change them. - Peace Dave On Wed, Dec 15, 2010 at 8:16 PM, Robert Fischer robert.fisc...@smokejumperit.com wrote: For one, it will mess with people who set their own Xmx values via $GRADLE_OPTS and $JAVA_OPTS. ~~ Robert. On 15 December 2010 20:18, Dave King djk...@gmail.com wrote: We've been hitting some very strange errors, turns out they were memory related. In the shell script all we had to do was uncomment the lines: @rem set GRADLE_OPTS=%GRADLE_OPTS% -Xmx512m @rem set JAVA_OPTS=%JAVA_OPTS% -Xmx512m It wasn't obvious that the issues were memory related. Some util developers swallow error messages and just say something bad happened eh. or something not too far from that. So what would it hurt to uncomment those lines by default? BTW uncommenting those lines was a huge boost to performance, from 25% to well over 200% depending on the machine. - Peace Dave - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Ivy Caches in gradle
+1 to Russel's annoyance. I don't have a great solution, but I've set up a script on boot to wipe out the cache directory. That script has reclaimed rather impressive amounts of hard disk space (by my ancient laptop's standards, anyway) in the past. ~~ Robert. On 28 December 2010 08:36, Russel Winder rus...@russel.org.uk wrote: Adam, On Tue, 2010-12-28 at 07:09 +1100, Adam Murdoch wrote: On 28/12/2010, at 7:06 AM, Munoz, Pablo [Tech] wrote: Is there a way to set ivy caches [1] in gradle? There isn't at the moment. I'm curious, why do you want to configure the ivy cache? I am not sure about OP's situation but I find the ever increasing (and all to often hugely out of date) cache of Maven, Ivy, Gradle, Grapes, etc. a real irritation. I regularly end up simply deleting the whole thing when I know I am on a high speed connection simply to get rid of all the dross. Gradle/Ivy is particularly prone to leaving thousands of files in ~/.gradle/cache called resolved-* and I often have to go in and delete them. This is irritating. There should be a way of keeping the cache clean apart from manual intervention. Tidying up ~/.gradle/cache/*/* to remove all the outdated rubbish is also an extremely length and tedious operation. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net sip%3arussel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [gradle-user] Welcome Peter Niederwieser
Score one for Gradle! ~~ Robert. On Tue, Jan 11, 2011 at 3:37 AM, Hans Dockter h...@gradle.biz wrote: Hi, we are very excited that Peter Niederwieser, the author of Spock, has joined the Gradle team. Welcome Peter! Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] Composite Javadocs?
I've got a multi-project build. Is there a way to generate composite javadocs? The javadoc task seems to produce them per-project, but I'd prefer to have a single big compiled version—or at least have them interlinked! This is the kind of thing I've gone off to write a plug-in for, only to discover that it's actually already in existence, so I'm checking in. ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] Query for Daemon?
Is it possible to query for the daemon? I've discovered an issue when using the daemon (some code goes to the FileDescriptors in order to grab stdout, which means the output is lost under the daemon) and I'd like to be able to disable that behavior if the daemon is running. ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Password encryption
Have the CI server provide the password as a Java property. That will be accessible to the build script. Sooner or later, the CI server is going to have to have a secret that it exposes to the build script in order to decrypt the password. From a security standpoint, that secret is equivalent to the password. So why not just have it expose the password itself directly to the build script, and not muck around with encrypting/decrypting anything? Either that, or you'll need some kind of smarter authentication (a la SSH). ~~ Robert. On Fri, Mar 25, 2011 at 10:48 AM, Benjamin Muschko benjamin.musc...@gmail.com wrote: Thanks for pointing me to your plugin. I'll def. have a look. Unfortunately, it's not for artifact uploading. I guess what I actually want is obfuscation which is easy enough to implement with a key stored somewhere else. -- View this message in context: http://gradle.1045684.n5.nabble.com/Password-encryption-tp4264140p4264248.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] [ANN] Compiler-Base and Compiler-Mirah plugins
I've generated a plugin that can be used as a base for implementing compilers of all stripes: http://github.com/RobertFischer/Gradle-Compiler-Plugins Also, there's a plugin specifically for Headius' Mirah language based on it: http://github.com/RobertFischer/Gradle-Mirah-Compiler ~~ Robert.
Re: [gradle-user] gradle antlr3
Looks like they changed the API on you. Going to have to figure out
the new Ant task class name.
~~ Robert.
On Sat, Apr 16, 2011 at 4:30 PM, Marko Bauhardt m...@101tec.com wrote:
hi all.
i'm using gradle 1.0 milestone-1.
as i understand gradle's antlr plugin works with antlr2. i tried to
configure gradle to use anltr3.
but i'm getting this exception (see below)
what i have todo to that gradle is using antlr3?
any hints?
thanks
marko
---
configurations {
grammarCompile
}
dependencies {
grammarCompile group: 'org.antlr', name: 'antlr', version: '3.1',
transitive:false
compile group: 'org.antlr', name: 'antlr-runtime', version: '3.1',
transitive:false
testCompile group: 'junit', name: 'junit', version: '4.+'
}
task generateGrammarSources {
generatedDir = new File(project.buildDir.toString() + '/generated-src/')
generatedDir.mkdirs()
ant.taskdef(name: 'antlr3', classname: 'org.antlr.Tool', classpath:
configurations.grammarCompile.asPath)
ant.antlr3(target: 'src/main/antlr/Calculator.g', outputdirectory:
'build/generated-src/')
}
---
:: loading settings :: url =
jar:file:/Applications/gradle-1.0-milestone-1/lib/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
:: resolving dependencies :: #blabla;0.0.1
confs: [grammarCompile]
found org.antlr#antlr;3.1 in MavenRepo
:: resolution report :: resolve 161ms :: artifacts dl 0ms
-
| | modules || artifacts
|
| conf | number| search|dwnlded|evicted||
number|dwnlded|
-
| grammarCompile | 1 | 0 | 0 | 0 || 0 | 0
|
---
Caused by: : No public execute() in class org.antlr.Tool
at
org.apache.tools.ant.TaskAdapter.checkTaskClass(TaskAdapter.java:97)
at
org.apache.tools.ant.TaskAdapter.checkProxyClass(TaskAdapter.java:113)
at
org.apache.tools.ant.AntTypeDefinition.checkClass(AntTypeDefinition.java:263)
at
org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:614)
at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:239)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at
org.gradle.api.internal.project.ant.BasicAntBuilder.nodeCompleted(BasicAntBuilder.java:71)
at
org.gradle.api.internal.project.ant.BasicAntBuilder.doInvokeMethod(BasicAntBuilder.java:86)
at
org.gradle.api.internal.project.DefaultAntBuilder.super$3$invokeMethod(DefaultAntBuilder.groovy)
at
org.gradle.api.internal.project.DefaultAntBuilder.invokeMethod(DefaultAntBuilder.groovy:37)
at
build_44c1a83iunkoa3eoun162srvg$_run_closure4.doCall(/blabla/build.gradle:24)
at
org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:444)
at
org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:432)
at
org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:58)
---
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] gradle antlr3
For integrating with big systems like Antlr, my general opinion is
that it's better to have parallel plugins since configuration options
are likely to change, and people aren't likely to want to have a
surprise upgrade—just because they update the plugin, they don't
suddenly want to be using a new major version of Antlr.
~~ Robert.
On Sat, Apr 16, 2011 at 7:21 PM, Steve Ebersole st...@hibernate.org wrote:
Its much more toll friendly now. I wrote the Maven plugin support for
Antlr3 and it is much easier than the Antlr 2 support. The real question is
whether Gradle wants a single plugin to support both versions. That is much
tougher.
On 04/16/2011 04:55 PM, Robert Fischer wrote:
Looks like they changed the API on you. Going to have to figure out
the new Ant task class name.
~~ Robert.
On Sat, Apr 16, 2011 at 4:30 PM, Marko Bauhardtm...@101tec.com wrote:
hi all.
i'm using gradle 1.0 milestone-1.
as i understand gradle's antlr plugin works with antlr2. i tried to
configure gradle to use anltr3.
but i'm getting this exception (see below)
what i have todo to that gradle is using antlr3?
any hints?
thanks
marko
---
configurations {
grammarCompile
}
dependencies {
grammarCompile group: 'org.antlr', name: 'antlr', version: '3.1',
transitive:false
compile group: 'org.antlr', name: 'antlr-runtime', version: '3.1',
transitive:false
testCompile group: 'junit', name: 'junit', version: '4.+'
}
task generateGrammarSources {
generatedDir = new File(project.buildDir.toString() +
'/generated-src/')
generatedDir.mkdirs()
ant.taskdef(name: 'antlr3', classname: 'org.antlr.Tool', classpath:
configurations.grammarCompile.asPath)
ant.antlr3(target: 'src/main/antlr/Calculator.g', outputdirectory:
'build/generated-src/')
}
---
:: loading settings :: url =
jar:file:/Applications/gradle-1.0-milestone-1/lib/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
:: resolving dependencies :: #blabla;0.0.1
confs: [grammarCompile]
found org.antlr#antlr;3.1 in MavenRepo
:: resolution report :: resolve 161ms :: artifacts dl 0ms
-
| | modules || artifacts
|
| conf | number| search|dwnlded|evicted||
number|dwnlded|
-
| grammarCompile | 1 | 0 | 0 | 0 || 0 | 0
|
---
Caused by: : No public execute() in class org.antlr.Tool
at
org.apache.tools.ant.TaskAdapter.checkTaskClass(TaskAdapter.java:97)
at
org.apache.tools.ant.TaskAdapter.checkProxyClass(TaskAdapter.java:113)
at
org.apache.tools.ant.AntTypeDefinition.checkClass(AntTypeDefinition.java:263)
at
org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:614)
at
org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:239)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at
org.gradle.api.internal.project.ant.BasicAntBuilder.nodeCompleted(BasicAntBuilder.java:71)
at
org.gradle.api.internal.project.ant.BasicAntBuilder.doInvokeMethod(BasicAntBuilder.java:86)
at
org.gradle.api.internal.project.DefaultAntBuilder.super$3$invokeMethod(DefaultAntBuilder.groovy)
at
org.gradle.api.internal.project.DefaultAntBuilder.invokeMethod(DefaultAntBuilder.groovy:37)
at
build_44c1a83iunkoa3eoun162srvg$_run_closure4.doCall(/blabla/build.gradle:24)
at
org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:444)
at
org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:432)
at
org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions(DefaultTaskExecuter.java:58)
---
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Steve Ebersole st...@hibernate.org
http://hibernate.org
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Create a top-level build that triggers build in each subproject?
task ci(dpeendsOn:getTasksByName(build, true)) ~~ Robert. On Mon, Apr 18, 2011 at 10:01 PM, Howard Lewis Ship hls...@gmail.com wrote: This seems like it should be easy. I have a top-level task: task continuousIntegration(dependsOn: ['build', 'aggregateJavadoc']) However, my top-level build.gradle doesn't define a build task (there's no Java code at the top level, just in the subprojects). What's the idiomatic way to create a top-level build target that, in effect, is dependent on each subproject's build task? -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Create a top-level build that triggers build in each subproject?
Don't you have to do subprojects*.tasks*.build these days? For some
reason, I've got it in my head that the direct project - task link
was broken.
~~ Robert.
On Tue, Apr 19, 2011 at 12:08 AM, Adam Murdoch
adam.murd...@gradleware.com wrote:
On 19/04/2011, at 12:01 PM, Howard Lewis Ship wrote:
This seems like it should be easy.
I have a top-level task:
task continuousIntegration(dependsOn: ['build', 'aggregateJavadoc'])
However, my top-level build.gradle doesn't define a build task
(there's no Java code at the top level, just in the subprojects).
What's the idiomatic way to create a top-level build target that, in
effect, is dependent on each subproject's build task?
You can do something like this:
task build { dependsOn subprojects*.build }
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Create a top-level build that triggers build in each subproject?
You could have at least gotten to my solution by checking out the API JavaDoc on Project. ~~ Robert. On Tue, Apr 19, 2011 at 1:26 PM, Jason Porter lightguard...@gmail.com wrote: On Tuesday, April 19, 2011, Howard Lewis Ship hls...@gmail.com wrote: Thanks! This seems to be working: task continuousIntegration(dependsOn: [subprojects.build, 'aggregateJavadoc']) That's very tight and clean ... I'm just a bit daunted because I'm not sure how I would have found that without asking on the list. Unfortunately there are all kinds of tricks like that which are not documented save the list :( On Tue, Apr 19, 2011 at 5:13 AM, Peter Niederwieser pnied...@gmail.com wrote: Robert Fischer wrote: Don't you have to do subprojects*.tasks*.build these days? For some reason, I've got it in my head that the direct project - task link was broken. subprojects.build is enough (no .tasks, no *'s). -- Peter Niederwieser Developer, Gradle http://www.gradle.org Trainer Consultant, Gradleware http://www.gradleware.com Creator, Spock Framework http://spockframework.org -- View this message in context: http://gradle.1045684.n5.nabble.com/Create-a-top-level-build-that-triggers-build-in-each-subproject-tp4312246p4313109.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Execute command line task?
If you need help developing the plug-in, feel free to drop me a line off-list. ~~ Robert. On Wed, Apr 20, 2011 at 11:02 AM, StormeHawke brian.trez...@intellidata.net wrote: Ronen Narkis wrote: I'm planning to give this plugin a go also, we are using tomcat 5.5 which is installed locally, ill try to make it work against it and let you know how it went Sounds great, let me know what you come up with ~B -- View this message in context: http://gradle.1045684.n5.nabble.com/Execute-command-line-task-tp4311284p4328320.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Gradle Plugins: JDepend, PMD, Findbugs
Looks good. I'm definitely interested in FindBugs, so I'll be taking a look soon. ~~ Robert. On Sat, May 14, 2011 at 12:53 PM, Andrew Oberstar ajobers...@gmail.com wrote: Hi all, I just released a few Gradle plugins for JDepend, PMD, and Findbugs. As far as I could tell (I may be wrong), there aren't any pure plugins for these tools. The code was mostly inspired by the samples in the Cookbook and the code-quality plugin. The implementations aren't that great, but they work for the most part. This is my first crack at this, so I welcome any comments, suggestions, or criticism. The JAR is available in Maven Central: group:'org.ajoberstar', name:'gradle-plugins', version:'0.1.0' You can see the source on Github: https://github.com/ajoberstar/gradle-plugins Andy Oberstar - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] up-to-date check for osgified jar task does not work
I opened a ticket for this already which contains a simple work-around:
http://issues.gradle.org/browse/GRADLE-1227
~~ Robert.
On Sun, May 15, 2011 at 5:27 AM, Ric Klaren rkla...@educator.eu wrote:
Hi,
On 14 May 2011 15:16, Rene Groeschke gra...@breskeby.com wrote:
We're actually working on the gpars build. I tried to get each up-to-date
check work properly when I noticed a bug for the jar tasks up-to-date check
when the osgi plugin is applied.
Is anybody aware of an convenient workarround for this issue:
http://issues.gradle.org/browse/GRADLE-1545
Ran into the same problem, I found a work around in the groovy build
scripts they filter the offending attribute out of the manifest (would
be nice if this was default behaviour):
http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/gradle/assemble.gradle
Relevant snippet:
commonOsgiManifest = {
// We exclude the Bnd-LastModified attribute as it always triggers
a rebuild without being really needed.
from(allManifest) {
eachEntry {details -
if (details.key == 'Bnd-LastModified') {
details.exclude()
}
}
}
}
Hope this helps,
Ric
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] WAR Overlay
I'd be inclined to have a three projects: one that built war #1, one
that built war #2, and one solely responsible for merging the two
using something like:
war {
from zipTree(war1Project.war.archivePath)
from zipTree(war2Project.war.archivePath)
}
But I tend to prefer istinct subprojects over tasks/source sets/etc.,
and other people might suggest an alternative approach with a single
project and some configuration to wire things together.
~~ Robert.
On Wed, May 18, 2011 at 10:41 AM, mraccola mracc...@yahoo.com wrote:
I need to convert an existing build that uses WAR overlaying to merge the
contents of two web projects into one WAR. Think..one web project that has
some framework stuff and then another web project that contains stuff that
extends the framework stuff. The projects will both be modules in the same
multi-module Gradle build.
I think this should be fairly straight forward but I wanted to ask if there
are any best practices for implementing this before I get started. If
anyone has some script snippets that they can share that would also be
appreciated.
--
View this message in context:
http://gradle.1045684.n5.nabble.com/WAR-Overlay-tp4406652p4406652.html
Sent from the gradle-user mailing list archive at Nabble.com.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[gradle-user] Specifying dependency with osgi=bundle
Is there a way to specify an OSGi bundle as a dependency? This is a new feature in the most recent release of Ivy: https://ant.apache.org/ivy/history/trunk/osgi/osgi-mapping.html It'd be really nifty, because that enables us to pull bundles from OBRs. Does Gradle have any support for that yet, or should I open a ticket? ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] file.encoding System property (and maybe others?) not passed to Gradle Daemon
I think I already raised an issue for this, but I can't seem to access the JIRA from work (internet is pretty locked down here at the homeless shelter...). ~~ Robert. On Tue, Jun 14, 2011 at 7:39 PM, Luke Daley l...@ldaley.com wrote: I've experienced this too. I actually suspect there are other places as well where the encoding is not being handled correctly (one I can think of is POM generation). Please make sure you raise an issue for this issue with the daemon. You're right in that it should respect the environment options. On 15/06/2011, at 7:51 AM, David Fogel wrote: We've just recently switched to Gradle for building our various projects, and for the most part things are working pretty well. But we spent a few days trying to figure out why certain tasks in our build were messing up character encodings of our source files (which all start out as UTF-8). What we finally discovered is that when the Gradle Daemon is started (in org.gradle.launcher.DaemonConnector.java), it doesn't copy in any of the program or VM arguments from the originating gradle command, or the existing environment settings that are set using GRADLE_OPTS or JAVA_OPTS. Among other things, we had been setting GRADLE_OPTS to set the file.encoding Java system property. But when the Gradle Daemon executed our gradle builds, the JVM was set to use the platform default, which is, for instance, Mac Roman on Mac OS X. Obviously it isn't a great idea to rely on the platform default encoding, but we're calling into 3rd-party ant scripts from our builds (in this case to concatenate and compress javascript source files), and those ant scripts made use of tasks which used the platform default (for instance the LoadFile Ant task does this). I can see there's an argument against passing on command-line args from the gradle command to the Daemon, but shoulnd't the Daemon make use of environment settings like GRADLE_OPTS and JAVA_OPTS in a same way that the gradle shell command does? -Dave Fogel - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Uploading files over SCP.
Nifty. Thanks!
~~ Robert.
On Tue, Jun 14, 2011 at 9:56 PM, Luke Daley l...@ldaley.com wrote:
Hi all,
I was recently asked about moving arbitrary files over SCP with Gradle (note
that this is different to moving published artifacts which is already covered
in the manual), so I thought I'd post it to the list for posterity.
So say you need to publish a website over SCP, you can do something like…
// pull the wagon dependency into the build, there are multiple protocols
available
// http://maven.apache.org/wagon/wagon-providers/
buildscript {
dependencies {
classpath org.apache.maven.wagon:wagon-ssh:1.0-beta-7
}
}
// Some task to collect what is to be uploaded into one place
task generateSite(type: Sync) {
from «somewhere»
from «somewhere»
into $buildDir/site
}
// Use the wagon to upload the content
task uploadSite(dependsOn: generateSite) {
def rep = new org.apache.maven.wagon.repository.Repository(site,
scp://site.com/path/to/site)
def auth = new org.apache.maven.wagon.authentication.AuthenticationInfo()
auth.userName = «username»
auth.password = «password»
def wagon = new org.apache.maven.wagon.providers.ssh.jsch.ScpWagon()
wagon.connect(rep, auth)
generateSite.destinationDir.eachFile {
if (it.directory) {
wagon.putDirectory(it, it.name)
} else {
wagon.put(it, it.name)
}
}
}
Cheers.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] bug in dependsOn method?
That kind of granular control isn't really the Gradle paradigm. The Gradle paradigm is about expressing dependencies and relationships in artifacts (declarative), not laying out a set of instructions (imperative). ~~ Robert. On Fri, Jun 17, 2011 at 5:53 PM, phil swenson phil.swen...@gmail.com wrote: Ok, the reason I wanted this behavior is so I could have granular control of each task unless I ran the whole batch. But I will work around this. thanks On Fri, Jun 17, 2011 at 3:33 PM, Robert Fischer robert.fisc...@smokejumperit.com wrote: There's no guarantied ordering of dependencies. If localeGenerateArchives depends on localeGenerateResources, it should say so itself. ~~ Robert. On Fri, Jun 17, 2011 at 5:16 PM, phil swenson phil.swen...@gmail.com wrote: buildLanguagePackTask.dependsOn([localeExportMessages, localeGenerateResources, localeGenerateArchives]) I was wondering why my build was failing, turns out it's because dependency #3 is getting run before #2. Solutions? BTW, I'm on gradle 1.0 m3 - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: bug in dependsOn method?
If the order of dependsOn tasks is guarantied, you open up a whole can of worms with dependencies being in the wrong/conflicting order, or the inferred order from resources being in a different order. It's just not the right direction to head. It's just serious bad times. You're swimming against the stream in Gradle if you're wanting to do this: there are other ways to accomplish the same thing without opening this can of worms. If it's a human call, just have the person punch in both tasks at the command line. Or have one task which has the dependency, and one task which does not have the dependency. Read this thread, where I was talking about a similar kind of request: http://gradle.1045684.n5.nabble.com/Run-After-td2642739.html ~~ Robert. On Sat, Jun 18, 2011 at 10:26 AM, phil swenson phil.swen...@gmail.com wrote: well in this case it is fetching data from an external source (web service call). There is no way to know if it's up-to-date or not, it's a human judgement call. This issue would be solved if I could count on the order of buildLanguagePackTask.dependsOn([localeExportMessages, localeGenerateResources, localeGenerateArchives]) I will file a request. If gradle is going to allow me to specify multiple dependencies, why not work in the order specified? Or is it not that simple? On Fri, Jun 17, 2011 at 6:26 PM, Peter Niederwieser pnied...@gmail.com wrote: phil swenson wrote: Maybe not, but in my case why regenerate files when I don't need to? You should tell Gradle about the inputs and outputs of your tasks. Then it will skip up-to-date tasks automatically. -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Blog: http://pniederw.wordpress.com Twitter: @pniederw -- View this message in context: http://gradle.1045684.n5.nabble.com/bug-in-dependsOn-method-tp4500010p4500312.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Where's the time going?
Wouldn't that closure have to be resolved in order to do UP-TO-DATE
checking on that task? So it's before the execution of the task, at
least. It will be as soon as someone paid any attention to the input
to the jar task.
~~ Robert.
On Wed, Jun 22, 2011 at 4:51 PM, Szczepan Faber szcze...@gmail.com wrote:
The closure passed to from() method for sure is evaluated at execution
of the task. So it may be that it was eating up the time but surely
not the configuration phase time?
Cheers!
On Wed, Jun 22, 2011 at 6:39 PM, M A curious.attempt.bu...@gmail.com wrote:
Hi Adam,
Confirmed. It's this fragment that's eating all the time:
jar {
from {
dependencies.collect {
it.isDirectory() ? it : zipTree(it)
}
}
}
I was hoping that making the expression passed to jar.from a closure
would make it lazily evaluated. I don't think this configuration can
be moved to a doFirst. Perhaps I can move this to a task class and
keep my implicit input/output declarations? What would you do to
resolve this?
Cheers,
Merlyn
On Tue, Jun 21, 201 at 4:55 PM, Adam Murdoch
adam.murd...@gradleware.com wrote:
On 22/06/2011, at 8:58 AM, M A wrote:
Hi all,
My gradle build is eating almost 30 seconds even before it considers
executing any tasks. How do I best go about diagnosing the problem?
A common problem is accidentally resolving dependencies at configuration
time, rather than at execution time. This can make the configuration phase
quite slow, particularly if those dependencies include dynamic revisions or
snapshots.
The profiling report does not yet give you any information about how long
dependency resolution takes, or where in the build it happens. We do want to
add this at some point.
What you could do in the meantime is comment out all the dependencies
(temporarily, of course), and see if this has an effect on the execution
time for, say, 'gradle help'.
Cheers,
Merlyn
=== details
When I run this command:
gradle --profile tasks
Here's the output:
Summary
Total Build Time 33.494
Startup 1.268
Settings and BuildSrc 0.617
Loading Projects 0.539
Configuring Projects 28.697
Total Task Execution 1.649
When I run in debug mode
gradle -d tasks
Then I get 33890 lines of output, of which 33456 are IvyLoggingAdapter.
I noticed the log messages of the form took XX secs. 223 lines
mention secs. These are the ones that are 0.1 seconds or greater:
15:41:34.253 [DEBUG]
[org.gradle.initialization.ScriptEvaluatingSettingsProcessor] Timing:
Processing settings took: 0.665 secs
15:41:34.761 [DEBUG] [org.gradle.initialization.BuildLoader] Timing:
Loading projects took: 0.506 secs
15:41:40.091 [DEBUG] [org.gradle.configuration.BuildScriptProcessor]
Timing: Running the build script took 5.323 secs
15:41:40.860 [DEBUG] [org.gradle.configuration.BuildScriptProcessor]
Timing: Running the build script took 0.125 secs
15:41:41.031 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultSettingsConverter]
Timing: Ivy convert for resolve took 0.136 secs
15:41:42.976 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.moduleconverter.ResolveModuleDescriptorConverter]
Timing: Ivy convert for resolve took 1.328 secs
15:41:42.985 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.moduleconverter.PublishModuleDescriptorConverter]
Timing: Ivy convert for publish took 1.337 secs
15:41:45.892 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.moduleconverter.ResolveModuleDescriptorConverter]
Timing: Ivy convert for resolve took 1.046 secs
15:41:45.896 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.moduleconverter.PublishModuleDescriptorConverter]
Timing: Ivy convert for publish took 1.05 secs
15:41:47.291 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver]
Timing: Ivy resolve took 4.305 secs
15:41:47.406 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultIvyReportConverter]
Timing: Translating report for configuration configuration
':PATH:SOMEPROJECT' took 0.103 secs
15:41:49.120 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver]
Timing: Ivy resolve took 0.849 secs
15:41:50.230 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver]
Timing: Ivy resolve took 0.42 secs
15:41:51.287 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver]
Timing: Ivy resolve took 0.401 secs
15:41:52.599 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver]
Timing: Ivy resolve took 0.491 secs
15:41:53.646 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver]
Timing: Ivy resolve took 0.391 secs
15:41:54.909 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver]
Timing: Ivy resolve took 0.465 secs
15:41:56.088 [DEBUG]
[org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver]
Re: [gradle-user] Using Git as a local artifact repository
The fact that you're referring to the local Git repository (that's the, not a) sets off some warning bells for me. That terminology makes me suspect that you don't quite understand what Git is or how it works. And you really, *really* don't want source control sitting on top of your local Ivy cache — that'll just be a headache, especially when you decide to clear your cache or when updates happen. When you check out a Git project, you end up with files checked out onto the file system, just like any source control. So if that folder looks like an Ivy repository, you should be able to use it just by pointing a mavenRepo to it using a file:// URL. I'm not sure you really want Gradle pulling from remote Git repositories (even the default upstream), because you'll end up with merge issues and the like which are difficult to handle programmatically. When projects do that obnoxious re-release thing, then blow away the entry in your Ivy cache. Once that's done, you'll pull against a new version. But they really shouldn't do that. Another option is to check out the project into your project as a subproject, and to map it as a submodule using Git. I do this for Clojure for my programming language, since I want to be living always with the newest and greatest code. Then you can have Gradle build the other project and supply it as a dependency. ~~ Robert. On Fri, Jun 24, 2011 at 1:47 AM, Mike Mills purdah...@gmail.com wrote: Does anyone have any information on how to use Git as a local ivy repository or cache? I would like to be able to use Git as a local repository, and if the artefact is not there, then go to the next resolver as normal. However, I would like it so that if an artefact is retrieved elsewhere that the artefact is added into the local Git repository. This is akin to replacing the Gradle cache file with a Git repository with automatic commits to Git for NEW artefacts or version, and an error or confirmation should a REPLACEMENT jar be available for a particular version of a jar already downloaded. The advantage of this setup would be that any changes to artefacts would be tracked should things change and the confirmation would allow the user to be aware that things might break due to the replacement artefact. I have had on a couple of occasions externally sourced maven dependencies that have just changed. Ie version 1.1 has been re-released, different jar contents but reusing the same jar version. In maven this is a real issue, as anyone who has the old version in their repository builds against one version of the dependency, and new developers to the project get a different version. Is git a good way to achieve this and can it be integrated into gradle? Regards, Mike - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Names for sourceSets
Note that you will have to create the directories for 'test-manual' by
hand. That threw me when I first got started with Gradle.
~~ Robert.
On Fri, Jun 24, 2011 at 1:06 PM, John Murph jmurph@gmail.com wrote:
AFAIK, Gradle only automatically handles main and test (really, the
JavaBase plugin handles those). For your number 1 case, we use a directory
named test-manual and just add a new sourceSet for that directory. It's
not very hard, something like
sourceSet {
'test-manual'
}
something like that (the user's guide talks about this). This will give you
some tasks automatically, such as a compileTestManualJava task for instance.
--
John Murph
Automated Logic Research Team
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Ivy vs Gradle configurations
Oh, so the case is when you have an API jar, and instead of having an API jar which is a bunch of interfaces that you both share, there is just an implementation JAR which implements the given API. That's a broken design pattern. I believe it's out there, but that's really broken. ~~ Robert. On Wed, Jul 6, 2011 at 12:40 AM, cquinn carl.qu...@gmail.com wrote: If you declare the api libraru as 'compile', it will be inherited by 'runtime' and be transitively brought in to all downstream builds, including the final app's war or other archive. That could clash with the actual implementation library that the app or container might be providing, resulting in classpath problems. It seems like the current Gradle approach is to cancel out the unwanted transitive compile/runtime using the war task's providedCompile conf. But, if this is true, that seems like a bit of a kludge. Workable, but not optimal. -- View this message in context: http://gradle.1045684.n5.nabble.com/Ivy-vs-Gradle-configurations-tp4544242p4555689.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Gradle REPL?
If you create one, I'm sure it'd be a welcome addition. Until then, most of the API is accessible through the documentation (JavaDocs, GroovyDocs, write-up). If there's something particularly missing, let us know. ~~ Robert. On Mon, Jul 11, 2011 at 12:15 PM, Olivier Lefevre lefev...@yahoo.com wrote: I think it would be very worthwhile to create a Gradle REPL. Since groovy has one already that shouldn't be a major undertaking. -- O.L. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Mixed groovy and java code
I'm pretty sure you can put *.java files under /src/*/groovy and they will compile just fine. ~~ Robert. On Thu, Nov 17, 2011 at 12:46 PM, Alexander von Zitzewitz a.zitzew...@hello2morrow.com wrote: Hello, I am having a project with groovy and java sources, using gradle version 1.0 M4. Now some java classes depend on groovy classes and the other way around. When building from scratch the compileJava tasks fails, because it cannot find the groovy classes used by the Java classes and compileGroovy has not been executed yet. Is this a chicken-egg problem? How would I solve that? Thanks for any hep in advance. Best regards Alexander von Zitzewitz hello2morrow Inc. 1 (877) 294-6327 - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Mixed groovy and java code
That's not really keeping your source trees seperate...it's just pretending that they are in your file system while making them the same in Gradle itself. ~~ Robert. On Thu, Nov 17, 2011 at 1:54 PM, Carr, Brian M brianmc...@austin.utexas.edu wrote: If you want to keep your source trees separate, you may also add the following to your build.gradle: sourceSets.main.java.srcDirs = [] sourceSets.main.groovy.srcDirs = ['src/main/groovy', 'src/main/java'] sourceSets.test.java.srcDirs = [] sourceSets.test.groovy.srcDirs = ['src/test/groovy', 'src/test/java'] ___ Brian M. Carr Senior Software Engineer Identity Management, ITS Applications University of Texas at Austin V: 512-232-6419 F: 512-471-5746 brianmc...@austin.utexas.edu On Nov 17, 2011, at 12:26 PM, Alexander von Zitzewitz wrote: Thanks, that worked.. On Nov 17, 2011, at 1:06 PM, Robert Fischer wrote: I'm pretty sure you can put *.java files under /src/*/groovy and they will compile just fine. ~~ Robert. On Thu, Nov 17, 2011 at 12:46 PM, Alexander von Zitzewitz a.zitzew...@hello2morrow.com wrote: Hello, I am having a project with groovy and java sources, using gradle version 1.0 M4. Now some java classes depend on groovy classes and the other way around. When building from scratch the compileJava tasks fails, because it cannot find the groovy classes used by the Java classes and compileGroovy has not been executed yet. Is this a chicken-egg problem? How would I solve that? Thanks for any hep in advance. Best regards Alexander von Zitzewitz hello2morrow Inc. 1 (877) 294-6327 - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Best regards Alexander von Zitzewitz hello2morrow Inc. 1 (877) 294-6327 - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Problem building groovy test code
I, for one, like to keep my Groovy and Java stuff fairly separate. I use Groovy for a different level of my application than where I use Java (or Scala), and so it is nice that the default allows for the distinction. ~~ Robert. On Tue, Nov 22, 2011 at 2:32 AM, Peter Niederwieser pnied...@gmail.com wrote: David Kowis wrote Yeah, I ended up setting the CompileJava task to skip, and added the src/main/java to the groovy srcDir. Is this the ideal convention? Why not have the groovy plug in do this by default? I'm not sure which is the ideal convention, but the current convention is more flexible in that you can control which Java files are joint-compiled and which are passed directly to javac. -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: @pniederw -- View this message in context: http://gradle.1045684.n5.nabble.com/Problem-building-groovy-test-code-tp5012007p5012731.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] [ANN] Plugins: Compilers and Mirah (0.0.4 release for both)
The Compilers plugin (providing a base class for JVM compilers) as well as the Mirah plugin (providing a compiler for the JRuby-inspired, ultralight Mirah programming language) have both been released. More information in the README pages: https://github.com/RobertFischer/Gradle-Compiler-Plugins https://github.com/RobertFischer/Gradle-Mirah-Compiler ~~ Robert. Science tells us we are merely beasts, but we don't feel like that. We feel like angels trapped inside the bodies of beasts, forever craving transcendence. (VS Ramachandran, cognitive neuroscientist) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[gradle-user] Get at Artifacts?
Is there a handy way to get a handle on the artifacts that would be produced by uploadArchives? I'd like to use that for my ghUpload script as part of the GitHub development. (This is a stop-gap approach to defining a proper GitHub Deployer.) ~~ Robert. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Get at Artifacts?
That'll do. Thanks! Now, are those PublishArtifact instances or their containing set only properly configured after some point in the lifecycle, or can I just use them and go to town, and trust Gradle to do the rest? ~~ Robert. On Sun, Apr 22, 2012 at 8:04 PM, Peter Niederwieser pnied...@gmail.com wrote: `configurations.archives.artifacts/allArtifacts` will get you a SetPublishArtifact. Is this what you are looking for? -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: @pniederw -- View this message in context: http://gradle.1045684.n5.nabble.com/Get-at-Artifacts-tp5658131p5658144.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Get at Artifacts?
I'm defining the task like this:
task ghUpload(dependsOn:[configurations.archives]) {
...
}
But that isn't forcing the jar to be built. (In this case, I've got
the Java plugin installed.) Is there a trick I need to force that?
~~ Robert.
On Sun, Apr 22, 2012 at 8:28 PM, Peter Niederwieser pnied...@gmail.com wrote:
They are configured at configuration time (e.g. by the `java` plugin).
Plugins should use the usual mechanisms (`artifacts.all { ... }`, convention
mapping, `doFirst {}`, etc.) to cope with timing issues.
--
Peter Niederwieser
Principal Engineer, Gradleware
http://gradleware.com
Creator, Spock Framework
http://spockframework.org
Twitter: @pniederw
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Get-at-Artifacts-tp5658131p5658162.html
Sent from the gradle-user mailing list archive at Nabble.com.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Get at Artifacts?
Looks like this is working:
task ghUpload(dependsOn:[configurations.archives.allArtifacts]) {
...
}
Is this a bug? I'd expect configurations.archives to be functionally
equivalent to configuration.archives.allArtifacts.
~~ Robert.
On Mon, Apr 23, 2012 at 11:38 AM, Robert Fischer
robert.fisc...@smokejumperit.com wrote:
I'm defining the task like this:
task ghUpload(dependsOn:[configurations.archives]) {
...
}
But that isn't forcing the jar to be built. (In this case, I've got
the Java plugin installed.) Is there a trick I need to force that?
~~ Robert.
On Sun, Apr 22, 2012 at 8:28 PM, Peter Niederwieser pnied...@gmail.com
wrote:
They are configured at configuration time (e.g. by the `java` plugin).
Plugins should use the usual mechanisms (`artifacts.all { ... }`, convention
mapping, `doFirst {}`, etc.) to cope with timing issues.
--
Peter Niederwieser
Principal Engineer, Gradleware
http://gradleware.com
Creator, Spock Framework
http://spockframework.org
Twitter: @pniederw
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Get-at-Artifacts-tp5658131p5658162.html
Sent from the gradle-user mailing list archive at Nabble.com.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Get at Artifacts?
Thanks for the tip. I'll head that way with the code: what you're
seeing is iterative development at work.
~~ Robert.
On Tue, Apr 24, 2012 at 8:07 AM, Luke Daley luke.da...@gradleware.com wrote:
On 23/04/2012, at 10:43 AM, Robert Fischer wrote:
Looks like this is working:
task ghUpload(dependsOn:[configurations.archives.allArtifacts]) {
…
}
You should rewrite your upload task to accept a FileCollection parameter, and
annotate that parameter with @InputFiles.
say…
class GhUpload extends DefaultTask {
@InputFiles
FileCollection artifacts
…
}
then…
task ghUpload(type: GhUpload) {
artifacts = configurations.archives.allArtifacts
}
Gradle will then infer/manage the dependencies for you.
Is this a bug? I'd expect configurations.archives to be functionally
equivalent to configuration.archives.allArtifacts.
It's not a bug, but more of a quirk of configurations modelling incoming
(dependencies) outgoing (artifacts) right now (which is an Ivy hangover).
In the way you're using it, configurations.archives is like saying
configurations.archives.dependencies
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] gradle use case I haven't seen an example for
Isn't this why a loving and benevolent God invented wget? Or is there some inconsistency that I'm not aware of? ~~ Robert. On Thu, Apr 26, 2012 at 11:15 AM, Roger Studner rstud...@gmail.com wrote: I have an ivy repo and use a sort of ugly/hackish ant file to pull things from maven central and then publish them to my own ivy repo I'd like to do this with gradle, but have no idea where to start.. obviously I can pull down the dependencies/comppile etc etc with gradle.. i've just never tried to make a task to pull something down and then publish it to another repo anyone :)? Thanks, Roger - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] gradle use case I haven't seen an example for
Ah. Got it. So there is a distinction you're concerned about. I'd think you could somehow pipe configurations.compile into configurations.archives and then use the standard install provided by the Maven plugin. Although that'll probably give you Pom files, which aren't exactly Ivy files. ~~ Robert. On Thu, Apr 26, 2012 at 2:49 PM, Roger Studner rstud...@gmail.com wrote: Well, the issue is making sure the proper artifacts all depedencies are pulled down.. and then the correct ivys/*.xml files are created/pushed for each artifact. wget (CURL!) is brilliant.. but doesn't solve the issue (even 1%) here. Roger On Apr 26, 2012, at 11:21 AM, Robert Fischer wrote: Isn't this why a loving and benevolent God invented wget? Or is there some inconsistency that I'm not aware of? ~~ Robert. On Thu, Apr 26, 2012 at 11:15 AM, Roger Studner rstud...@gmail.com wrote: I have an ivy repo and use a sort of ugly/hackish ant file to pull things from maven central and then publish them to my own ivy repo I'd like to do this with gradle, but have no idea where to start.. obviously I can pull down the dependencies/comppile etc etc with gradle.. i've just never tried to make a task to pull something down and then publish it to another repo anyone :)? Thanks, Roger - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Watching a File For Changes?
Commons-IO has this: https://commons.apache.org/io/apidocs/org/apache/commons/io/monitor/FileAlterationObserver.html Not sure if Gradle does. ~~ Robert. On Thu, Apr 26, 2012 at 4:39 PM, James Carr james.r.c...@gmail.com wrote: This feels like a silly question, but my gradle-fu is a little off since I've been in node.js land a lot more lately. Is there an easy way to watch file(s) for changes from gradle? I'm basically looking to make the embedded jetty/tomcat server restart when certain files (like the SQL files we use to init H2) change. Thanks, James - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [gradle-user] Can not resolve artifacts with dynamic revisions from Ivy repository
I was under the impression that Gradle did not support dynamic
revisions. It'd be really nice if it did!
~~ Robert.
On Wed, May 2, 2012 at 8:53 AM, Milan Papzilla papic...@googlemail.com wrote:
Hello,
I can not resolve artifacts with dynamic revision number from a Ivy
repository.
According to GRADLE-1789 this should work but when I try to resolve e.g
dependencies {
testCompile group: 'commons-beanutils', name: 'commons-beanutils',
version: '1.8.+', configuration:'default'
}
version: '1.8.+' fails while version: '1.8.3' is resolved correctly.
Also resolving against mavenCentral() is working correctly.
But whenever I use a dynamic version number with a Ivy repository it ends up
with:
org.gradle.api.artifacts.ResolveException: Could not resolve all
dependencies for configuration ':testCompile'.
[org.gradle.BuildExceptionReporter] at
org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.rethrowFailure(DefaultLenientConfiguration.java:51)
[org.gradle.BuildExceptionReporter] at
org.gradle.api.internal.artifacts.ivyservice.DefaultResolvedConfiguration.rethrowFailure(DefaultResolvedConfiguration.java:36)
[org.gradle.BuildExceptionReporter] at
org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyResolver$1.rethrowFailure(SelfResolvingDependencyResolver.java:81)
Caused by:
org.gradle.api.internal.artifacts.ivyservice.ModuleVersionNotFoundException:
Could not find any version that matches group:commons-beanutils,
module:commons-beanutils, version:1.8.+.
any suggestions ?
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Can-not-resolve-artifacts-with-dynamic-revisions-from-Ivy-repository-tp5680421.html
Sent from the gradle-user mailing list archive at Nabble.com.
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Re: Can not resolve artifacts with dynamic revisions from Ivy repository
Is there a syntax for them different from normal? foo:bar:[1.2.3,) doesn't work as of the last time I tried it. The OP states that foo:bar:1+ doesn't work. ~~ Robert. On Wed, May 2, 2012 at 2:09 PM, Peter Niederwieser pnied...@gmail.com wrote: Robert Fischer wrote I was under the impression that Gradle did not support dynamic revisions. It'd be really nice if it did! Dynamic revisions have always been supported (modulo some bugs). Just don't expect too much from them; from my experience, they can cause significant problems both with Ivy and Maven (performance penalty, semantics). For me and others that's reason enough not to use them. Chances are that if Spring and Hibernate get along without them, you will too. -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: @pniederw -- View this message in context: http://gradle.1045684.n5.nabble.com/Can-not-resolve-artifacts-with-dynamic-revisions-from-Ivy-repository-tp5680421p5681254.html Sent from the gradle-user mailing list archive at Nabble.com. - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
