Re: [gradle-user] Client module for custom ant tasks
filed: http://jira.codehaus.org/browse/GRADLE-527
I have now built my first ear with gradle 0.6.1! Still a lot to do in
updating all gradle files in all projects, but I can now use gradle again.
Are there any big breaking changes in the DSL in upcoming releases? I'm
trying to decide if I should skip over 0.6 on the CI engine since the people
who own the projects I building have less patience than I do for changes in
builds.
Thanks for the help!
Jerod
hdockter wrote:
On Jun 17, 2009, at 4:52 PM, JerodLass wrote:
Thanks, that worked. I don't have a good answer as to why I do that,
but it's
for using the ant task WsEjbDeploy. I declare the module and then,
later, I
refer to the configuration when I execute the task and it finds the
jar.
It's something I have been using for several gradle releases.
I'm getting a funny error now. It applies all of the plugins, which
is
good, but now on the line:
project.libs.archiveTasks.each {bundle -
I get an error:
Execution failed for task ':projectModule:libs'.
Cause: Could not find property 'archiveTasks' on task
':projectModule:libs'.
I still see this in the userguide in example 24.59.
This is a bug in the UG. Could you file a Jira?
Is there a new way to
do something with all archives?
Yes. For example:
task showJars {
tasks.withType(Jar).each { println it }
}
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
View this message in context:
http://www.nabble.com/Client-module-for-custom-ant-tasks-tp23983465p24095322.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] Project.subprojects iteration
Both Project.subprojects and Project.allprojects take a closure and use it to
configure the requested set of projects. Is there a good way to access the
project that is currently being configured from inside the closure?
The only way I saw to do this was to modify ConfigureUtil.configure to pass the
configured object to the closure as a parameter. Then you could do:
allprojects { nextProject-
// use nextProject
}
Does this seem like a good change to configure?
--
Steve Appling
Automated Logic Research Team
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Project.subprojects iteration
I was a little premature with my question. I can reference the delegate to get
to this. It still seems more obvious to use a closure parameter. This makes
both allprojects.each { closure } and allprojects { closure } work more
consistently.
Steve Appling wrote:
Both Project.subprojects and Project.allprojects take a closure and use
it to configure the requested set of projects. Is there a good way to
access the project that is currently being configured from inside the
closure?
The only way I saw to do this was to modify ConfigureUtil.configure to
pass the configured object to the closure as a parameter. Then you
could do:
allprojects { nextProject-
// use nextProject
}
Does this seem like a good change to configure?
--
Steve Appling
Automated Logic Research Team
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [gradle-user] Project.subprojects iteration
Doesn't project reference the current project as well?
Op 18 jun 2009 om 20:35 heeft Steve Appling sajaka...@appling.org
het volgende geschreven:\
I was a little premature with my question. I can reference the
delegate to get to this. It still seems more obvious to use a
closure parameter. This makes both allprojects.each { closure } and
allprojects { closure } work more consistently.
Steve Appling wrote:
Both Project.subprojects and Project.allprojects take a closure and
use it to configure the requested set of projects. Is there a good
way to access the project that is currently being configured from
inside the closure?
The only way I saw to do this was to modify ConfigureUtil.configure
to pass the configured object to the closure as a parameter. Then
you could do:
allprojects { nextProject-
// use nextProject
}
Does this seem like a good change to configure?
--
Steve Appling
Automated Logic Research Team
-
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] Project.subprojects iteration
Not in a subprojects { } or allprojects { } closure. It's a bit confusing,
and I'm hoping to look into a solution at some point. But for now, it's not
so straight-forward.
On Thu, Jun 18, 2009 at 3:01 PM, Levi Hoogenberg
levihoogenb...@gmail.comwrote:
Doesn't project reference the current project as well?
--
John Murph
Automated Logic Research Team
Re: [gradle-user] Project.subprojects iteration
Levi Hoogenberg wrote:
Are you sure? I'm fairly certain that I'm doing this (with a subprojects
closure) in a 0.6.1 build script.
Op 18 jun 2009 om 21:41 heeft John Murph jmurph@gmail.com
mailto:jmurph@gmail.com het volgende geschreven:\
Not in a subprojects { } or allprojects { } closure. It's a bit
confusing, and I'm hoping to look into a solution at some point. But
for now, it's not so straight-forward.
On Thu, Jun 18, 2009 at 3:01 PM, Levi Hoogenberg
mailto:levihoogenb...@gmail.comlevihoogenb...@gmail.com
mailto:levihoogenb...@gmail.com wrote:
Doesn't project reference the current project as well?
--
John Murph
Automated Logic Research Team
Levi, you are right. I feel silly now.
That is exactly how I wanted it to work. I thought I tried this in a previous
version and it didn't work (at least that will be my excuse).
--
Steve Appling
Automated Logic Research Team
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
