Nabble - gradle-user

Re: conditional artifact publication

2009-11-26T12:59:40Z

Ross Black wrote:

> Hi,
>
> Is there a way to conditionally add an artifact to a configuration,
> where the condition is evaluated at runtime?
> eg. I only want to add an artifact if a specific directory exists.
>
> I was hoping the following would work (but it does not):
> ---
> project.configurations {
> api
> }
>
> Task apiTask = project.task('apiJar', type: Jar, dependsOn:
> 'classes') {
> fileSet(dir: project.apiClassesDir)
> }
> apiTask.onlyIf {project.apiClassesDir.exists()}
>
> project.artifacts {
> api apiTask
> }
> ---
>
> The apiJar task correctly only generates the jar if the directory
> exists, but the artifact handler always expects that the file
> specified by the apiJar task exists even if the task has not run.
>
> Is there some other way to achieve this?
>

Not really. Could you add a JIRA issue for this?

I can't think of a good work-around, either. Is it possible to figure
out at configuration time whether the api jar is needed?

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Java heap space during uploadArchives execution

2009-11-26T09:39:08Z

Change your max heap size via GRADLE_OPTS

~~ Robert.

Erwan.LACOSTE@... wrote:

>
> Hi all,
>
> I'm facing a Java heap space during the upload of my files to Maven.
> I've looked into the mailing list, but the only matching problems
> actually come from the compiler. Here the execution of the task is in
> error:
>
> Caused by: org.gradle.api.GradleException: Could not publish
> configurations [configuration 'archives'].
> at
> org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.publish(ErrorHandlingIvyService.java:44)
>
> at
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.publish(DefaultConfiguration.java:194)
>
> at org.gradle.api.tasks.Upload.upload(Upload.java:57)
> at org.gradle.api.DefaultTask.invokeMethod(DefaultTask.groovy)
> at
> org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23)
> at
> org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:125)
>
> at
> org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:123)
>
> at
> org.gradle.api.internal.AbstractTask.doExecute(AbstractTask.java:257)
> at
> org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:222)
> ... 11 common frames omitted
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:338)
> at
> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:305)
> at
> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:267)
> at
> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:238)
> at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:143)
> at
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(LightweightHttpWagon.java:148)
>
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244)
>
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160)
>
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80)
>
> at
> org.apache.maven.artifact.ant.DeployTask.doExecute(DeployTask.java:117)
> at
> org.gradle.api.internal.artifacts.publish.maven.deploy.CustomDeployTask.doExecute(CustomDeployTask.java:42)
>
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:665)
>
> at
> org.gradle.api.internal.artifacts.publish.maven.deploy.AbstractMavenResolver.execute(AbstractMavenResolver.java:186)
>
> at
> org.gradle.api.internal.artifacts.publish.maven.deploy.AbstractMavenResolver.commitPublishTransaction(AbstractMavenResolver.java:178)
>
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:263)
> at
> org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyPublisher.publish(DefaultIvyDependencyPublisher.java:62)
>
> at
> org.gradle.api.internal.artifacts.ivyservice.DefaultIvyService.publish(DefaultIvyService.java:127)
>
> at
> org.gradle.api.internal.artifacts.ivyservice.ShortcircuitEmptyConfigsIvyService.publish(ShortcircuitEmptyConfigsIvyService.java:61)
>
> at
> org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.publish(ErrorHandlingIvyService.java:42)
>
> at
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.publish(DefaultConfiguration.java:194)
>
> at org.gradle.api.tasks.Upload.upload(Upload.java:57)
>
> Any ideas? Trying :
>
> uploadArchives {
> (…)
> options.fork(memoryMaximumSize: '512m')
> }
>
> Didn't work for me…
>
> Thanks in advance.
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Java heap space during uploadArchives execution

2009-11-26T09:37:54Z

Java heap space during uploadArchives execution

Hi all,

I'm facing a Java heap space during the upload of my files to Maven. I've looked into the mailing list, but the only matching problems actually come from the compiler. Here the execution of the task is in error:

Caused by: org.gradle.api.GradleException: Could not publish configurations [configuration 'archives'].
at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.publish(ErrorHandlingIvyService.java:44)

        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.publish(DefaultConfiguration.java:194)
        at org.gradle.api.tasks.Upload.upload(Upload.java:57)
        at org.gradle.api.DefaultTask.invokeMethod(DefaultTask.groovy)
        at org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23)
        at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:125)

at org.gradle.api.internal.project.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:123)

        at org.gradle.api.internal.AbstractTask.doExecute(AbstractTask.java:257)
        at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:222)
        ... 11 common frames omitted
Caused by: java.lang.OutOfMemoryError: Java heap space
        at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:338)
        at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:305)
        at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:267)
        at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:238)
        at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:143)
        at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(LightweightHttpWagon.java:148)
        at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244)
        at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160)
        at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:80)
        at org.apache.maven.artifact.ant.DeployTask.doExecute(DeployTask.java:117)
        at org.gradle.api.internal.artifacts.publish.maven.deploy.CustomDeployTask.doExecute(CustomDeployTask.java:42)
        at org.apache.maven.artifact.ant.AbstractArtifactTask.execute(AbstractArtifactTask.java:665)
        at org.gradle.api.internal.artifacts.publish.maven.deploy.AbstractMavenResolver.execute(AbstractMavenResolver.java:186)

at org.gradle.api.internal.artifacts.publish.maven.deploy.AbstractMavenResolver.commitPublishTransaction(AbstractMavenResolver.java:178)

at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:263)
at org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyPublisher.publish(DefaultIvyDependencyPublisher.java:62)

at org.gradle.api.internal.artifacts.ivyservice.DefaultIvyService.publish(DefaultIvyService.java:127)
at org.gradle.api.internal.artifacts.ivyservice.ShortcircuitEmptyConfigsIvyService.publish(ShortcircuitEmptyConfigsIvyService.java:61)

