Spring Actionscript is a great library - no question. It makes it much easier to mock Cairngorm service delegates and rewire them for testing with FlexUnit. Testing the full event/command/delegate workflow is pretty easy.

However today I had quite some "fun" with the Maven artifact and it's transitive dependencies in combination with Maven 2.2.1. Spring Actionscript has some dependencies to these artifacts:

  • as3commons-lang
  • as3commons-logging
  • as3commons-reflect
All these required artifacts are available from the yoolabs.org repository so it's pretty easy to include these artifacts into your build. But today I struggled with two hefty problems.

We have a rather complicated setup. There are tons of individual Flex artifacts and libraries along with several Java modules for the backend. We also have certain legal requirements to the build like being able to reproduce a released build at any time in case a customer needs a patch. This requires a tight dependency management, which can only be accomplished with an in-house repository server that is able to cache external libraries in case external repository servers break and become unavailable or in case artifacts are removed. All builds are absolutely restricted to the in-house repository server. No build may access external repository servers directly.

Until I noticed that Flex builds suddenly start to contact the yoolabs.org repository server. I searched all POM files, but did not find any reference to this server. My local Maven settings also did not contain anything. So how was this repository server introduced to the local build?

Update 2009-11-14: The original article claimed that a distributionManagement section tag was the fault. This is not true. After further examination I discovered that the spring-actionscript-superpom declares remote repositories, which are actually used:

	<repositories>
		<repository>
			<id>flex-mojos-repository</id>
			<url>http://repository.sonatype.org/content/groups/public</url>
			<releases>
				<enabled>true</enabled>
			</releases>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
		</repository>
		<repository>
			<id>yoolab.org-releases</id>
			<url>http://projects.yoolab.org/maven/content/repositories/releases</url>
			<releases>
				<enabled>true</enabled>
			</releases>
		</repository>
		<repository>
			<id>yoolab.org-snapshots</id>
			<url>http://projects.yoolab.org/maven/content/repositories/snapshots</url>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</repository>
	</repositories>

I have tested this with various Maven versions and obviously repositories in dependent POMs are activated since Maven 2.1.0. With 2.0.9 I cannot reproduce this behavior, but any version above 2.1.0 downloads artifacts from such repositories defined in dependencies.

For completeness, here is the old and wrong text:

After spending some hours searching I finally examined the POMs of the artifacts hosted on the yoolabs.org repository servers and found something in the as3commons-project POM:

    <distributionManagement>
		<repository>
			<id>yoolab.org-releases</id>
			<name>Yoolab.org releases repository</name>
			<url>dav:https://www.yoolab.org/maven/content/repositories/releases</url>
		</repository>
		<snapshotRepository>
			<id>yoolab.org-snapshots</id>
			<name>Yoolab.org snapshots repository</name>
			<url>dav:https://www.yoolab.org/maven/content/repositories/snapshots</url>
		</snapshotRepository>
		<site>
			<id>yoolab.org-as3commons</id>
			<url>scp://www.as3commons.org/srv/www/www.as3commons.org/public_html</url>
		</site>
	</distributionManagement>

The distributionManagement section seems to be something new in Maven 2.2.1. At least I am unable to reproduce this behavior with Maven 2.0.9 and that's why I haven't noticed it until I had upgraded my notebook to Ubuntu 9.10, which comes with Maven 2.2.1. It allows an artifact to define remote repositories, where transitive dependencies can be downloaded.

Well, I must say I have an ambivalent opinion about defining other repositories in POMs on remote repositories. It may ease initial setup, but it is very dangerous if you want to enforce a tight artifact management. I don't know yet, how to disable such indirect repositories. The only solution I know so far is running Maven builds with no direct Internet access and making sure that no proxy has been configured for Maven.

This was the first problem. The second problem also took some time to figure out.

Since some projects started to use features from the Flash Player 10 that are not available in the Flash Player 9 API, we had to upgrade the playerglobal artifact dependency. The major version of the Flash Player is configured through a classifier, which is not a good idea and you'll see soon why.

So we had changed all occurrences of the artifact in the POM files, but still the build was being compiled against the old Flash Player 9 libraries. To make it more interesting this was the case only on some machines. E.g. on a colleagues Windows Vista machine the build failed, but not on my Linux Box. Running mvn dependency:tree finally revealed that the artifacts spring-actionscript-core, spring-actionscript-cairngorm and as3commons-logging had dependencies to this playerglobal artifact with classifier 9.

