Maven 2.x Ear Plugin

Jar files packed in the EAR file should also be added to application.xml or manifest.mf

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

While attempting to package an EAR for deployment on JBoss I have come across a (for me) major issue with the way this module works.

The issue is that there are a lot dependency jars included by default. That by itself isn't the problem. The problem is there is no way to include it in the classpath without defining all the dependencies again in the pom.xml for the EAR.

In an ideal world (for me) the jars would be an easy way to add the jars to the classpath since I want to include all I need in the EAR to make it as easy as possible to set up a depoyment environment.

There are really two options for how to do that. Either the jar files are added to the generated Manifest.MF file or else there should be a simple option to include all packed jar files to the application.xml. Both should (AFAIK) work in any standard-compliant container.

The option of putting all the jar files in APP-INF/lib only works on Weblogic.

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. MWAR-21 Need a way to include limited set of webapp's dependencies

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MWAR-9 WAR plugin should support minimal WARs for inclusion within an EAR

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Kristoffer Peterhansel added a comment -

After having read a bit more on my homework I should revise my suggestion to say that the manifest.mf files to add class-path information to should be the modules bundled in the ear. That of course makes it a bit more complicated to implement since it requires the module to reopen a jar file and modify (or create) the file in them before packaging them in the ear.

Simply adding an option to write all included jars (that are not ejb modules) into the application.xml is by far an easier method of doing this.

Show
Kristoffer Peterhansel added a comment - After having read a bit more on my homework I should revise my suggestion to say that the manifest.mf files to add class-path information to should be the modules bundled in the ear. That of course makes it a bit more complicated to implement since it requires the module to reopen a jar file and modify (or create) the file in them before packaging them in the ear. Simply adding an option to write all included jars (that are not ejb modules) into the application.xml is by far an easier method of doing this.
Hide
Permalink
Stéphane Nicoll added a comment -

Adding an entry in the manifest on the EAR won't work but I guess you've discovered it meanwhile.

Regarding your other option, only ejb-client module should be included in a <module> <java> entry (see the spec). We already discussed this issue on the user list. I know that JBoss won't complain about this, though.

What about 'profiles'. With the Weblogic profile, we would copy things over APP-INF/lib ; With JBoss, we wil include it in the application.xml.

Thoughts?

Show
Stéphane Nicoll added a comment - Adding an entry in the manifest on the EAR won't work but I guess you've discovered it meanwhile. Regarding your other option, only ejb-client module should be included in a <module> <java> entry (see the spec). We already discussed this issue on the user list. I know that JBoss won't complain about this, though. What about 'profiles'. With the Weblogic profile, we would copy things over APP-INF/lib ; With JBoss, we wil include it in the application.xml. Thoughts?
Hide
Permalink
Kristoffer Peterhansel added a comment -

Hmmm. I see. Never been much of a spec reader myself. But I guess either I've completely misunderstood how to use an appserver or it's another one of those areas where the Sun spec mostly solves theoretical issues and leaves the actual implementation and real world issues to the implementers.

Ah well. Since there is no standard way of doing this I suppose a method of adapting to specific targets would have to be in place. So some kind of profile system would be in order. Out of convenience I have only really looked at JBoss for now. But I guess I'll have to look around and see how I'd solve this issue on other servers to get a better idea if this is really the way to go then.

In the end I presume appservers are supposed to include the required 3rd party libs inside it's installation instead of in individual EAR files. But that don't really work too well with how Maven works. Unless we should completely stop packaging dependencies inside the EAR and instead install them in the server install. In that case a profile approach would definitely be needed as the install structure of the different servers are obviously very different.

Anyway this would move the responsibility of handling dependencies out of the EAR packager and into the domain of one of the deployment modules.

Show
Kristoffer Peterhansel added a comment - Hmmm. I see. Never been much of a spec reader myself. But I guess either I've completely misunderstood how to use an appserver or it's another one of those areas where the Sun spec mostly solves theoretical issues and leaves the actual implementation and real world issues to the implementers. Ah well. Since there is no standard way of doing this I suppose a method of adapting to specific targets would have to be in place. So some kind of profile system would be in order. Out of convenience I have only really looked at JBoss for now. But I guess I'll have to look around and see how I'd solve this issue on other servers to get a better idea if this is really the way to go then. In the end I presume appservers are supposed to include the required 3rd party libs inside it's installation instead of in individual EAR files. But that don't really work too well with how Maven works. Unless we should completely stop packaging dependencies inside the EAR and instead install them in the server install. In that case a profile approach would definitely be needed as the install structure of the different servers are obviously very different. Anyway this would move the responsibility of handling dependencies out of the EAR packager and into the domain of one of the deployment modules.
Hide
Permalink
Karthik added a comment -

There should atleast be a parameter in the EAR plugin which when set should not bundle the system dependency within the EAR.

Show
Karthik added a comment - There should atleast be a parameter in the EAR plugin which when set should not bundle the system dependency within the EAR.
Hide
Permalink
Stéphane Nicoll added a comment -

