[
http://jira.codehaus.org/browse/MNBMODULE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=242029#action_242029
]
Gabriele Kahlout commented on MNBMODULE-115:
--------------------------------------------
>So including it in just the master
I still don't understand why you don't want to have spec compliant code.
Do we need a case (at a customer machine) before complying to the standards?
What if between one jre and another (or simply in the jre platform
implementation of one client) there is an issue we don't know of?
Programming to the specs implementing clients (and Java) are excused to depend
on the href for all sort of things they might or not document. The only safe
thing we could do is comply to the specs, as the contract btw us and them that
they will run our program to the specs expectations.
Likewise any client (even application) can program to the specs and parse the
jnlp for instance. You shouldn't break such expectations. I believe all jnlps
must be valid/comply with the specified dtd. This is helpful for everyone.
Regarding the codebase, again consistent interface issue. Why is no codebase
offered for javase projects and not for nbm?
> 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
> Fix For: 3.4
>
> 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
