> > First, v3.0.0 was using a default template from somewhere and > generating a .html file for me. I didn't realize I have to create my > own template with v3.3.0 until I saw the index.jsp in the examples. I > do have to create my own template now, right?
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. Reason why the old swf packaging methods don't work with wars: If you automatically re-extract a template into one of the webapp intermediary directories, you run the risk of copying over one of the user's files if there are any name clashes between the two. To avoid that, you would either have to provide all kinds of annoying exception cases or error conditions that begin to make the whole process unpredictable. For swf projects, there aren't any pre-existing resources to merge with the wrapper, so the fresh provided template could be injected during every build process without any merger worries. Second, the version of Maven I am using (2.2.1) filters resources > inconsistently depending whether or not a build is executed from a > parent pom (usually what I do in my IDE - IDEA) or if build is > executed on a single module (the way my continuous integration server > does it). > 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? Third, the wrapper goal doesn't seem to work properly when I don't use > the default artifact file names for my modules. I append a version > control number to my file names. I modified the example Marvin > provided and added comments inline in the pom of the war-project > module. > After a quick look at your example: - 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. - The parameters config is ignored on non-swf projects since it is taken from the wrapperArtifact. - 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. - If I remember the maven version explanation presentation I've seen properly, 2.2+ tries to be backwards compatible with the 2.0.9 derivatives as much as possible but doesn't make guarantees (but things change and my memory certainly fails from time to time, so I could be way off here). The flexmojos plugin was originally developed targeting the 2.0.9 line, so there could certainly be some assumptions that break in the 2.2.x releases. I'm not familiar of where the differences lie unfortunately as I've not had too much opportunity to work with the 2.2 line releases. You should probably create a jira issue for that too. Well, that was a lot longer than I originally anticipated. Hopefully I didn't miss any of the comments in your example project.. --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/ -~----------~----~----~----~------~----~------~--~---
