I was able to get around this problem by being more explicit, but somewhere
along the way the context is being thrown around. It would make more sense
to me for the project property to always be the project that is currently
executing in a task, but I imagine this is an easier concept than
implementation. Still, his is probably just an issue with multiple task
definitions (each with a corresponding project), and I have only run into it
a few times.
-Jerod
JerodLass wrote:
>
> I am defining tasks for certain specific subprojects through my top-level
> gradlefiles. I am trying to make a generic, useful top-level gradlefile
> so nobody else gets to use groovy, and one thing it does is detect if the
> project it an EJB project. If so, it declares the necessary source and
> resource variables as well as an ejbdeploy task. I have shortened it as
> follows:
>
> subprojects.each{project->
> if(project.isEJB){
> project.srcRootName = ejbModule
> project.createTask('ejbdeploy', dependsOn: 'libs'){
> ant {
> taskdef(name: "wsejbdeploy", classname:
> "com.ibm.websphere.ant.tasks.WsEjbDeploy", classpath:
> project.dependencies.antpath("wsanttasks"))
> wsejbdeploy(inputJar:
> project.buildDir.path+'/'+project.archivesBaseName+'-'+project.version+'.jar',
> classpath: path{
> fileset(dir: rootDir.path+"/$modulesDirPath"){include:
> name="**/*.jar"}
> fileset(dir: globalWasDir+'/lib'){include: name="**/*.jar"}
> fileset(dir: globalWasDir+'/java'){include: name="**/*.jar"}
> fileset(dir: earLib.path){include: name="**/*.jar"}
> },
> wasHome: globalWasDir,
> outputJar:
> ${project.projectDir.path}/$ejbTemp/${project.name}-${project.version}.jar",
> quiet:'false',
> trace:'true',
> failonerror:'true')
> }
>
> }
> }
>
> It's a bit sloppy, but when I run it on windows it's fine. On unix, I end
> up with:
>
> [wsejbdeploy] com.ibm.etools.ejbdeploy.IllegalFilenameException: Can not
> create file
> /builds/build/**/*.jar/EJBproject/ejbTemp/codesbenchEJB-g.1.0.jar.
>
> I'm wondering if this is a context problem, but obviously that's not a
> valid location. It should be coming from the outputjar attribute, but I
> don't know where it gets that front nonsense.
>
> Any thoughts?
>
> -Jerod
>
--
View this message in context:
http://www.nabble.com/task-execution-context-tp18496103p18512310.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
