Exploded (unpacked) ear

Not sure I follow. If maven generates the MANIFEST entry itself, it does not contain stuff needed to deploy the EAR. If it's not generate it, then it's there.

What's the problem of using the working directory as an exploded view of the EAR?

I would also like this feature. you'll notice that if you do a "mvn compile" on an ear project, it will create an exploded ear in the target/ directory, but will not create a manifest file.

if you use "mvn compile package" then it WILL create a zipped up ear which DOES have the manifest file.

yeah yeah ok. I get that. But what's the whole point of having the MANIFEST.MF file in the exploded ear.

Is it actually used by the App server when it deploys the EAR?

I am not sure if the MANIFEST.MF file is used with an exploded ear. My JBoss 4.0.5.GA doesn't seem to find it a problem. But I don't know what the official JSR says about it.

But there are more reasons to having an unpack option.
1. I would need to set the workDirectory property because the default workdirectory doesn't add the .ear on the end of the name. If I set the workDirectory then I lose the ability that the version is automatically added to the name.
2. The .ear file gets generated for nothing. If I want an unpacked ear directory then I probably don't need an .ear file.
3. I want the ear directory to be created in a different directory then the target directory. For instance in my jboss deploy directory so that I don't need to copy it manually. It just feels wrong to put the workDirectory there.
4. The workDirectory isn't meant to be used as an exploded ear. I can't depend on it to behave the same in future versions.

I am pretty sure the application server does not care at all if a manifest is not present.

Regarding your questions:

1. uh? /opt/jboss/server/default/deploy/$ {pom.artifactId}

   -$

   {pom.currentVersion}

   .ear

2. True but then work directory should be the same or the unpack goal should copy everything over the "exploded directory"
3. Why?
4. Yes it is. The EAR plugin is designed to build the EAR in this directory.

I can add an ear:exploded goal but I am not sure it will help.

Please provide more details, use case, etc and I will add the functionnality for sure if it makes sense. For now, I don't really see a problem.

Thanks for your quick comment.

Ok, maybe it isn't really needed. I see know that my points weren't that great... The only advantage that a separate option would have is that it would be clearer and easier for users to generate exploded ears (with the right name and such).

I don't think that a separate goal would bring something. I was thinking more in the line of a configuration option. If set to true then the .ear file wouldn't get generated and the workDirectory would get the name from the finalName configuration option (or something like that).

I understand.

Unfortunately, the default goal could not make this since it needs to generate an artifact and the finalName would clash.

If we want an exploded form, we need a separate goal (see the war plugin for an example).

Let me know what you think.

Ok, I can live with that.

Would be really great if you implement that.

Hi
Any progress on implementing the new goal like you did for war. it seems to be a problem for many with no solution. I am here after googling everywhere to find this.

I have zero time for this at the moment, sorry.

I guess the right thing to do on this case is to use the unpack goal of the maven-dependency-plugin.

You can configure it on the verify or install phase and set outputDirectory to the the desired place.

What do you think?

I tend to think that it is the best option indeed.

using the maven dependency plugin for this is not the perfect solution, because the dep. plugin can only fetch artifacts from the repository. this means that trying to add an exploded-ear-unpack execution to the package phase (where it logically belongs, just after ear:ear) would result in the previous build of the ear being exploded (since the new one will only be copied into the repository at the install phase).
this forces me to bind the unpack-ear to the install phase, which might create problems (since im not aware of any way to guarentee the unpack runs after the artifact was installed to the repository)