|
||||||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||||||
- [mojo-dev] [jira] (MWEBSTART-176) Signing of the JNL... Tony Chemit (JIRA)
- [mojo-dev] [jira] (MWEBSTART-176) Signing of th... Nico De Groote (JIRA)
- [mojo-dev] [jira] (MWEBSTART-176) Signing of th... Marek Gregor (JIRA)
- [mojo-dev] [jira] (MWEBSTART-176) Signing of th... Heiko Wiesner (JIRA)
- [mojo-dev] [jira] (MWEBSTART-176) Signing of th... Tony Chemit (JIRA)
- [mojo-dev] [jira] (MWEBSTART-176) Signing of th... James Olsen (JIRA)
- [mojo-dev] [jira] (MWEBSTART-176) Signing of th... Andreas Kuhtz (JIRA)
- [mojo-dev] [jira] (MWEBSTART-176) Signing of th... alex t (JIRA)

I've hacked up a solution for generating a APPLICATION_TEMPLATE.JNLP or APPLICATION.JNLP. It includes a new JnlpInfMojo (derived from the JnlpSingleMojo) which simply chops out undesirable processing from the AbstractJnlpMojo allowing the execution to occur at the prepare-package stage (i.e. before the jar is built).
A patch is attached and an example usage is below. You do this execution in addition to the (in my case) jnlp-single during package. Your mileage may vary if you use something other than jnlp-single.
The patch also includes a LegacyDependencyFilenameStrategy because the ordering of the classifier has changed recently and I wasn't ready to deal with that now.