[
http://jira.codehaus.org/browse/MNBMODULE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=242042#action_242042
]
Gabriele Kahlout commented on MNBMODULE-118:
--------------------------------------------
>what "duplicate code in the jnlps" refers to
<info> and the <title><vendor><description> children.
<security> (it's there in the current versions, but I'm not sure if its
inherited from application-desc.
>easier to support conditionally present elements and attributes
yes, especially href and codebase.
>Safety is not an issue since we anyway validate the results against DTD.
you mean manually?
>so you still need to somehow load the template (default or custom), do
>>substitutions, then serialize it.
Could just read it as an xml file and using the instance variables we use to
generate jnlps (same string names) could manipulate as done in the rest of the
code.
${jnlp.resources} could be handled as currently. After all is written use
interpolation and replace this.
For another issue, I'd deprecate <masterJnlpFile> and have all variables
passed/overriden from the pom.xml (like codebase for now). Consistent interface
=).
> 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
