search

DPascalBernard / maven-alfresco-archetypes

Automatically exported from code.google.com/p/maven-alfresco-archetypes
0 stars 0 forks source link

Transitive AMP dependencies management #133

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Currently AMP can be installed in 3 ways (see docs here 
https://artifacts.alfresco.com/nexus/content/repositories/alfresco-docs/alfresco
-lifecycle-aggregator/latest/plugins/alfresco-maven-plugin/advanced-usage.html):

- with direct alfresco:install goal calls
- providing the ampLocation config to the alfresco-maven-plugin in a WAR build, 
install filesystem available AMPs
- via WAR overlays, by specifying the AMP as a dependency and then reference it 
in the overlay section

We need to investigate support for transitive AMPs installation.

Original issue reported on code.google.com by gabriele...@alfresco.com on 10 Jul 2013 at 9:57

GoogleCodeExporter commented 9 years ago

Original comment by colum...@gmail.com on 10 Jul 2013 at 9:57

GoogleCodeExporter commented 9 years ago 
I wonder if in this dependency scenario

AMP1 --> AMP2

WAR --> AMP1

both AMP1 and AMP2 would be in the reactor of the WAR build, and so you might 
be able to reference both of them in an <overlay> section.

Original comment by colum...@gmail.com on 10 Jul 2013 at 9:58

GoogleCodeExporter commented 9 years ago 
Also Axel Faust has contributed a patch in Github to provide an additional 
parameter to install transitive dependencies:

https://twitter.com/ReluctantBird83/status/353580122986655744

Axel can you provide a bit of description of the patch?

Original comment by colum...@gmail.com on 10 Jul 2013 at 10:00

GoogleCodeExporter commented 9 years ago 
The patch provides the ability for a 4th way to install AMPs by using the 
dependency declaration on the project. Instead of having to explicity call 
alfresco:install, specify an ampLocation or perform an overlay, the InstallMojo 
pulls "runtime"-scoped AMP dependencies from the WAR build project. This is 
achieved by a new configuration option "installFromDependencies" (boolean).

As modules can have dependencies between them expressed in their 
module.properties, the order of installation is important. In the previous 3 
ways this needed to be handled manually. Even the old (experimental) 
maven-mmt-plugin did nothing to order installs, following the ordering of the 
file system after copying the AMPs into a temporary directory "ampoverlays".

For the "installFromDependencies" feature, the patch also includes dependency 
graph analysis to detect inter-dependencies between the modules about to be 
installed. It uses the Aether API used by Maven internally to collect all 
transitive dependencies of those AMPs (stopping at the first JAR encountered in 
a dependency graph) of scope "runtime". There is some tolerance built into the 
analysis so that AMP1 => AMP2 dependencies are picked up even if the POM of 
AMP1 only contains a dependency on the JAR artefact of AMP2.

The MOJO respects the order in the <dependencies> segment as best as possible. 
Starting from the first AMP it checks for any dependency and recursively 
installs dependant AMPs out of the regular order if:

1) the transitive dependency is an AMP and it itself is contained in the 
<dependencies>-configuration
2) the transitive dependency is a JAR and an AMP with the identical 
groupId:artifactId pair is contained in the <dependencies> segment

Original comment by axel.fau...@googlemail.com on 10 Jul 2013 at 10:34

GoogleCodeExporter commented 9 years ago 
Ok I tried the transitive dependencies using <overlay> but fails because the 
depended AMP is not added to the WAR reactor.

I would love to have a solution which hooks into the standard <overlay> 
ordering, instead of having one more way of doing things.

Axel, wdyt?

Original comment by colum...@gmail.com on 10 Jul 2013 at 10:36

GoogleCodeExporter commented 9 years ago 
It should be possible to hook it into the <overlay> by moving it to the 
UnArchiver. But I see the following issues:

- any <overlay> still requires at least one duplicate, manual configuration 
(<dependency> + <overlay>) for each AMP that is not the dependency of another 
AMP
- the UnArchiver would have to check and avoid duplicate dependency 
installation over multiple invocations (e.g. two <overlay> AMPs which share a 
dependency)
- the UnArchiver does not support a configuration option for the "backup" 
parameter
- an explicit "install" goal may still be a valueable feature for anyone using 
the SDK

As this was my first time fiddling around within actual Maven plugin code, I 
don't know about options to externalize the code including the dependencies / 
requirements on Maven components and reusing it for both the InstallMojo and 
the UnArchiver...

Original comment by axel.fau...@googlemail.com on 10 Jul 2013 at 11:08

GoogleCodeExporter commented 9 years ago 
Hi Alex, 

so I have reviewed the issue for the 1.1.0 release and I believe that we need 
to rethink the way we use WAR/JAR/AMP packaging.

I don't think I'll make to merge and test this for 1.1.0 (lots of changes 
already for Alfresco 4.2.0 + Tomcat + rapid development support) so scheduling 
for 1.2.0.

Let's talk at Summit if you're there!

Original comment by colum...@gmail.com on 3 Nov 2013 at 2:21

GoogleCodeExporter commented 9 years ago 
Hi Gabriele and Alex,

So did you come to any conclusions on this at Summit? :) 

I really miss a possibility to run my module via -Pamp-to-war, but having any 
dependent modules/jars included. This must be a popular use case when somebody 
wants to extract common functionality of several local projects into a separate 
module.

Original comment by bulat.ya...@gmail.com on 6 Feb 2014 at 10:44

GoogleCodeExporter commented 9 years ago 
This would make running the recently mavenized ECM Architect tutorials much 
easier as they are each split into their own projects with some of them 
depending on prior tutorial AMPs to run. Currently the later tutorials cannot 
run in the embedded Alfresco or run unit tests without this feature.

Original comment by jeff.po...@alfresco.com on 6 Feb 2014 at 3:06

GoogleCodeExporter commented 9 years ago

Original comment by colum...@gmail.com on 10 Jun 2014 at 12:52