Create an alfresco-jar-archetype

[GoogleCodeExporter]

Based on the alfresco-amp-archetype-1.1.1, I performed the following 
experiment; I haven't tested it intensively, but surefire tests and tomcat run 
work.

If there are no objections (warnings or unsupported use cases), I'd like to 
proceed with the development of an alfresco-jar-archetype.

1. Changed packaging from amp to jar
2. Moved src/main/amp/config into src/main/resources
3. Added the following XML snippet to pom.xml

  <build>
    <plugins>
      <plugin>
        <groupId>org.alfresco.maven.plugin</groupId>
        <artifactId>alfresco-maven-plugin</artifactId>
        <version>${maven.alfresco.version}</version>
        <extensions>true</extensions>
        <configuration>
          <skipAmpInstallation>true</skipAmpInstallation>
        </configuration>
        <executions>
          <execution>
            <id>resolve-snapshot-version</id>
            <phase>initialize</phase>
            <goals>
              <goal>set-version</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

Original issue reported on code.google.com by maurizio...@alfresco.com on 12 Dec 2013 at 5:52

[GoogleCodeExporter]

How do the generated JARs get deployed to Alfresco?

Original comment by peter.mo...@alfresco.com on 12 Dec 2013 at 6:18

[GoogleCodeExporter]

Via a standard <dependency>, so they go in WEB-INF/lib ?

I'm talking this week with product management to make this an officially 
supported mechanism.

Original comment by colum...@gmail.com on 12 Dec 2013 at 10:27

[GoogleCodeExporter]

WEB-INF/lib where?  Not all app servers "explode" WAR files to disk, so any 
solution that assumes that WEB-INF/lib (or indeed anything inside alfresco.war) 
is a writable directory (let alone on disk!) is fraught with peril.

Unless, of course, you're also recommending that we drop support for app 
servers and instead simply ship and "Alfresco server" that includes, say, 
Tomcat (which does, for now, "explode" WAR files to disk)?  ;-)

Original comment by peter.mo...@alfresco.com on 13 Dec 2013 at 12:21

[GoogleCodeExporter]

The real issue here is that we should not be enabling, encouraging or 
supporting any deployment mechanism that can't be properly change controlled.  
Manually fucking about with the Alfresco WAR file (whether exploded or not) is 
so far from a "controlled" process that it makes my head hurt...

Original comment by peter.mo...@alfresco.com on 13 Dec 2013 at 12:22

[GoogleCodeExporter]

