task execution context

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

task execution context

JerodLass
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
Reply | Threaded
Open this post in threaded view
|

Re: task execution context

JerodLass
I had been using a tempdir variable to deploy the ejb, which has to end up copied into a modules directory.  This worked once, but on the next ejb project it failed on an error like the one given.  I assumed this was an issue of variable redeclaration, but I don't know how to get around it.

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
Reply | Threaded
Open this post in threaded view
|

Re: task execution context

JerodLass
In reply to this post by JerodLass
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
Reply | Threaded
Open this post in threaded view
|

Re: task execution context

hans_d
Administrator
Hi Jerod,

On Jul 17, 2008, at 6:18 PM, JerodLass wrote:

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

We will keep an eye on this. Right now if you don't say project.x in  
your closure but x, x is resolved against the project object of the  
top level project. Sometimes this is what you want, other times not.  
Than you have to be more specific.

- Hans

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

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





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

    http://xircles.codehaus.org/manage_email