at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.publish(ErrorHandlingIvyService.java:42)

at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.publish(DefaultConfiguration.java:194)
at org.gradle.api.tasks.Upload.upload(Upload.java:57)

Any ideas? Trying :

uploadArchives {
(…)
options.fork(memoryMaximumSize: '512m')
}

Didn't work for me…

Thanks in advance.

Downloading *-sources

2009-11-26T05:10:29Z

Hi,

Is there a way to tell Gradle to download the sources of the jar files as well? I looked at this thread: http://old.nabble.com/Dowloading-*-sources.jar-td22064471.html#a22064471, but it looks like Artifact is no longer there, and wondered if there is a better way to do this.

Cheers,
Shay

Re: Copy non java files into the target directory

2009-11-25T21:10:09Z

Just wanted to verify that this works, thanks for the help.

My eyes simply glanced over it (its late) ..., sorry.

Paul Speed-2 wrote:

Quote from the original response: "Gradle will ignore any files it finds
in the resource dirs which are also included in the java dirs (or groovy
or scala dirs, if appropriate)."

So you should be covered.
-Paul

Shay Banon wrote:
> Thanks!,
>
> I will try it, but won't it copy over the java files as well? Can I
> control the inclusion / exclusion for it?
>
> Shay
>
>
> Adam Murdoch-2 wrote:
>>
>>
>> Shay Banon wrote:
>>> Hi,
>>>
>>> What is the simplest way to configure gradle to copy non java files
>>> that
>>> exists within src/main/java or src/test/java into their respective target
>>> classes directory?
>>>
>>>
>> Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
>> will ignore any files it finds in the resource dirs which are also
>> included in the java dirs (or groovy or scala dirs, if appropriate).
>>
>> To do this, you can do something like:
>>
>> sourceSets.main.resources.srcDir 'src/main/java'
>> sourceSets.test.resources.srcDir 'src/test/java'
>>
>>
>> --
>> Adam Murdoch
>> Gradle Developer
>> http://www.gradle.org
>>
>>
>> ---------------------------------------------------------------------
>> 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: Copy non java files into the target directory

2009-11-25T20:59:16Z

My eyes simply glanced over it (its late) ..., sorry.

Paul Speed-2 wrote:

Quote from the original response: "Gradle will ignore any files it finds
in the resource dirs which are also included in the java dirs (or groovy
or scala dirs, if appropriate)."

So you should be covered.
-Paul

Shay Banon wrote:
> Thanks!,
>
> I will try it, but won't it copy over the java files as well? Can I
> control the inclusion / exclusion for it?
>
> Shay
>
>
> Adam Murdoch-2 wrote:
>>
>>
>> Shay Banon wrote:
>>> Hi,
>>>
>>> What is the simplest way to configure gradle to copy non java files
>>> that
>>> exists within src/main/java or src/test/java into their respective target
>>> classes directory?
>>>
>>>
>> Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
>> will ignore any files it finds in the resource dirs which are also
>> included in the java dirs (or groovy or scala dirs, if appropriate).
>>
>> To do this, you can do something like:
>>
>> sourceSets.main.resources.srcDir 'src/main/java'
>> sourceSets.test.resources.srcDir 'src/test/java'
>>
>>
>> --
>> Adam Murdoch
>> Gradle Developer
>> http://www.gradle.org
>>
>>
>> ---------------------------------------------------------------------
>> 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

[ANN] SmokejumperIT Gradle-Plugins 0.1

2009-11-25T15:47:39Z

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: Copy non java files into the target directory

2009-11-25T14:53:06Z

Quote from the original response: "Gradle will ignore any files it finds
in the resource dirs which are also included in the java dirs (or groovy
or scala dirs, if appropriate)."

So you should be covered.
-Paul

Shay Banon wrote:

> Thanks!,
>
> I will try it, but won't it copy over the java files as well? Can I
> control the inclusion / exclusion for it?
>
> Shay
>
>
> Adam Murdoch-2 wrote:
>>
>>
>> Shay Banon wrote:
>>> Hi,
>>>
>>> What is the simplest way to configure gradle to copy non java files
>>> that
>>> exists within src/main/java or src/test/java into their respective target
>>> classes directory?
>>>
>>>
>> Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
>> will ignore any files it finds in the resource dirs which are also
>> included in the java dirs (or groovy or scala dirs, if appropriate).
>>
>> To do this, you can do something like:
>>
>> sourceSets.main.resources.srcDir 'src/main/java'
>> sourceSets.test.resources.srcDir 'src/test/java'
>>
>>
>> --
>> Adam Murdoch
>> Gradle Developer
>> http://www.gradle.org
>>
>>
>> ---------------------------------------------------------------------
>> 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: Copy non java files into the target directory

2009-11-25T14:25:27Z

Thanks!,

I will try it, but won't it copy over the java files as well? Can I control the inclusion / exclusion for it?

Shay

Adam Murdoch-2 wrote:

Shay Banon wrote:
> Hi,
>
> What is the simplest way to configure gradle to copy non java files that
> exists within src/main/java or src/test/java into their respective target
> classes directory?
>
>

Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
will ignore any files it finds in the resource dirs which are also
included in the java dirs (or groovy or scala dirs, if appropriate).

To do this, you can do something like:

sourceSets.main.resources.srcDir 'src/main/java'
sourceSets.test.resources.srcDir 'src/test/java'

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Copy non java files into the target directory

2009-11-25T14:22:02Z

Shay Banon wrote:
> Hi,
>
> What is the simplest way to configure gradle to copy non java files that
> exists within src/main/java or src/test/java into their respective target
> classes directory?
>
>

Add 'src/main/java' and 'src/test/java' as resource directories. Gradle
will ignore any files it finds in the resource dirs which are also
included in the java dirs (or groovy or scala dirs, if appropriate).

To do this, you can do something like:

