[
http://jira.codehaus.org/browse/MNBMODULE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=242046#action_242046
]
Gabriele Kahlout commented on MNBMODULE-118:
--------------------------------------------
>Offering an overridable template with substitutions, as now, seems to make
>>more sense.
I think the ultimate feature with maven would be to have one pom.xml (and at
most one settings.xml for private settings) with all configuration. Like now
many parameters are factored (description, title, website, ...). Using a jnlp
to specify those (again) is duplication. I don't know how many other 'obscure
sections' one would want to add, that cannot be cleanly specified through the
pom.xml. Do you have a concrete case? =)
><codebase> parameter is deprecated and should not be used in 3.4
I use this to specify my localdeployment and webdeployment codebases. What else
(non-manual and not providing two duplicate .jnlps with the only difference of
the codebase) do you expect me to do without it?
So in the end you want to close this refactoring?
We agreed on some sections, but I don't know if that is still worth the change
for you.
> 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
