AMP Plugin: store config assets in fully expanded folder structure rather than a single folder

[GoogleCodeExporter]

Currently the AMP plugin stores assets src/main/config in the following
folder structure in the AMP:

    config/alfresco/module/com.acme.myextension

This causes problems when trying to classload resources that are stored in
the config folder - a problem that can be avoided by using a fully expanded
folder structure in the AMP file instead, ie:

    config/alfresco/module/com/acme/myextension

Original issue reported on code.google.com by pmo...@gmail.com on 28 Oct 2009 at 6:40

[GoogleCodeExporter]

Original comment by pmo...@gmail.com on 28 Oct 2009 at 6:53

• Changed state: New

[GoogleCodeExporter]

According to the amp specs "There are a couple of files that are required by the
module service, these should be placed in the package 
alfresco.module.<moduleid>".
See http://wiki.alfresco.com/wiki/Developing_an_Alfresco_Module. Since the 
moduleId
is generated as module.id=${pom.groupId}.${pom.artifactId}, this is working as 
expected. 

Original comment by tib...@gmail.com on 7 Dec 2009 at 5:30

[GoogleCodeExporter]

When written into an AMP file, the groupId and artifactId need to be separated 
by the
path separator character ("/"), as per the Java standard for storing package
hierarchies in the filesystem.  Without this, it's impossible to load classpath
resources from within a package hierarchy, as classloaders don't typically 
check both
x/y/z/ and x.y.z/ when asked to retrieve a classpath resource such as
x.y.z.resourceFilename.extension - they only check "real" paths (ie.
x/y/z/resourceFilename.extension).

FWIW Gab and I discussed this in detail back in late October, and after coming 
to an
understanding of the issue, he asked me to raise this bug report.  It may be
worthwhile discussing this further with him - I'm not entirely clear on the 
exact
process that's being used to vet and prioritise bugs.

Original comment by pmo...@gmail.com on 7 Dec 2009 at 7:45

[GoogleCodeExporter]

Issue 42 has been merged into this issue.

Original comment by colum...@gmail.com on 24 Feb 2010 at 8:59

[GoogleCodeExporter]

After a discussion with Gabriele I have changed the way moduleId is generated, 
from 
${groupId}.${artifactId} to just ${artifactId}. Now the resources is getting 
picked up 
correctly.

Original comment by bille...@gmail.com on 1 Mar 2010 at 2:25

• Changed state: Fixed