I would still consider this a bug as currently you cannot compile a multi-module flex project that uses link-report/load-externs using the compile or package goals (which as you point out are synonymous in flexmojos). And to be fully clear, if you were to run 'install' and *then* run 'compile'/'package' it *would* work because it would be using the link report XML files from the maven repo from the *last* run when 'install' was used. This could cause unexpected errors if the class listed in the XML file should have changed.
At the end of the day, the severity of all this is low but I think it should be considered a bug. I was always just using 'install' anyways because I got in the habit of doing that and in flexmojos there isn't too much of a difference between 'compile' and 'install', other than installing into the local repo. Maybe a simple way of stating the problem is "why do swcs load properly in multi-module flex projects as dependencies (i.e. they use the swc just compiled in the module/target directory), but not link report xml files?" Collin On Jul 8, 9:26 am, Marvin Froeder <[email protected]> wrote: > If you wanna load an artifact (in this case the link report) from another > module it must be present on repo (may be there is an workaround here, since > you can run mvn compile on java, but I don't see this as a problem on > flexmojos) > > This packaging issue shouldn't be a problem on flexmojos too, the swc/swf is > created on compile phase (on flex there is no compilation w/o packaging, at > least I'm not aware of it if it does exists) > > Anyway, you could run assembly on verify phase.... This phase is after > package, but before install.... > > Using another module just for assembly is a solution for you problem as > well. > > Worse case scenario, you need to figure out how other maven projects manage > to deal with now installed artifacts and fix this on flexmojos.... but I see > too much effort for little/no gain. > > VELO > > On Wed, Jul 8, 2009 at 1:12 PM, Collin Peters <[email protected]>wrote: > > > > > 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-ba... > > . > > 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-dis... > > > 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/ -~----------~----~----~----~------~----~------~--~---