sourceSets.main.resources.srcDir 'src/main/java'
sourceSets.test.resources.srcDir 'src/test/java'

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Copy non java files into the target directory

2009-11-25T13:37:28Z

Yea, I know that this is a possibility. I simply don't like that structure. Is there a way to solve what I asked?

Philip Crotwell wrote:

If you put them in src/main/resources instead, then they are copied
automatically. Just make a parallel directory structure to reflect the
java packages they are now in.

Philip

On Wed, Nov 25, 2009 at 4:27 PM, Shay Banon <kimchy@gmail.com> wrote:
>
> Hi,
>
> What is the simplest way to configure gradle to copy non java files that
> exists within src/main/java or src/test/java into their respective target
> classes directory?
>
> Thanks,
> Shay
> --
> View this message in context: http://old.nabble.com/Copy-non-java-files-into-the-target-directory-tp26520594p26520594.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: Copy non java files into the target directory

2009-11-25T13:30:36Z

If you put them in src/main/resources instead, then they are copied
automatically. Just make a parallel directory structure to reflect the
java packages they are now in.

Philip

On Wed, Nov 25, 2009 at 4:27 PM, Shay Banon <kimchy@...> wrote:

>
> Hi,
>
> What is the simplest way to configure gradle to copy non java files that
> exists within src/main/java or src/test/java into their respective target
> classes directory?
>
> Thanks,
> Shay
> --
> View this message in context: http://old.nabble.com/Copy-non-java-files-into-the-target-directory-tp26520594p26520594.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

Copy non java files into the target directory

2009-11-25T13:27:46Z

Hi,

What is the simplest way to configure gradle to copy non java files that exists within src/main/java or src/test/java into their respective target classes directory?

Thanks,
Shay

Re: Creating multiple jars

2009-11-25T08:20:10Z

Thanks Adam, 2 more questions:

- Is there a way to merge a signed jar - I would need either to remove the signatures or recompute them ?
- How can I have this jar (with the modified classifier) uploaded together with the "regular" one ?

On Tue, Nov 24, 2009 at 4:08 AM, Adam Murdoch <a@...> wrote:

tog wrote:

Hi folks,

In my project I would like to create multiple jars:
- one containing only the classes of my project (classic targer)
- a second one containing all dependencies,

In the cookbook, it is said that I can do this:

jar.doFirst {
for(file in configurations.compile) {
jar.merge(file)
}
}

What is the best way to achieve this ?

You can add another jar task to build the fat jar:

task fatJar(type: Jar) {
dependsOn classes
from sourceSet.main.classesDir
classifier = 'all' // Give the jar a different name
doFirst { task->

for(file in configurations.compile) {
task.merge(file)
}
}
}

Clone the jar task ?

Do something like a :
jar.doLast{
jar.copy(jar-minimal.jar)
for(file in configurations.compile) {
jar.merge(file)
}
}

Thanks for your help

Guillaume

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

--
PGP KeyID: 1024D/69B00854 subkeys.pgp.net

http://cheztog.blogspot.com

RE: Deploying to Maven

2009-11-25T06:24:50Z

Thanks for the answers Hans.

As promissed, I created a page inside the examples section of Gradle's Confluence. I cover there not only the Maven deploy part, but also environment configuration, which I started to speak about earlier this year.

For all of you who are interested in the problems raised by this topic, please have a look here for some answers:

http://docs.codehaus.org/display/GRADLE/complete+example+-+environment+managment+and+maven+deploy

But of course you're not gonna get out of here so easily as I have some other questions :) (most of them raised as TODOs in the previous link). I'll try to ask only the ones that would take me too long dig for, and I'll update the WIKI with the answer I get from myself eventually.

1) any SVN plugin? Anyway to Gradelly commit, tag or even branch something?

2) Anyway to change the project version number from the command line?

3) disable the disabling of tests. Meaning that skipping the tests would NOT be possible when running some definite tasks?

4) I noticed some behaviour with my multiproject tasks.

Here's roughly the structure:

ROOT/

SERVICE/

WEB-LAYER/

WAR-PROJECT/

WEB-LAYER is not a project, just a folder containing projects. When I run at the root "$gradle release", then the output would be:

:RASFF-core:compileJava
:RASFF-core:bind
[ant:echo] Binding with jibx...
:RASFF-core:processResources
:RASFF-core:classes
:RASFF-core:jar
:RASFF-core:uploadDefaultInternal
:RASFF-core:uploadArchives
:RASFF-core:release
:RASFF-web:compileJava ???????
:RASFF-web:processResources ????????
:RASFF-web:classes ??????????
:RASFF-web:jar SKIPPED ?????????
:RASFF-web:uploadArchives SKIPPED ???????
:RASFF-web:release ?????????
:RASFF-web:RASFF-web:compileJava
:RASFF-web:RASFF-web:processResources
:RASFF-web:RASFF-web:classes
:RASFF-web:RASFF-web:initConfiguration
no environment specified, skipping.
:RASFF-web:RASFF-web:war
version is: 2.2.0.DEV13-BUILD-6-SNAPSHOT
:RASFF-web:RASFF-web:uploadArchives
:RASFF-web:RASFF-web:release

As you see, I had to manually disable the 'RASFF-web' tasks. Why would Gradle run the tasks though I never declared RASFF-web as a project? This is not a blocker since I disabled the tasks, just a question of mine.

Thanks for your help,

Erwan

Re: Upload via SCP

2009-11-24T16:19:30Z

Okay, sorted it out: needed to set up a configuration and connect the
configuration a la the docs. Relying on 'classpath' is what was causing
the issue.

~~ 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

Re: Upload via SCP

2009-11-24T15:37:12Z

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:

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Upload via SCP

2009-11-24T14:54:31Z

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: Deploying to Maven

2009-11-24T04:29:55Z

On Nov 24, 2009, at 2:54 AM, <Erwan.LACOSTE@...> <Erwan.LACOSTE@...> wrote:

