Launching Acceleo generation from Maven – take 2

Just before summer vacations, I’ve wrote a post on Launching Acceleo generation from Maven and that seems to interest many people out there. Many questions came out on configuration details, encountered problems, compatibility issues with Tycho system and so on …

So here’s a short sequel to introduce a repository I put on GitHub in order to illustrate the use case that was previously introduced. For the impatient ones, just go to https://github.com/lbroudoux/acceleo-maven-sample to check the source code.

21-apr update

I’ve post a sequel to this blog post here : https://lbroudoux.wordpress.com/2013/04/21/launching-acceleo-generation-from-maven-take-3/ that deals with portability issues on the build. The demo project on Github has evolved in consequence.

Since my last post, I’ve made the use case a little bit more complex by introducing an another Acceleo project that is having a dependecy with a first one. The schema below summarizes the artifacts locations, names and dependencies :

And here’s a brief introduction on artifact content and their location with GitHub repository :

com.github.lbroudoux.acceleo.uml.java

This is the base artifact. It is an Acceleo module that provides some basic UML to Java templates. It is bundled as a Maven artifact and thus has a pom.xml. Sources can be found here.

com.github.lbroudoux.acceleo.uml.java.jpa

This is an Acceleo module that provides basic UML to Java Persistence APIs template. It is also bundled as a Maven artifact and thus has a pom.xml with a dependency to basic uml module. Sources can be found here.

com.github.lbroudoux.myapp

This is a sample application that contains a UML model (myapp.uml) with only an entity (Stuff class). It is bundled as a Maven artifact and the pom.xml defines an Acceleo generation step bound to the generate-sources Maven lifecycle phase. After that phase, a unit test (StuffTest.java) ensures that things have been correctly generated from our JPA Acceleo module that also uses basic Java Acceleo module. Sources can be found here.

How to use it ?

Just git clone the repository, and then execute the following commands :

acceleo-maven-sample$ cd com.github.lbroudoux.acceleo.uml.java
acceleo-maven-sample/com.github.lbroudoux.acceleo.uml.java$ mvn clean install
...
acceleo-maven-sample/com.github.lbroudoux.acceleo.uml.java$ cd ../com.github.lbroudoux.acceleo.uml.java.jpa
acceleo-maven-sample/com.github.lbroudoux.acceleo.uml.java.jpa$ mvn clean install
...
acceleo-maven-sample/com.github.lbroudoux.acceleo.uml.java.jpa$ cd ../com.github.lbroudoux.myapp
acceleo-maven-sample/com.github.lbroudoux.acceleo.uml.java.jpa$ mvn clean test

The build should all be successfull : look at the console output and you’ll see trace of Acceleo generation.

In the fourthcming weeks, I’ll try to make the Maven builds compliant with Tycho. Let me know if it help some of you and do not hesitate forking and enhancing !

Advertisements

13 thoughts on “Launching Acceleo generation from Maven – take 2

  1. Thanks for this blog. I had to remove the following line from the pom.xml of the myapp project to make it work:
    ${settings.localRepository}/org/eclipse/uml2/org.eclipse.uml2.uml.resources/3.1.0.v201005031530/org.eclipse.uml2.uml.resources-3.1.0.v201005031530.jar

    When I look at the main method of the Generate.java, the umlJarPath as third argument ins’t there anymore. Is this correct?

    1. Hi Erwin,

      thanks for the comment.

      What you note seems coherent but also weird because when you look at source code on https://github.com/lbroudoux/acceleo-maven-sample/blob/master/com.github.lbroudoux.acceleo.uml.java.jpa/src/com/github/lbroudoux/acceleo/uml/java/jpa/main/Generate.java , the part managing third argument is present :

      // If there’s a third argument, it is UML ressources jar path.
      if (args.length > 2){
      umlJarPath = args[2];
      }

      I’ve git clone the repo once again and also got this code in the new copy … strange !

      1. You are right, I did a new clone and now the code is there. It needs to be there for the UMLPrimitiveTypes. Otherwise the types (like String) are not recognized by the generator.

  2. Ok, I figured it out, it’s the acceleo plugin which is regenerating the Generate class. When you change the @generated in the javadoc of the main method to @notgenerated, you keep your custom code.

  3. Hi,
    I’m using v3.2.1 of your acceleo maven plugin.
    The ‘compiled’ emtl files have a hard coded path to the ‘imports’ of emtl files that are in other jars/modules.

    is this a bug, or am I using it wrong.

    cheers

    1. The problem with a multi project acceleo build with maven appears to be the hrefs within the compiled emtl files.
      Your acceleo maven plugin allows for these to be either:
      a) absolute paths (to the maven repository)
      b) ‘platform:/plugin/…’ paths.

      (a) works if the acceleo projects (maven artifacts) are build on the same machine as the one on which we do the generation, but if the location of the maven repository changes, we have a problem.

      (b) doesn’t work because running from within maven, ‘platform:/plugin/’ cannot be resolved.

      Have you any suggestions?

      1. Hello Dave,

        you are right : multi-project build is a mess because of Acceleo depencies path resolution … These limitations are a little bit explained in few posts such as :
        http://www.eclipse.org/forums/index.php/t/420838/
        https://bugs.eclipse.org/bugs/show_bug.cgi?id=360926#c7

        In our case (when it comes to deploy on our projects in my company), this does not really bother us because development infrastructure are standardized and we are sure that local maven repos have always the same location. We are in the (a) case you mention !

        However, following your comments, I thought problem deserves to be investigated more deeply and I’ve had some ideas on a possible workaround. I’ll try to check that during the week-end and post some results about that (even if not successfull)

        Regards,

      2. Thanks for your reply. I have done some exploration/experiments my self mentioned here [http://stackoverflow.com/questions/16054625/acceleo-maven-generation-multi-artifact-project]. Basically I tried to override the ‘createURIConverter’ method, and get it to decode the ‘platform:/plugin/..’ using a URLClassLoader. It seems to decode the hrefs ok, but the EMTL metamodel instance does not get correctly instantiated…references to things from a depended on project are set to null.

      3. The problem with resolving the hrefs was just a lack of resource factories being registered (the exception informing me of this gets lost in EcoreUtil.resolve which catches the exception with “// Failure to resolve is ignored.” – most unhelpful).

        So it seems that my approach of “override the ‘createURIConverter’ method, and get it to decode the ‘platform:/plugin/..’ using a URLClassLoader” does work.

        Building the URLClassLoader using the same method done in the AcceleoParserMojo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s