[
http://jira.codehaus.org/browse/MNBMODULE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241975#action_241975
]
Gabriele Kahlout commented on MNBMODULE-115:
--------------------------------------------
sorry for the confusion. Why isn't there consistency between these 2?
(rhetoric).
Anyway w/o it simply means that all clients with a jre before 1.6.18 (and there
are many target customer machines) will not work. In later releases problems
like the one discovered here occur:
http://osdir.com/ml/java-dev/2010-10/msg00075.html (ctrl+f: href).
Finally, the patch generates the jnlps (the master and the modules) in memory,
instead of having 2 files in the resources folder and making copies of them,
replacing specific variables with values passed from the program. I believe
(for the reasons listed earlier including refactoring duplication btw the two
files) to be a good refactoring (not enhancing outside behavior), but it
particularly relates to this patch since without it one would have to introduce
2 extra jnlps which are copies of the current ones, but with the href
attribute, and the appropriate java version.
> Missing href attribute in maven generated jnlps
> -----------------------------------------------
>
> Key: MNBMODULE-115
> URL: http://jira.codehaus.org/browse/MNBMODULE-115
> Project: Maven NetBeans Module Plugin
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Gabriele Kahlout
> Assignee: Jesse Glick
> Priority: Minor
> Attachments: hrefcomply.diff
>
>
> Creating an jws ant project (even in nb 7) with a codebase (one is given the
> option to exclude the codebase choosing to be 1.6.0_18+ only compatible)
> generates a launch.jnlp file with the href attribute as required by the jnlp
> specification.
> Maven created projects on the other hand include codebase but not the href
> and thus don't comply to the 1.6+ standard they claim in the same jnlp, but
> only to the 1.6.18+ standard, which then doesn't require the codebase
> attribute, which makes the difference of not needing to hard-code the
> location at development time (since the .jnlp is executed from the dir other
> referenced files are).
> Hence It's preferred to correct the version issue, and extend the same
> options to maven users (as is for ant).
> I propose a patch which detects whether the codebase is specified and if so
> includes it along with the href. In case it's not specified it will not
> include the href and will set the java version to 1.6.0_18+.
> This change is best accompanied with building the jnlp/xml dynamically
> (instead of having two file versions for each file, on disk and copy them).
> Should be even faster (in memory). It should also be more type-safe since the
> only place there are unsafe strings used to retrieve values is the pom.
> BTW: even the generated jws for ant is buggy. The j2se remeains set to 1.5+
> although without codebase requires 1.6.0_18+. It probably works for most
> developers when they test it, because they are likely to have 1.6.0_18+
> anyway.
> finally I've attached the diff to the trunk. However the trunk is broken!
> Try it before applying this patch. There's an issue with
> netbeans.jnlp.fixPolicy (both on mac and windows)
--
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
