Gradle Ear plugin generates wrong descriptor for JavaEE 1.4


(Andrey Adamovich) #1

The following configuration generates descriptor that contains ‘library-directory’ element, which is not defined by XSD for J2EE 1.4:

ear {

libDirName ‘APP-INF/lib’

deploymentDescriptor {

version = “1.4”

displayName = project.name

} }

If I omit libDirName, then libraries are put into ‘lib’ folder, not into ‘APP-INF/lib’ as required by WebLogic to which I deploy the EAR.

I’m trying to use withXml to fix, but in any case it seems that this behaviour is a bug since it generates an invalid descriptor.


(Peter Niederwieser) #2

The following configuration generates descriptor that contains ‘library-directory’ element, which is not defined by XSD for J2EE 1.4:

Thanks for pointing this out. I’ve created GRADLE-2785 for this.

If I omit libDirName, then libraries are put into ‘lib’ folder, not into ‘APP-INF/lib’ as required by WebLogic to which I deploy the EAR.

That’s why ‘libDirName’ is configurable. Some app servers use ‘APP-INF/lib’, others just ‘lib’. It’s not defined in the spec, and the Ear task/plugin is app server agnostic. App server specific support might be provided in the future.


(Andrey Adamovich) #3

Thanks for your reply Peter. I’m trying to construct withXml closure to fix the issue:

withXml { descriptor ->

descriptor.remove(descriptor.‘library-directory’)

}

But it gives me an error when it constructs:

  • What went wrong:

Could not copy application.xml to …

And application.xml in the build directory is empty file


(Andrey Adamovich) #4

Nevermind, the right code to fix it is:

withXml { provider ->

def descriptor = provider.asNode()

descriptor.remove(descriptor.‘library-directory’)

}


(Andrey Adamovich) #5

Another minor issue that I noticed is that in the docs it is mentioned that displayName defaults to project.name, but actually it’s not. It’s not set at all in the generated descriptor. The following line obviously fixes that:

displayName = project.name


(Peter Niederwieser) #6

At first sight, this looks like a bug in the ear plugin. We should have a look at this as part of the same JIRA issue.