Hi all,
I'm trying to customize my Maven deploying tasks.
Here's what I would like to do in one task:
Generate the WAR file, generate the sources of the WAR project (including WEB-INF) and the sources of the depending project sources, upload to maven all 3 jar files (2 sources and WAR file).
Depending on command line arguments, the WAR release (and WAR source) could have a classifier.
I wish to block the release, if it's not a SNAPSHOT and the dependencies contains a SNAPSHOT.
I can do some of the things, but I'm stuck with others. I'll post all my work, so people can criticize if I'm too far from best practice, and give ideas to people having the same needs.
Root gradle:
subprojects {
    usePlugin 'java'
    version '2.2.0.DEV13-SNAPSHOT'
    task sourcesJar(type: Jar) {
        from sourceSets.main.allSource
        // wont work because of GRADLE-704

GRADLE-704 is fixed in trunk.

        classifier = 'sources'
    }
}
WAR gradle:
task initConfiguration << {
    // creates a ConfigSlurper containing all kinds of settings if an environment was set as a command line parameter.
    deployConfig = // whatever
}
war.doFirst {
    if (project.hasProperty('deployConfig') {
        // wont work because of GRADLE-704
        war.classifier = deployconfig.environment
        // Do some other things on the war
    }
}
sourcesJar {
    // How can I add the default WEB-INF directory to my sources?

from(projectDir) {

include "path_to_webinf"

}

// simply include "path_to_webinf" should do the job also. But there is a bug that prevents this from working ATM.

}
artifacts {
    archives war
    archives sourcesJar
}
uploadArchives {
    repositories.mavenDeployer {
        configuration = configurations.release // when I will need to deploy using WEB-DAV, configuration called 'release' is declared.
        repository(url: 'file://d:/erwan-dev/tmp/REPO')
        snapshotRepository(url: 'file://d:/erwan-dev/tmp/REPO-SNAPSHOT')
    }
}
def isSnapshotDependent() {
    def containsSnapshot = false
    // TODO I want to run the following only if i am releasing on the main repo.
    // should I check the presence of the string 'SNAPSHOT' in the projects version? How does the maven plugin knows that I'm uploading a SNAPSHOT or a main version?
    configurations.default.allDependencies.each { dep ->
        if (dep.version.indexOf('SNAPSHOT') > 0)
            containsSnapshot = true
    }
    return containsSnapshot
}

We use the Ant Maven tasks under the hood for deploying. The check the full artifact name for the 'SNAPSHOT' pattern and decide based on that whether to deploy to 'repository' or 'snapshotRepository'. But they don't make this information available.

task release(dependsOn: initConfiguration) << {
    // check that i'm not depending on a SNAPSHOT
    if (isSnapshotDependent()) {
        throw new GradleException("cannot release since dependencies contains a SNAPSHOT")
    }
    uploadArchives.execute() // is there a bug? Executing the task with the command line runs the 'war' task. Executing the same command from another task will not launch the 'war' task.
    // unless a parameter says NO
    uploadSources.execute() // knowing that I would wish for both this project and the "service" project sources to be uploaded. Maybe ServiceProject.uploadSources.execute() ?
}

What I would do is the following:

uploadArchives {

if (gradle.taskGraph.hasTask('release') {

if (isSnapshotDependent()) throw ...

}

...

}

task release{dependsOn: initConfiguration, uploadArchives) {

// do nothing at the moment.

}

uploadArchives will upload all artifacts that are only distinguished by the classifier.

As you see, I'm a little stuck until issue 704 is fixed (I will DL the latest trunk version soon).
My main concern is to create a task that will launch the 'uploadArchives' task. As I explained in a comment, right now launching 'uploadArchives' from another task wont trigger the 'war' task. Maybe this is a bug.

I don't think this is a bug. There are other, cleaner, ways to achieve this I think. Usually you shouldn't be forced to use the execute method at all.

I could get away from that by including the dependency manually of my custom task on 'war' and 'sourcesJar' tasks.
I wish there was an easy way to detect that a library version is a SNAPSHOT, including my own project.

I guess the Maven plugin could provide such a functionality. Could you file a Jira?

The documentation on Maven plugin is, how to say, evasive. Maybe I could post this draft on the wiki, so the community can bring their experience to it?

That would be excellent.

- Hans

Hans Dockter

Gradle Project Manager

http://www.gradle.org

Thanks in advance for the community help,
Erwan

conditional artifact publication

2009-11-24T04:14:07Z

Hi,

Is there a way to conditionally add an artifact to a configuration, where the condition is evaluated at runtime?
eg. I only want to add an artifact if a specific directory exists.

I was hoping the following would work (but it does not):
---
        project.configurations {
            api
        }

        Task apiTask = project.task('apiJar', type: Jar, dependsOn: 'classes') {
            fileSet(dir: project.apiClassesDir)
        }
        apiTask.onlyIf {project.apiClassesDir.exists()}

        project.artifacts {
            api apiTask
        }
---

The apiJar task correctly only generates the jar if the directory exists, but the artifact handler always expects that the file specified by the apiJar task exists even if the task has not run.

Is there some other way to achieve this?

Thanks,
Ross

Deploying to Maven

2009-11-24T00:54:54Z

Deploying to Maven

Hi all,

I'm trying to customize my Maven deploying tasks.

Here's what I would like to do in one task:

Generate the WAR file, generate the sources of the WAR project (including WEB-INF) and the sources of the depending project sources, upload to maven all 3 jar files (2 sources and WAR file).

Depending on command line arguments, the WAR release (and WAR source) could have a classifier.
I wish to block the release, if it's not a SNAPSHOT and the dependencies contains a SNAPSHOT.

I can do some of the things, but I'm stuck with others. I'll post all my work, so people can criticize if I'm too far from best practice, and give ideas to people having the same needs.

Root gradle:

subprojects {

usePlugin 'java'
version '2.2.0.DEV13-SNAPSHOT'

    task sourcesJar(type: Jar) {
        from sourceSets.main.allSource
        // wont work because of GRADLE-704
        classifier = 'sources'
    }
}

WAR gradle:

task initConfiguration << {
// creates a ConfigSlurper containing all kinds of settings if an environment was set as a command line parameter.
deployConfig = // whatever
}

war.doFirst {
    if (project.hasProperty('deployConfig') {
        // wont work because of GRADLE-704
        war.classifier = deployconfig.environment

// Do some other things on the war
}
}

sourcesJar {
// How can I add the default WEB-INF directory to my sources?
}

artifacts {
archives war
archives sourcesJar
}

uploadArchives {
repositories.mavenDeployer {
configuration = configurations.release // when I will need to deploy using WEB-DAV, configuration called 'release' is declared.

        repository(url: 'file://d:/erwan-dev/tmp/REPO')
        snapshotRepository(url: 'file://d:/erwan-dev/tmp/REPO-SNAPSHOT')
    }
}

def isSnapshotDependent() {
    def containsSnapshot = false
    // TODO I want to run the following only if i am releasing on the main repo.
    // should I check the presence of the string 'SNAPSHOT' in the projects version? How does the maven plugin knows that I'm uploading a SNAPSHOT or a main version?

    configurations.default.allDependencies.each { dep ->
        if (dep.version.indexOf('SNAPSHOT') > 0)
            containsSnapshot = true
    }
    return containsSnapshot
}

task release(dependsOn: initConfiguration) << {
    // check that i'm not depending on a SNAPSHOT
    if (isSnapshotDependent()) {
        throw new GradleException("cannot release since dependencies contains a SNAPSHOT")
    }
    uploadArchives.execute() // is there a bug? Executing the task with the command line runs the 'war' task. Executing the same command from another task will not launch the 'war' task.

// unless a parameter says NO
uploadSources.execute() // knowing that I would wish for both this project and the "service" project sources to be uploaded. Maybe ServiceProject.uploadSources.execute() ?

}

As you see, I'm a little stuck until issue 704 is fixed (I will DL the latest trunk version soon).
My main concern is to create a task that will launch the 'uploadArchives' task. As I explained in a comment, right now launching 'uploadArchives' from another task wont trigger the 'war' task. Maybe this is a bug. I could get away from that by including the dependency manually of my custom task on 'war' and 'sourcesJar' tasks.

I wish there was an easy way to detect that a library version is a SNAPSHOT, including my own project.

The documentation on Maven plugin is, how to say, evasive. Maybe I could post this draft on the wiki, so the community can bring their experience to it?

Thanks in advance for the community help,
Erwan

Re: Creating multiple jars

2009-11-23T14:38:42Z

tog wrote:

> Hi folks,
>
> In my project I would like to create multiple jars:
> - one containing only the classes of my project (classic targer)
> - a second one containing all dependencies,
>
> In the cookbook, it is said that I can do this:
>
> jar.doFirst {
> for(file in configurations.compile) {
> jar.merge(file)
> }
> }
>
> What is the best way to achieve this ?
>

You can add another jar task to build the fat jar:

task fatJar(type: Jar) {
dependsOn classes
from sourceSet.main.classesDir
classifier = 'all' // Give the jar a different name
doFirst { task->
for(file in configurations.compile) {
task.merge(file)
}
}
}

> Clone the jar task ?
>
> Do something like a :
> jar.doLast{
> jar.copy(jar-minimal.jar)
> for(file in configurations.compile) {
> jar.merge(file)
> }
> }
>
> Thanks for your help
>
> Guillaume
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

RE: big problem with SNAPSHOTS from Maven repo

2009-11-23T02:16:54Z

As I was stating before, the GRAS library was developped quite some time ago, with old versions of libraries. Due to client requests we could not just upgrade the whole thing. I'm still gonna try to upgrade everything and redifine the pom.xml.

But this wont solve the problem. It is not because the library is define as a module that Gradle should not look for the most recent version of it. This bug is now not as critical as it was before, but to me, it remains a bug.

Erwan

-----Original Message-----
From: Hans Dockter [mailto:mail@...]
Sent: Friday, November 20, 2009 9:11 PM
To: user@...
Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo

On Nov 20, 2009, at 3:43 PM, <Erwan.LACOSTE@...> wrote:

> Thank you,
>
> I was looking at it right now, and wandering how to modify my local ivydata file to revert and reproduce the issue.
>
> Indeed "module" dependency looks like the source of the problem. Since you say there is no simple to fix that, we'll try a workaround of our own, using non-module declaration.
>
> Gras is not build by Gradle (unfortunatly) but with Maven. Old technologies from the time our client was paranoid... That's what you get when you refuse progress...

Why do you need a module? Doesn't the pom.xml of gras contain the correct dependencies for gras?

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

>
> Anyway, we now have the explanation for the problem. I hope this topic will help explain all of the other SNAPSHOTS related issues of other users. Will you edit the JIRA or do you want me to do it?
>
> Thanks a lot for your support, keep on the good work,
> Erwan
>
> -----Original Message-----
> From: Hans Dockter [mailto:mail@...]
> Sent: Friday, November 20, 2009 3:36 PM
> To: user@...
> Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo
>
> Hi Erwan,
>
> On Nov 20, 2009, at 2:11 PM, <Erwan.LACOSTE@...> <Erwan.LACOSTE@...> wrote:
>
>> Thanks for pointing the JIRA.
>>
>> I don't know how you could reproduce this. Should we go on DEVELOPPER ML to discuss this? Maybe I can show you some Maven internal files of the maven snapshot repo, or even give you my build files. One thing is sure, my SNAPSHOT repo keeps track of the dates of release (that's the only way I was able to fix our release in time ;o)).
>>
>> But just so we are clear, here's the way I declare the dependency. Maybe the fact that I declare a module messes up the thing...
>>
>> compile module("eu.sanco.gras:gras:${grasVersion}") {
>> dependency("eu.sanco:saas:1.1.7")
>> dependency("commons-lang:commons-lang:2.3")
>> dependency("commons-net:commons-net:1.4.1")
>> dependency("org.apache.axis:axis:1.4")
>> dependency("org.apache.axis:axis-saaj:1.4")
>> dependency("org.apache.axis:axis-jaxrpc:1.4")
>> dependency("opensymphony:osworkflow:2.8.0")
>> dependency("opensymphony:propertyset:1.3")
>> dependency("org.safehaus.jug:jug:2.0.0:lgpl")
>> dependency("opensymphony:oscore:2.2.4")
>> dependency("javax.mail:mail:1.4")
>> }
>>
>> ${grasVersion} = '1.15.8-SNAPSHOT'
>
> Now I can reproduce your problem. Although they should, snapshots don't work with client modules at the moment. And there is no simple fix to this. This is related to the underlying Ivy which we use for resolving dependencies.
>
> What you can do is to use either an ivy.xml/pom.xml to describe your gras dependency. Or to flatten it, but give up transitive dependency handling by that. Something like: compile "eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", ....
>
> You could also use a variable for that:
>
> GRAS = ["eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", .... ]
> compile GRAS, "org.hibernate:hibernate:3.0"
>
> Bu then all dependencies are first level dependencies.
>
> Is gras build by Gradle?
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
>
>>
>>
>>
>> -----Original Message-----
>> From: Hans Dockter [mailto:mail@...]
>> Sent: Friday, November 20, 2009 12:13 PM
>> To: user@...
>> Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo
>>
>>
>> On Nov 20, 2009, at 11:41 AM, Rwanou wrote:
>>
>>>
>>> Hi all,
>>>
>>> The problem has already been raised here, and no real answer was given.
>>> Yesterday we faced a real problem in our deployment task, due mostly to
>>> internal processes, and also because of this bug of Gradle.
>>>
>>> Our application depends on a home library which is present on our home Maven
>>> Repo. This library is constantly updated, and we release regularly SNAPSHOT
>>> versions on our SNAPSHOT repo. As it was stated before, running the "gralde
>>> war" or any "build" task wont look for the latest SNAPSHOT version from the
>>> server. If ever your local gradle cache contains a SNAPSHOT version of the
>>> library, let's say the one from October 1st, and there was another SNAPSHOT
>>> release of this same library on November 1st, then gradle will NOT download
>>> the latest version, and still package the war with October 1st version.
>>>
>>> Until now our solution was to mail users and tell them to manually empty
>>> their cache. Gradle would then be forced to re-download the latest version.
>>> This is not acceptable as sometimes the users forget to do so. But the most
>>> problematic issue is that we are using Bamboo to CI our application, and we
>>> don't have access to the remote agent. We cannot purge the cache on the
>>> agent.
>>>
>>> The solution cannot be to add a parameter to the task. Fetching for the
>>> latest SNAPSHOT MUST be transparent.
>>>
>>> Is there anything worked out for this? Any Jira issue on this matter?
>>
>> There is an issue for this: http://jira.codehaus.org/browse/GRADLE-629
>>
>> The problem is that I can't reproduce it. I did attach a test project to this issue which uses snapshots. If I run this test project, always the newest snapshot is automatically picked up as you would expect. It would be awesome if you could send us a test build that reproduces this behavior. Otherwise it is very hard to figure out what is going on.
>>
>> - Hans
>>
>> --
>> Hans Dockter
>> Gradle Project Manager
>> http://www.gradle.org
>> ---------------------------------------------------------------------
>> 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
>
>

---------------------------------------------------------------------
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

Creating multiple jars

2009-11-22T09:13:45Z

Hi folks,

In my project I would like to create multiple jars:
- one containing only the classes of my project (classic targer)
- a second one containing all dependencies,

In the cookbook, it is said that I can do this:

jar.doFirst {
for(file in configurations.compile) {
jar.merge(file)
}
}

What is the best way to achieve this ?
Clone the jar task ?

Do something like a :
jar.doLast{
jar.copy(jar-minimal.jar)
for(file in configurations.compile) {
jar.merge(file)
}
}

Thanks for your help

Guillaume

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Recent change to Gradle

2009-11-22T00:52:31Z

On Sun, 2009-11-22 at 06:36 +1100, Adam Murdoch wrote:

>
> Russel Winder wrote:
> > The Gant build works fine with Gradle Wrapper as per used by Gradle
> > itself, so there is no panic. However using the latest Gradle, the
> > build results in:
> >
> > FAILURE: Could not determine which tasks to execute.
> >
> > * What went wrong:
> > Project 'gant' not found in project ':gant'.
> >
> > * Try:
> > Run with -t to get a list of available tasks.
> >
> > BUILD FAILED
> >
> > I think that this means that command line specification of sub-project
> > tasks has changed. Whereas I used to type:
> >
> > gradle clean gant:uninstall gant:install
> >
> > I now seem to have to type:
> >
> > gradle clean :gant:uninstall :gant:install
> >
> > Is this right? Did I just miss an announcement (very possible).
> >
> >
>
> The command-line usage shouldn't have changed (but might have
> accidentally). Are you running this from the root directory or a
> subdirectory? According to the error message, it is looking for project
> 'gant' in project 'gant', rather than the root project, for some reason.

