WAR files take precedence over AMP files

[GoogleCodeExporter]

The way AMP processing works when creating an Alfresco extension
application (I also copied that functionality to my Share POM) does not
work.  The AMPs are extracted in the process-resources phase, then the WAR
(Alfresco web client or Share) is unpacked over it in the package phase. 
The result is that files in the AMP are overridden by files in the WAR. 
This is not correct.

I worked around this by unpacking the AMPs to
${project.build.directory}/work/amp and then adding that folder in the
webResources configuration for the WAR plugin.

Original issue reported on code.google.com by geis....@gmail.com on 14 Dec 2009 at 7:01

• Blocking: #38, #38

[GoogleCodeExporter]

IIRC file copying is handled via WAR overlays[1], which follows a first-win 
strategy.
I'll test it again and see if it's broken now.

[1] http://maven.apache.org/plugins/maven-war-plugin/overlays.html

Original comment by carlo.sciolla on 15 Dec 2009 at 12:49

[GoogleCodeExporter]

@Carlo: did you test this?

Original comment by colum...@gmail.com on 23 Feb 2010 at 6:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yep, tested and confirmed. The default binding to process-resources cause all 
the 
colliding files between the AMP and Alfresco WAR to be overwritten by the war 
plugin, 
which applies the first win strategy only for files coming from war overlays, 
not 
caring of what files were copied by other plugins.

Original comment by carlo.sciolla on 28 Feb 2010 at 3:09

[GoogleCodeExporter]

Ok so I guess we need to make this working as suggested by Ken, i.e. defining 
an external folder and then referring to it from the webResources config in the 
maven-war-plugin. @carlo: Do you have time to implement and test this? 

Original comment by colum...@gmail.com on 15 Nov 2011 at 5:22

• Added labels: Milestone-NextRelease

[GoogleCodeExporter]

Fix is attached. From a simple file-structure perspective, I think the fix is 
safe; I have tested archetype creation and execution and everything seems to go 
smooth; however, I haven't run intensive tests on specific AMP customisations.

Shall I commit the fix?

Original comment by mauri...@session.it on 4 Apr 2012 at 3:46

Attachments:

• fixIssue#41.patch

[GoogleCodeExporter]

Hi guys, 

I am not sure whether this could a desirable feature for the archetypes. 

IMHO in fact AMPs should be considered as "pure software modules" AKA 
plugins/add-ons, and they should NOT have any side effect on the underlying web 
application, at least in terms of files on the filesystem (any runtime / spring 
/ alfresco specific override is obviously out of our control).

In this sense I believe that if you want to modify / customize Alfresco WAR 
core files, than the maven-alfresco-extension-archetype should instead be used, 
making clear that you are producing a customized version of the WAR instead of 
delivering an AMP which could have (even bad) side effects on the different 
WARs it gets applied to.

Think about this example:

- Your AMP defines a custom log4j.properties or web.xml
- someone from the community / enterprise customers apply this AMP 
- Alfresco starts presenting unpredictable / unexpected behaviors

I think we should avoid that.

WDTY?

Original comment by colum...@gmail.com on 6 Apr 2012 at 9:46

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by colum...@gmail.com on 6 Apr 2012 at 9:48

[GoogleCodeExporter]

I think it makes sense that AMPs do not override the original WAR file, as I 
see an AMP as a way to extend the application and not configure it.

Original comment by mauri...@session.it on 6 Apr 2012 at 10:12

[GoogleCodeExporter]

Marking issue as a Task

Original comment by mauri...@session.it on 6 Apr 2012 at 10:17

• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by colum...@gmail.com on 29 Oct 2012 at 10:49

• Now blocking: #38, #38

[GoogleCodeExporter]

As of the Maven Alfresco SDK 1.0, the install process is based on the new 
Alfresco Maven Plugin which embeds the MMT.

This way we simulate the exact supportable process to install AMPs.

This issue does not apply anymore to me, so proceeding fixing in as part of the 
Maven Alfresco SDK 1.0 release.

Original comment by colum...@gmail.com on 29 Oct 2012 at 10:51

• Changed state: Fixed
• Added labels: Milestone-Release-sdk-1.0.0
• Removed labels: Milestone-NextRelease