Now what could work (and I think you'd agree is better than AMP / MMT) is 
something like what Jive do.  For starters they bundle Tomcat (customers have 
no choice of app server) and then configure it in such a way that there's a 
well defined, **EMPTY** folder on disk where additional modules (which in 
Jiveland are nothing but JAR files containing some Jive-specific descriptor 
files) can be deployed.  This directory is then simply configured into the 
classpath of the Jive server by default (i.e. via their specialised Tomcat 
configuration).

I'd be fully supportive of such a chance, since it gets us out of the MMT / AMP 
frying pan without putting us straight into the "let's encourage everyone to 
fuck about with our webapp" fire (which is a LOT worse than MMT / AMP).

Original comment by peter.mo...@alfresco.com on 13 Dec 2013 at 12:26

[GoogleCodeExporter]

Peter, there is no manual changes of the WAR files here. There has never been 
in the SDK, which is all about managing the full lifecycle of the customization 
(including packaging the customization in an AMP - or JAR in this case - and 
then installing, via alfresco-maven-plugin (or any other piece of code 
embedding the MMT, e.g. apply_amps.sh) into the WAR.

The whole point of the SDK is to allow people to automatically, via a standard, 
reproducible way, to build the customized WAR, which then becomes the 
deployable.

In the same way that it's currently done by AMPs (whether you do it with 
maven-war <overlay> or with the apply_amps.sh script).

Being the Maven Alfresco SDK 1.1.0 now a supported methodology to extend 
Alfresco WARs, I don't see any functional difference between depending on a JAR 
or on AMP. If anything a simplification, and the discouraging of overwriting 
unwanted parts of the WAR.

It seems to me you are missing the point here: in fact the whole purpose of the 
Maven SDK is to provide a project, that can committed in a source control 
system (so versioned, change controlled) which will always produce the same 
customized WAR. In the same exact way (but standard) that the apply_amps.sh 
crappy script does.

I suggest we have an offline chat on this.

Original comment by colum...@gmail.com on 13 Dec 2013 at 12:31

[GoogleCodeExporter]

Thx guys for the feedback!

There is no manual process involved for the build, it's actually handled by 
Maven; this approach simply
1. Uses a JAR instead of an AMP
2. Delegates to Maven (and not alfresco-maven-plugin, via MMT) to install the 
module JAR into the Alfresco WAR, using a JAR <dependency>

When it comes with local execution (the -Pamp-to-war profile), the following 
change should be added in order to test the module locally

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <executions>
          <execution>
              <id>jar-copy-alfresco-resources</id>
              <phase>prepare-package</phase>
              <goals><goal>copy-resources</goal></goals>
              <configuration>
                <outputDirectory>${alfresco.client.war.folder}</outputDirectory>
                <resources>
                  <resource>
                    <directory>${project.build.outputDirectory}</directory>
                    <targetPath>WEB-INF/classes</targetPath>
                    <filtering>false</filtering>
                  </resource>
               </resources>
            </configuration>
          </execution>
        </executions>
      </plugin>

I am also experimenting something like the following, which is IMO a better 
approach; any feedback is more than welcome!

      <plugin>
              <groupId>org.apache.tomcat.maven</groupId>
              <artifactId>tomcat7-maven-plugin</artifactId>
              <version>2.1</version>
              <configuration>
                <warRunDependencies>
                  <warRunDependency>
                    <dependency>
                      <groupId>${project.groupId}</groupId>
                      <artifactId>${project.artifactId}</artifactId>
                      <version>${project.version}</version>
                      <type>jar</type>
                    </dependency>
                    <contextPath>/alfresco</contextPath>
                  </warRunDependency>
                </warRunDependencies>
              </configuration>
      </plugin>

Original comment by maurizio...@alfresco.com on 13 Dec 2013 at 10:32

[GoogleCodeExporter]

Mau, Maven cannot be a requirement at deployment time.  It must be possible to 
deploy binary modules (i.e. AMPs or equivalent) without requiring Maven.

Original comment by pmo...@gmail.com on 13 Dec 2013 at 3:14

[GoogleCodeExporter]

I undersstand your contern.

In case of a module deployment on existing Alfresco WAR applications 
(deployment time), this approach would not work; however, if you're 
building/distributing your application using WAR files (apparently a wide 
practice, also used in the all-in-one archetype), this solution could be 
interesting. Maybe adding another module (WAR packaging, with a dependency on 
the JAR module and the Alfresco WAR overlay, more similar to the all-in-one) to 
the archtype would help?

Original comment by mauri...@session.it on 14 Dec 2013 at 12:10

[GoogleCodeExporter]

Mau do you have data supporting your assertion that this is a "wide practice"?

That certainly doesn't gel with my experience, nor my understanding of 
Alfresco's official support policies.

Original comment by peter.mo...@alfresco.com on 14 Dec 2013 at 12:13

[GoogleCodeExporter]

No, I cannot provide any data, the statement is based on experience gathered on 
the field (but I think that you've have more than mine)

I agree with the fact that this approach doesn't follow the official support 
policies; this is only for experimental purposes, it's not a proposal for 
replacing the current archetypes/poms; maybe I just took the wrong path :-)

Original comment by mauri...@session.it on 14 Dec 2013 at 12:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yeah that's my concern with this approach - it encourages unsupported 
behaviour.  Am I right in thinking that this is a central tenet of this project?

If not then my apologies - I've misunderstood the project's guiding principles.

Original comment by peter.mo...@alfresco.com on 14 Dec 2013 at 12:31

[GoogleCodeExporter]

You're right about the tenet of this project (Gab may confirm it); thanks a lot 
for all the precious feedback!

Original comment by mauri...@session.it on 14 Dec 2013 at 12:39

[GoogleCodeExporter]

Original comment by maurizio...@alfresco.com on 16 Dec 2013 at 6:27

• Changed state: OnHold

[GoogleCodeExporter]

Hi Maurizio,

The jar-archetype would be very interesting to me to try, I also know a couple 
of other guys who are already doing something like that.

The thing I need though is that, first, the jar project is runnable via 
-Pamp-to-war, as you stated above. But also that if there are any dependencies 
to other jar modules, then they would also be applied into the exploded WAR 
used by -Pamp-to-war.

Original comment by bulat.ya...@gmail.com on 16 Dec 2013 at 11:45

[GoogleCodeExporter]

Hi,
I'm develloping a share extension with maven. The share extension is a maven 
module, packaged as jar. Maven war plugin and maven jetty plugin are configured 
to run the share webapp with overlay. Dev environment is working great, and 
packaged file is just a jar that we put in tomcat/shared folder in target 
environment.

In pom.xml :
1/ Add dependency to share war

       <dependencies>
        <dependency>
            <groupId>org.alfresco.enterprise</groupId>
            <artifactId>share</artifactId>
            <type>war</type>
        </dependency>
    </dependencies>
2/ Map the webapp resources to jar structure (maybe not necesseray, but in my 
case, all custom web resources are un src/main/webapp folder )

        <resources>
            <resource>
                <directory>src/main/resources</directory>
            </resource>
            <resource>
                <directory>src/main/webapp</directory>
                <targetPath>${project.build.directory}/classes/META-INF</targetPath>
            </resource>
            <resource>
                <directory>.</directory>
                <includes>
                    <include>file-mapping.properties</include>
                </includes>
                <targetPath>${project.build.directory}/${project.build.finalName}</targetPath>
            </resource>
        </resources>

3/ Configure overlay mecanism in maven war plugin  
<plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <configuration>
                    <overlays>
                        <!-- The current project customizations -->
                        <overlay />
                        <!-- The Share WAR -->
                        <overlay>
                            <groupId>org.alfresco.enterprise</groupId>
                            <artifactId>share</artifactId>
                            <type>war</type>
                            <!-- To allow inclusion of META-INF -->
                            <excludes />
                        </overlay>

                        <!-- <overlay> <groupId>${alfresco.groupId}</groupId> <artifactId>alfresco-wcm-quickstart-share</artifactId> <type>amp</type> </overlay> -->
                    </overlays>
                </configuration>
            </plugin>

4/Configure jetty plugin :
<plugin>
                <groupId>org.mortbay.jetty</groupId>
                <artifactId>jetty-maven-plugin</artifactId>
                <configuration>
                    <webApp>
                        <contextPath>/share</contextPath>
                    </webApp>
                    <reload>manual</reload>
                    <scanIntervalSeconds>10</scanIntervalSeconds>
                    <connectors>
                        <connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
                            <port>8181</port>
                            <maxIdleTime>60000</maxIdleTime>
                        </connector>
                    </connectors>
                    <war>${project.build.directory}/share</war>
                    <useTestScope>true</useTestScope>
                    <!-- configure SLF4J to use Log4J -->
                    <systemProperties>
                        <systemProperty>
                            <name>org.apache.commons.logging.Log</name>
                            <value>org.apache.commons.logging.impl.Log4JLogger</value>
                        </systemProperty>
                    </systemProperties>

                </configuration>
                <dependencies>
                    <!-- add SLF4J and Log4J to the plugin classpath to prevent logging to stderr -->
                    <dependency>
                        <groupId>org.slf4j</groupId>
                        <artifactId>slf4j-api</artifactId>
                        <version>1.6.4</version>
                    </dependency>
                    <dependency>
                        <groupId>org.slf4j</groupId>
                        <artifactId>slf4j-log4j12</artifactId>
                        <version>1.6.4</version>
                    </dependency>
                </dependencies>
                <!-- <executions> <execution> <id>run-amp-to-war</id> <goals> <goal>run-exploded</goal> </goals> <phase>pre-integration-test</phase> </execution> </executions> -->
            </plugin>

Original comment by alexis.t...@gmail.com on 8 Apr 2014 at 7:59

[GoogleCodeExporter]

Original comment by maurizio...@alfresco.com on 3 Jul 2014 at 12:28

• Added labels: Milestone-Release-sdk-unscheduled