[
http://jira.codehaus.org/browse/MNBMODULE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=242141#action_242141
]
Jesse Glick commented on MNBMODULE-118:
---------------------------------------
"Do you have a concrete case?" - <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. It is simpler and more
flexible to let the user specify an alternate *.jnlp template with the desired
configuration.
"specify my localdeployment and webdeployment codebases" - off topic for this
issue, but as of MNBMODULE-104 this is unnecessary. The local files will have
the actual local path for quick testing, and the WAR will use the JNLP servlet
to calculate the codebase on the fly.
"if that is still worth the change for you" - if the refactoring preserves
existing usage of <masterJnlpFile> but improves formatting it could be useful.
Otherwise I would probably not bother.
> 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