Artifacts with different classifiers are different artifacts by Maven convention. So in case you do no longer have an explicit dependency to playerglobal, classifer 9, you are not longer able to overwrite the version. Note that the classifier is NOT the version. So after upgrading our POMs to playerglobal, classifier 10, we had two playerglobal dependencies. And the actual dependency that was used by the compiler was obviously chosen randomly. So on one developer machine classifier 10 was in place, on another classifier 9.

So in case you use Spring Actionscript in your builds, you may have a working build, until you change something that affects the dependency order in your builds and suddenly the builds will fail with no obvious reason. To prevent this problem, you will have to exclude the playerglobal dependency from the transitive dependencies of the affected artifacts when you add the dependencies mentioned above to your POM:

    <dependency>
      <groupId>org.as3commons</groupId>
      <artifactId>as3commons-logging</artifactId>
      <type>swc</type>
      <!-- Supress transitive playerglobal 9 dependency from
           as3commons-logging -->
      <exclusions>
        <exclusion>
          <groupId>com.adobe.flex.framework</groupId>
          <artifactId>playerglobal</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
 
    <dependency>
      <groupId>org.springextensions.actionscript</groupId>
      <artifactId>spring-actionscript-core</artifactId>
      <type>swc</type>
      <!-- Supress transitive playerglobal 9 dependency from
           spring-actionscript-core -->
      <exclusions>
        <exclusion>
          <groupId>com.adobe.flex.framework</groupId>
          <artifactId>playerglobal</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

    <dependency>
      <groupId>org.springextensions.actionscript</groupId>
      <artifactId>spring-actionscript-cairngorm</artifactId>
      <type>swc</type>
      <!-- Supress transitive playerglobal 9 dependency from
           spring-actionscript-cairngorm -->
      <exclusions>
        <exclusion>
          <groupId>com.adobe.flex.framework</groupId>
          <artifactId>playerglobal</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

Trackbacks


Trackback specific URI for this entry
    No Trackbacks

Comments


    #1 Nick Stolwijk on 11/11/09 at 10:21 PM
    *The distributionManagement section is nothing new. The pom model is still 4.0.0, which it always has been in the 2.x.x versions of Maven. Also, this has will only be used when deploying artifacts and not when retrieving them. Take a look at the other poms if they specify a repository element which includes this repository. Also take a look at http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/

    Did you check your build with Maven 2.0.9 right after your build failed?
    #1.1 Carsten Schlipf on 11/12/09 at 09:37 AM
    *Hi Nick,

    there is no repository in any POM, but our in-house repository. I've searched all POM files - no repository defined anywhere. The only occurence of this repository is in that distributionManagement.

    And it is definitely not limited to deploy, as I am only running mvn clean install. Also it does not appear with Maven 2.0.9, but with Maven 2.2.1 and not only on my developer machine.
    #1.1.1 Nick Stolwijk on 11/12/09 at 09:57 AM
    *Could send a mail to the mailinglist describing your issue (or pointing here) with a pom file attached. This seems a serious problem.
    #1.1.1.1 Carsten Schlipf on 11/12/09 at 10:17 AM
    *I will have to recreate a sample project which can reproduce this problem. Will take some time. Can you tell me, which mailing list you mean and where I can subscribe?
    #1.1.1.1.1 Nick Stolwijk on 11/12/09 at 11:16 AM
    *The mailing list of the Maven software over at http://maven.apache.org/mail-lists.html and then the first one.

    Listaddress: users@maven.apache.org
    Subscribeaddress: users-subscribe@maven.apache.org
    #1.2 Carsten Schlipf on 11/14/09 at 04:27 PM
    *Hi Nick,

    you were right. The spring-actionscript-superpom declares remote repositories. I've updated the article.

    I still have to verify this with Maven 2.0.9 and why I haven't seen it with that version so far.

    Best regards,
    Carsten
    #1.3 Mitsutaka on 09/11/12 at 12:48 AM
    *We're trying to have a multi IDE evroninment here, but I've noticed that when you run FlexUnit tests using FlashBuilder it automatically pulls in it's own included version of FlexUnit (4.0.1.277662). Have you had any problems with this or have you moved away from FlashBuilder completely now?
    #1.3.1 Carsten Schlipf on 09/11/12 at 09:51 AM
    *Haven't used FlashBuilder for the last years anymore. It simply cannot deal with our large multi-project environment and the Maven support is essentially not existing.
    #2 Philip Wilder on 11/16/10 at 04:38 PM
    *Just wanted to let you know that this approach solved a compilation problem. Thanks for the tip.

Add Comment

HTML-Tags will be converted to Entities.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA