>
> It works with the parent build, but breaks with the module build.
> When I build the war module the ${build.finalName} property gets
> replaced with ${project.artifactId} rather than the actual artifact
> file name. I think something must have changed with the way maven
> handles properties, but I don't know enough about maven (or Flexmojos)
> to offer a better explanation. I'll add an issue to JIRA for this and
> do my best to clean up the example you looked at so it illustrates the
> behavior. For myself, I will simply use maven 2.0.10.
>
Hmmm... that's weird. Velo might know better about the differences or even
already have a general strategy of dealing with 2.0.9 vs 2.2.x issues. I
think I remember seeing some other threads on the group where that was
discovered to be the root cause of their problems, but I don't remember
offhand if they were ever resolved (other then by, like you, reverting back
to 2.0.9/10).
This is the only part of your reply that I don't agree with. The
> flexmojos plugin behaves differently than other standard maven
> packaging plugins and I think the way the flexmojos plugin behaves
> isn't the way most people would expect.
>
> If I'm not using the flexmojos plugin I can get my entire project
> (about 12 modules) from svn and run 'clean package' on the parent pom
> with a completely empty (local) maven repository. It will build
> successfully and the resulting .ear and .war files will include
> artifacts that are created during the parent project build. The
> artifacts are never installed to the local repository in this process
> and, as far as I know, this is the expected behavior.
>
> It should be possible to build and package a project from the parent
> module without having to install artifacts to the local repository.
> I'll argue that if installing to the local repository is a requirement
> (and the expected behavior) after packaging, then maven would only
> have one phase for the process rather than two. This is not the
> case. Please note that I am specifically talking about a full project
> build. In the case of building modules individually, flexmojos
> behaves as I would expect.
>
> To give an example of how the behavior of flexmojos could be
> problematic, consider the following scenario:
>
> 1. DEV gets entire project (parent + all modules) from SVN
> 2. DEV runs mvn clean install
> 3. DEV makes minor re-factoring change
> 4. DEV runs mvn clean package
> 5. DEV tries to manually deploy artifact to web / app server
>
> In the above case, if the flexmojos wrapper task is wrapping an
> external artifact (swf-project in the example we've been using) the
> developer will end up with an artifact that is stale. The wrapped
> artifact would be from the build executed in step 2, not the build
> executed in step 4. All other packaging plugins (ie: maven-ear-
> plugin) would contain artifacts from the build executed in step 4.
I think I understand what you're getting at now. The wrapper does *always*
query the repository for wrapperArtifact regardless of package/install
command, so your thought experiment would provide potentially unexpected
results for a lot of users. I'm not very familiar with how the other
plugins you mention deal with this, but it may just be because they rely on
the normal maven dependency resolution instead of doing their own thing with
config like the wrapper now does. The first patch I submitted used a normal
maven dependency dropped right into the flexmojos plugin declaration, but
users found it confusing so we reverted to doing things this way instead.
If this is a side-effect of that change, then maybe we can find some middle
ground that can be both clear and reliant on normal maven dependency
resolution.
I've added two issues to JIRA:
>
> https://issues.sonatype.org/browse/FLEXMOJOS-184
> https://issues.sonatype.org/browse/FLEXMOJOS-185
>
> I don't file too many bug reports, so they may need a little
> moderating. I missed the component on one and probably set the
> priority too high on the other :-o
>
They look good to me. Especially, 185... it certainly should not behave
that way.
--David
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
