Hi David,
Thanks for looking at my example. I'll add a few comments inline.
> The template for war projects by definition now is whatever the war-plugin
> is pointing to for its webapp directory. The provided templates should
> still work for swf projects. I suppose what may make sense is to provide a
> goal that extracts a baseline template into a war project or include one of
> the pre-packaged templates as part of a maven project archetype for
> flexmojos based war projects. The second option would probably be more in
> line with the whole 'maven way' approach, correct me if I'm wrong.
I think the 'new way' is much better than the 'old way' now that I
understand it. I believe having a base template added as part of the
archetype for flexmojos based war projects would be a good way to do
things (it may already - I created all my modules a few months ago).
In fact, I'd say something like the index.jsp in the example Marvin
provided would be sufficient. Of course it would need a few lines of
comments to explain what it's for. When I'm developing I really like
(new) default behavior of adding the .swf to the welcome-file-list in
web.xml.
> Just for clarification... is it on the module or parent build that it's
> breaking? Or what does 'inconsistently' mean here if broken isn't an
> appropriate term?
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.
> If there is no swf artifact in the repository (i.e. 'If you delete the
> 'sandbox' directory from your local repo and execute...'), then the failure
> of mvn package on the war should fail. That's desired behavior. The repo
> acts as the communication gateway between all the different builds and I
> don't think there's supposed be any way around that. Example of why this is
> important: If wrapperArtifact isn't in the repo, is that because I haven't
> built it yet, because I made a typo in the groupId/artifactId, or because
> I'm pointing to an incorrect version? Using the 'artifact created during
> the build' is the purpose of executing on the module's parent project which
> will analyze dependencies and guarantee that a dependency is in the repo
> come the time of its necessity in a later project module build.
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 hope that is a better explanation than I had in the example I
posted.
> There's currently no interaction between the copy and wrapper mojo...
> This really is an oversight on my part as any re-formatting of the copied
> swf's name (i.e. stripVersion) needs to be taken into account when injected
> references to it during the wrapping process. This would need to be
> discussed in much more detail before implementing however, so you could
> create a jira entry to foster said discussion and move things along.
I will add a JIRA issue for this and add a cleaned up version of the
example you looked at as an attachment.
> Well, that was a lot longer than I originally anticipated. Hopefully I
> didn't miss any of the comments in your example project..
I think you covered everything. Thank you for taking the time to
look.
Ryan
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
