[
http://jira.codehaus.org/browse/MNBMODULE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=242149#action_242149
]
Gabriele Kahlout commented on MNBMODULE-118:
--------------------------------------------
><shortcut>, for example. There is no existing POM metadata that could
>meaningfully be interpreted to say whether or not you want a menu shortcut to
>be created in a JNLP app
This would be fit nicely under <execution>
<id>webstart</id>..for the plugin just as it fits nicely in the jnlp. They are
both specified in an xml structure. I expect pom.xml to wrap all other
configuration files, including this.
>if the refactoring preserves existing usage of <masterJnlpFile> but >improves
>formatting it could be useful.
It does, as described above.
> Refactoring jnlp generation
> ---------------------------
>
> Key: MNBMODULE-118
> URL: http://jira.codehaus.org/browse/MNBMODULE-118
> Project: Maven NetBeans Module Plugin
> Issue Type: Improvement
> Affects Versions: 3.4
> Reporter: Gabriele Kahlout
> Assignee: Jesse Glick
> Priority: Minor
>
> This refactoring generates the brandingToken.jnlp and the modules.jnlp
> dynamically instead of having two file versions for each file, on disk and
> copy them.
> Right now there are are 2 jnlps with ${} variables set which are copied into
> memory, replacing these variables with values and then writing them to new
> jnlps.
> This practice results in duplicate code in the jnlps (<information/>,
> <java/>, xml and jnlp declaration).
> In the refactoring this duplication is eliminated since generating the first
> jnlp, the second one only removes and replaces what it doesn't need from the
> previous.
> It is also type-unsafe since the ${} variables are strings both in the java
> code and in the jnlps.
> In the refactoring such variables are referred to by java variables (after
> the first text initialization), and hence the code is type-safe, checked at
> compile-time since there is only one string for each variable and it's always
> references with its variable name.
> Supporting jnlps of different structure requires more code duplication. For
> instance to include jnlps that declare a codebase and href attribute (and
> java version) one would either have to create duplicate files in the
> resources folder and use those when needed, or would have to load them in
> memory and delete the unwanted declarations, possibly through a dom
> representation.
> In the refactoring everything is already in dom java representation for the
> original purpose of creating any jnlp in the first place. Removing and adding
> elements becomes a matter function calls to the dom interface.
> Reading the files from disk into memory, modify them and finally write new
> ones back to disk should be slower than generating one in memory directly to
> specification and then write to disk. Likewise only one jnlp content is read
> into memory, versus 2 in the current implementation.
> I had attached the refactoring against a previous trunk in another bug. If
> you share the motives of this refactoring, as described above, I'll checkout
> the latest trunk and apply the refactoring to it. Finally, I'll upload the
> patch.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
