Anyone have any ideas? Thanks, -Brian
-----Original Message----- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 21, 2006 5:46 PM To: Maven Developers List Subject: control of reactor ordering from plugin This is a usability question but also dev related since the answer may require/prompt changes to the dependency plugin. I'm using assembly:attached to generate many different zip files that package things I want to reuse. In this case, some data to be imported into hsql for unit test purposes. This zip file occurs in a sub module /data/modules. In /data/variants I have more assembly:attached things that depend on the product of the rest of the builds. In otherwords, the dependency tree effectively is: /data/variant[s] -> service jars -> /data/module[s]. Since I'm using the dependency plugin to unpack/copy artifacts, these zips are effectively dependencies but Maven doesn't know because they aren't explicitely listed in the dependency section. We attempted to list these zips as proper dependencies to affect the ordering, but in doing so, Maven fails because it can't find a pom that matches the zip (remember we have pom packaging with assembly:attached to deploy). Putting the data child at the top of the module tree in the parent pom works a little, but Maven still doesn't understand that some jars need to be built before executing the data/modules assemblies. (we can control a little by listing the jars as dependencies and won't run into the missing pom problem like the assembly:attached zips but I'm looking for a way to make the dependency-plugin more robust) So, the question is: Is it possible to modify the dependency plugin in a way to allow it to take part in the ordering phase that Maven does before executing the builds? (ie to have it inject some dependencies to the tree) Alternatively, is there a way to allow the dependency plugin to detect that some artifacts are in the same reactor build and cause them to be built before continuing? (fork perhaps? - not ideal because presumably these modules would then be built 2x) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
