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
