[
http://jira.codehaus.org/browse/MNBMODULE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=242038#action_242038
]
Jesse Glick commented on MNBMODULE-118:
---------------------------------------
Not sure what "duplicate code in the jnlps" refers to. <java> occurs only in
master.jnlp. The XML headers occur in both master.jnlp and branding.jnlp but
this is trivial. <information> in branding.jnlp is likely not used by anything;
it is just there to satisfy the DTD. Removing these few lines is not worth code
changes.
Performance of reading/writing *.jnlp is practically irrelevant here.
nbm:webstart-app is quite slow, but AFAIK this is almost entirely due to JAR
signing.
Creating *.jnlp structurally (as DOM) would be cleaner, probably result in
better formatting, and would make it marginally easier to support conditionally
present elements and attributes. Safety is not an issue since we anyway
validate the results against DTD.
The main reason the mojo does text substitution is that it supports a custom
<masterJnlpFile> with variable interpolation - so you still need to somehow
load the template (default or custom), do substitutions, then serialize it. The
substitution stage would seem to be most easily done on a text representation,
especially in the case of variables like ${jnlp.resources} which are replaced
by a whole XML fragment. It could be done on a DOM tree with some more work:
either parse the template first and look for text nodes containing the var; or
substitute the var textually with some <placeholder/>, parse, and then replace
this DOM node.
> 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