Karthik, I have removed your sub-task, it has nothing to do here. See MEAR-20 for your request.

Show
Stéphane Nicoll added a comment - Karthik, I have removed your sub-task, it has nothing to do here. See MEAR-20 for your request.
Hide
Permalink
Stéphane Nicoll added a comment -

OK ; Will include a new property includeLibrariesInApplicationXml

by default it's set to false. If it set to true, all third party libs are includes in the application.xml

Show
Stéphane Nicoll added a comment - OK ; Will include a new property includeLibrariesInApplicationXml by default it's set to false. If it set to true, all third party libs are includes in the application.xml
Hide
Permalink
Mark Chesney added a comment -

I thought Maven was supposed to "provide guidelines for best practices development". This new property really seems like a hack. The entire Chapter 8 in the J2EE 1.4 spec (See http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf) is dedicated to J2EE assembly and packaging use cases which are required to be supported by any J2EE container. To acheive these use cases with Maven requires redundant, hackish, fragile configuration. Can we look at the big picture and set a Maven standard for J2EE packaging which covers these use cases?

Show
Mark Chesney added a comment - I thought Maven was supposed to "provide guidelines for best practices development". This new property really seems like a hack. The entire Chapter 8 in the J2EE 1.4 spec (See http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf ) is dedicated to J2EE assembly and packaging use cases which are required to be supported by any J2EE container. To acheive these use cases with Maven requires redundant, hackish, fragile configuration. Can we look at the big picture and set a Maven standard for J2EE packaging which covers these use cases?
Hide
Permalink
Stéphane Nicoll added a comment -

I agree with you. Personally, I would be in favor of deploying things in compliance with the Spec and Maven will allow that btw: most EJBs, WARs could have their manifest entry created at deployment time with transitive deps.

However, I am in favor of adding this property in dev environments. Upating the manifest of Jar files is really painful and takes time.

I know the spec, I have reminded this chapter many times on the users list.

Do you have any suggestion?

Show
Stéphane Nicoll added a comment - I agree with you. Personally, I would be in favor of deploying things in compliance with the Spec and Maven will allow that btw: most EJBs, WARs could have their manifest entry created at deployment time with transitive deps. However, I am in favor of adding this property in dev environments. Upating the manifest of Jar files is really painful and takes time. I know the spec, I have reminded this chapter many times on the users list. Do you have any suggestion?
Hide
Permalink
Stéphane Nicoll added a comment -

Mark, any suggestion for this use case?

Show
Stéphane Nicoll added a comment - Mark, any suggestion for this use case?
Hide
Permalink
Stéphane Nicoll added a comment -

If you use dependencies you should update the manifest of the ejb modules accordingly (Class-Path). This is the way recommended by the spec.

Show
Stéphane Nicoll added a comment - If you use dependencies you should update the manifest of the ejb modules accordingly (Class-Path). This is the way recommended by the spec.
Hide
Permalink
Steve Loughran added a comment -

Sun's belief that you should patch the EJB modules is bollocks, because it doesnt take in to account signed JAR files, does it?

On a brighter note while j2ee 1.5 spec doesnt come out and document it anywhere, there may a <library-directoy> element in the ear

http://docs.sun.com/app/docs/doc/819-3659/6n5s6m57h?a=view

This will point to the location of the library dir, and it appears to default to /lib if not set.

Now, if EAR files point it at APP-INF/lib you get the same settings for weblogic as for java5..

Of course, jboss4.x doesnt handle the 1.5 descriptor. There are some hints in its docs that it takes the APP-INF/lib dir, but I dont see it working for me.

Show
Steve Loughran added a comment - Sun's belief that you should patch the EJB modules is bollocks, because it doesnt take in to account signed JAR files, does it? On a brighter note while j2ee 1.5 spec doesnt come out and document it anywhere, there may a <library-directoy> element in the ear http://docs.sun.com/app/docs/doc/819-3659/6n5s6m57h?a=view This will point to the location of the library dir, and it appears to default to /lib if not set. Now, if EAR files point it at APP-INF/lib you get the same settings for weblogic as for java5.. Of course, jboss4.x doesnt handle the 1.5 descriptor. There are some hints in its docs that it takes the APP-INF/lib dir, but I dont see it working for me.
Hide
Permalink
Stéphane Nicoll added a comment -

No, so patching the EJB modules break signatures. That's one of the reason why I don't want to do it in the EAR plugin (but you should do so in the projeet building the EJB module)

Thanks for the link, it's interessting but JavaEE5 specifc for now.

Regarding APP-INF/lib it's a weblogic proprietary feature, it won't work on other app server.

Show
Stéphane Nicoll added a comment - No, so patching the EJB modules break signatures. That's one of the reason why I don't want to do it in the EAR plugin (but you should do so in the projeet building the EJB module) Thanks for the link, it's interessting but JavaEE5 specifc for now. Regarding APP-INF/lib it's a weblogic proprietary feature, it won't work on other app server.

People

  • Assignee:
    Stéphane Nicoll
    Reporter:
    Kristoffer Peterhansel
Vote (2)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: