[ 
http://jira.codehaus.org/browse/MNBMODULE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesse Glick closed MNBMODULE-115.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 3.4

6.0.10/download.html#downloading clarifies that the href attribute is useful 
specifically for the application descriptor, which (unlike extensions) is not 
retrieved originally by javaws. In fact it seems to work fine for running from 
cache, after javaws -import. So including it in just the master in revision 
13024. Making corresponding change in Ant harness in core-main #164b0d283c52.

"no codebase has [...the] flexibility of moving files while testing" - 
potentially yes, but the hardcoded codebase is only used in the unpacked *.jnlp 
under ${basedir}/target, which would not be distributed. Once packed into the 
WAR and installed in the repo, it is portable. If you have specialized needs, 
you can always postprocess the results. Anyway this is off topic here.

> 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


Reply via email to