The reason for not wanting to (or not being able to) use the install goal is because I am attempting to use maven assemblies to create a zipped archive of our app. The assembly Maven goal is a strange beast with a few limitations on how it works. You can read about it here: http://www.sonatype.com/books/maven-book/reference/assemblies-sect-basics.html. Basically it has two modes, one is assembly:assembly which is designed to run out of the normal lifecycle and you therefore must/should run it manually from the command line. The other is it can be made part of the lifecycle but you *must* explicitly call the package goal first in order to overcome an oddity with how this assembly plugin works.
So... I want this to be run from Hudson (our CI server) so the first option is out as I need to run a normal lifecycle so that leaves the second option. So now I *must* call package and if I run 'mvn clean package' the assembly process runs correctly. However, due to this issue (I'll call it an issue and not a bug ;) ) I *must* call install and as soon as I do that the entire lifecycle runs twice due to this oddity in how this assembly goal works. I would classify that as a bug and I saw mentions of it being fixed in the next major version of Maven. So just to re-iterate... I can call 'mvn clean package install assembly:assembly' but this causes the whole lifecycle to be run twice which is more than annoying. The workaround that I have found is to create a whole new project that is solely responsible for doing the assembly/distribution. That info was found here: http://www.sonatype.com/books/maven-book/reference/assemblies-set-dist-assemblies.html So I don't know if this can be called a bug or not. It isn't a problem really if you aren't using assemblies in which case you can just use 'install', and there is a fairly simple workaround. Assemblies aside though, I would vote that as this is a compile time action it should work at compile time. Although, as Lorand mentions, if you are just compiling the one module that the dependency would have to be installed to the local repo. I would compare it to compiler.library-path option where it *does* use the local modules correctly and doesn't require dependencies to be installed in the local repo. The workaround is what I will continue with for now though... Collin On Jul 7, 4:55 pm, Marvin Froeder <[email protected]> wrote: > Hi Collin, > Why can't you install? > > Module B can't access Module A artifacts directly.... well, probably there > is a way, but I don't know how, so use the local repo. > > VELO > > On Tue, Jul 7, 2009 at 8:49 PM, Collin Peters <[email protected]>wrote: > > > > > We have a large, multi-module, application being compiled by flexmojos > > (great work by the way!) and we use the link-report & load-externs > > features of the compiler to reduce file sizes on our SWFs that are > > loaded by parent SWFs. This features works fine when using the > > 'install' maven goal, but it does not work when using the 'compile' > > goal. To be very specific... it does not work with the compile goal > > unless you happen to have run 'install' already and the XML link- > > report file has already been installed to the local Maven repo. > > > Example: > > 1. Imagine a multi-module project with two children: moduleA and > > moduleB, where moduleB depends on moduleA > > 2. The poms have been setup so that moduleA runs 'link-report' to > > produce the XML link-report file which is then used by moduleB using > > the 'load-externs' option > > 3. Clean out .m2/repository/myapp > > 4. Run 'mvn clean compile' > > 5. Build fails on moduleB because it can't find the link-report XML > > (Maven spits out the usual instructions for how to install it to your > > local repo) > > 6. Now run 'mvn clean install' > > 7. Build suceeds because on the install phase on moduleA the link > > report XML was install to your local Maven repo and moduleB was able > > to use it > > > Hopefully this is clear because I know link-report/load-externs is not > > an often used feature. I believe flexmojos used to have a similar > > problem with SWCs (with multi-module projects) as it tried to look for > > them in the repo first, and not in the working folder of the project --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Flex Mojos" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/flex-mojos?hl=en?hl=en http://blog.flex-mojos.info/ -~----------~----~----~----~------~----~------~--~---