From the project directory, not the subproject directory. Using -d I
get:

org.gradle.execution.TaskSelectionException: Project 'gant' not found in project ':gant'.
at org.gradle.execution.TaskNameResolvingBuildExecuter.findProject(TaskNameResolvingBuildExecuter.java:134) [gradle-core-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.execution.TaskNameResolvingBuildExecuter.doSelect(TaskNameResolvingBuildExecuter.java:72) [gradle-core-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.execution.TaskNameResolvingBuildExecuter.select(TaskNameResolvingBuildExecuter.java:41) [gradle-core-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.execution.DelegatingBuildExecuter.select(DelegatingBuildExecuter.java:46) [gradle-core-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.execution.DefaultBuildExecuter.select(DefaultBuildExecuter.java:52) [gradle-core-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.GradleLauncher.doBuildStages(GradleLauncher.java:185) [gradle-core-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.GradleLauncher.doBuild(GradleLauncher.java:128) [gradle-core-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.GradleLauncher.run(GradleLauncher.java:98) [gradle-core-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.launcher.Main.execute(Main.java:93) [gradle-launcher-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.launcher.Main.main(Main.java:42) [gradle-launcher-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]
at org.gradle.launcher.GradleMain.main(GradleMain.java:50) [gradle-launcher-0.9-20091121110334+0000.jar:0.9-20091121110334+0000]

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: Sorry, definite RTFM

2009-11-21T14:30:39Z

Hi, Hans!

Any news on the subject? I tried to find anything about it, but except of the open issue in Jira with a great, but lacking script found nothing.

Thanks!

Baruch.

hdockter wrote:

Hi James,

On Jan 27, 2009, at 4:22 PM, james_bromley wrote:

>
> Hi, thank you for your reply.
>
> I have since used the migration tool to generate gradle style
> dependencies
> from pom.xml (http://jira.codehaus.org/browse/GRADLE-154), but my
> hope was,
> when starting with a project that was already building in maven,
> with its
> dependencies articulated in the pom.xml, to be able to start running
> builds
> using gradle without having to migrate dependencies from one form to
> another
> beforehand.
>
> Then, as advantages of gradle become apparent, to migrate
> dependencies into
> gradle.
>
> But I feel it's valid to have dependencies declared in a pom or ivy
> file,
> but do the building using gradle. After all, it's the building and
> enhancing
> it that's the major problem with maven, not necessarily the dependency
> declaration....?
>
>
> Must be doable since gradle reads poms in maven style repos for
> transitive
> dependencies, so how to do so for primary dependencies?

>
>
> Sense or nonsense?

It is not possible at the moment but would make a lot of sense. This
is a planned feature and shouldn't be that much work. We want to
implement this in a way, so that you can use the pom/ivy.xml together
with the depedency declarations in the Gradle script.

- Hans

>
> James Bromley
>
>
> Szczepan Faber wrote:
>>
>> Hi,
>>
>> I'm not an expert but let me try to help you.
>>
>>> What i can't find is a way to say to gradle "use this pom.xml to
>>> find the
>>> dependencies when compiling".
>>
>> Gradle is a different build system and AFAIK you cannot declare
>> dependencies for your project using maven poms. You should specify
>> dependencies in build.gradle. BTW, under the hood, gradle uses IVY
>> for
>> dependency management.
>>
>>> dependencies
>>> {
>>> addMavenStyleRepo("tim-reg","file:///C:/Work/timreg/")
>>> }
>>
>> Again, I'm not an expert but above does not make much sense to me.
>> It's like you specify the source of dependencies but you don't
>> specify
>> any dependencies. The effect is that gradle doesn't put any
>> dependencies on the classpath. This is the reason of your compilation
>> errors.
>>
>> HTH,
>> Szczepan Faber
>>
>> On Thu, Jan 22, 2009 at 3:30 PM, james_bromley <james.bromley@and.co.uk
>> >
>> wrote:
>>>
>>> hi
>>>
>>> Am trying to setup my first project using gradle to build
>>> something that
>>> is
>>> already setup in Maven.
>>>
>>> What i can't find is a way to say to gradle "use this pom.xml to
>>> find the
>>> dependencies when compiling".
>>>
>>> i.e. instead of articulating my dependencies in the build.gradle,
>>> simply
>>> use
>>> the pom.xml i already have.
>>>
>>> This must be because I'm being stupid ;-) or have failed to read
>>> the docs
>>> properly.
>>>
>>> What i'm trying is this:
>>>
>>>
>>> defaultTasks "compile"
>>>
>>> usePlugin('war')
>>>
>>> targetCompatibility = '1.5'
>>> sourceCompatibility = '1.5'
>>>
>>> dependencies
>>> {
>>> addMavenStyleRepo("tim-reg","file:///C:/Work/timreg/")
>>> }
>>>
>>>
>>> where the file path supplied is the directory containing the project
>>> pom.xml, and the first parameter is the artifactId specified in
>>> the pom.
>>>
>>> I guess what i'm trying to point at isn't really a repository,
>>> just a
>>> pom.xml. The result of running the above is something like this:
>>>
>>>
>>> C:\Work\globalLibs\gradle-0.5.2\bin\gradle.bat
>>> :init
>>> :resources
>>> :compile
>>> C:\Work\timreg\src\main\java\uk\co\anm\controller
>>> \DataCaptureController.java:3:
>>> package org.springframework.web.servlet.mvc does not exist
>>> import org.springframework.web.servlet.mvc.SimpleFormController;
>>>
>>> ... etc, etc
>>>
>>> 35 errors
>>>
>>> Build failed with an exception.
>>> Run with -s or -d option to get more details. Run with -f option
>>> to get
>>> the
>>> full (very verbose) stacktrace.
>>>
>>> Build file 'C:\Work\timreg\build.gradle'
>>>
>>> Execution failed for task :compile.
>>> Cause: Compile failed; see the compiler error output for details.
>>>
>>> BUILD FAILED
>>>
>>>
>>> Thanks for your any help, and sorry for not finding this myself.
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Sorry%2C-definite-RTFM-
>>> tp21605223p21605223.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
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Sorry%2C-definite-RTFM-tp21605223p21687448.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
>
>

--
Hans Dockter
Gradle Project lead
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: [ANN] GitHub: RobertFischer/gradle-plugins

2009-11-21T14:29:55Z

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

Re: [ANN] GitHub: RobertFischer/gradle-plugins

2009-11-21T14:18:34Z

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?

Re: [ANN] GitHub: RobertFischer/gradle-plugins

2009-11-21T13:01:15Z

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?

~~ Robert.

Helmut Denk wrote:

> thanks robert for publishing your code.
>
> to make my plugin (i only have one atm) distributable,
> i build a jar and copy it to the lib/ dir of the gradle-distribution
> + add a line in plugins.properties.
>
> setup of an 'official' gradle-plugins project @hithub
> and definition of a ruleset for plugin-developers would
> probably be what's needed to kick off the eco-system
> for gradle-plugins.
>
> a minimalistik plugins-sdk may be a good idea too.
>
> have a successful time
>
>
> Robert Fischer wrote:
>
>> I'm starting to stash plugins over on GitHub at my gradle-plugins project:
>> http://github.com/RobertFischer/gradle-plugins
>>
>> README for more info:
>> http://github.com/RobertFischer/gradle-plugins/blob/master/README.md
>>
>> ~~ 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: Recent change to Gradle

2009-11-21T11:36:51Z

Russel Winder wrote:

> The Gant build works fine with Gradle Wrapper as per used by Gradle
> itself, so there is no panic. However using the latest Gradle, the
> build results in:
>
> FAILURE: Could not determine which tasks to execute.
>
> * What went wrong:
> Project 'gant' not found in project ':gant'.
>
> * Try:
> Run with -t to get a list of available tasks.
>
> BUILD FAILED
>
> I think that this means that command line specification of sub-project
> tasks has changed. Whereas I used to type:
>
> gradle clean gant:uninstall gant:install
>
> I now seem to have to type:
>
> gradle clean :gant:uninstall :gant:install
>
> Is this right? Did I just miss an announcement (very possible).
>
>

The command-line usage shouldn't have changed (but might have
accidentally). Are you running this from the root directory or a
subdirectory? According to the error message, it is looking for project
'gant' in project 'gant', rather than the root project, for some reason.

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: gradle stopped working with 'Could not select the default project for this build'

2009-11-21T10:52:14Z

Hi,

I just wanted to spend some more time to get my build running again.
Today it just worked. And I have changed nothing at all.
So I really have no clue why gradle was complaining about "No projects
in this build have project directory '/users/pvoss/myproject'."
although my working directory was "/Users/pvoss/myproject". I have no
clue where gradle was taking the lowercase /users from.

--Peter

On 20.11.2009, at 22:05, Peter Voss wrote:

> Hi Adam,
>
> right I have a case-insensitive file system (Mac). But where is the /
> users coming from? If I do a pwd the directory is
> /Users/pvoss/myproject
>
> Where is gradle taking the /users/pvoss/myproject from?
>
> Thanks,
> --Peter
>
> On 20.11.2009, at 20:37, Adam Murdoch wrote:
>
>>
>> If you're working on a machine with a case-insensitive file system
>> (windows, os x), double check that your working directory has the
>> correct case (eg should that '/users' below be '/Users' instead?)
>>
>>
>> Peter Voss wrote:
>>> Hi,
>>>
>>> I am really stuck now. I have used gradle successfully for a
>>> while, but it just stopped working with the following error message:
>>>
>>> >gradle eclipse
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * What went wrong:
>>> Could not select the default project for this build. No projects
>>> in this build have project directory '/users/pvoss/myproject'.
>>>
>>> * Try:
>>> Run with -s or -d option to get more details. Run with -S option
>>> to get the full (very verbose) stacktrace.
>>>
>>> BUILD FAILED
>>>
>>> Total time: 2.099 secs
>>>
>>> I think I have deleted ~/.gradle before. When I checkout the
>>> project on a different machine everything works fine. There also
>>> is an issue which seems to be related to this problem:
>>> http://jira.codehaus.org/browse/GRADLE-511
>>>
>>> Any ideas what I can do to get gradle running again?
>>>
>>> Thanks,
>>> --Peter
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> --
>> Adam Murdoch
>> Gradle Developer
>> http://www.gradle.org
>>
>>
>> ---------------------------------------------------------------------
>> 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: [ANN] GitHub: RobertFischer/gradle-plugins

2009-11-21T10:50:32Z

thanks robert for publishing your code.

to make my plugin (i only have one atm) distributable,
i build a jar and copy it to the lib/ dir of the gradle-distribution
+ add a line in plugins.properties.

setup of an 'official' gradle-plugins project @hithub
and definition of a ruleset for plugin-developers would
probably be what's needed to kick off the eco-system
for gradle-plugins.

a minimalistik plugins-sdk may be a good idea too.

have a successful time

Robert Fischer wrote:

I'm starting to stash plugins over on GitHub at my gradle-plugins project:
http://github.com/RobertFischer/gradle-plugins

README for more info:
http://github.com/RobertFischer/gradle-plugins/blob/master/README.md

~~ Robert.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Recent change to Gradle

2009-11-21T08:30:35Z

The Gant build works fine with Gradle Wrapper as per used by Gradle
itself, so there is no panic. However using the latest Gradle, the
build results in:

FAILURE: Could not determine which tasks to execute.

* What went wrong:
Project 'gant' not found in project ':gant'.

* Try:
Run with -t to get a list of available tasks.

BUILD FAILED

I think that this means that command line specification of sub-project
tasks has changed. Whereas I used to type:

gradle clean gant:uninstall gant:install

I now seem to have to type:

gradle clean :gant:uninstall :gant:install

Is this right? Did I just miss an announcement (very possible).

Thanks.

Don't you just love being at the bleeding edge ;-)

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

[ANN] GitHub: RobertFischer/gradle-plugins

2009-11-20T19:40:04Z

I'm starting to stash plugins over on GitHub at my gradle-plugins project:
http://github.com/RobertFischer/gradle-plugins

README for more info:
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: More Source Set Issues

2009-11-20T14:54:54Z

> 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