-
Enhancement
-
Resolution: Fixed
-
P2
-
6, 7
-
b13
-
generic
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2199010 | 7 | Thomas Ng | P2 | Resolved | Fixed | b64 |
We can implement versioning much as we have now, except perhaps without the ability to use wildcards in version id's, and we can do this without requiring enhanced download protocol if we just define in the specification the conventions we now use in the servlet for naming versions.
We can also implement jar-diff the same way, if we define the naming convension for jardiff files in the spec.
Similarily, we can implement pack200, by allowing us to trigger downloading a jar whose extension is listed as .jar.pk.gz, .jar.gz, .jar.pk, and assume it's contents are as it's extension implys.
What build is this targeted for? Please can you mark this accordingly?
Craig
We can also implement jar-diff the same way, if we define the naming convension for jardiff files in the spec.
Similarily, we can implement pack200, by allowing us to trigger downloading a jar whose extension is listed as .jar.pk.gz, .jar.gz, .jar.pk, and assume it's contents are as it's extension implys.
What build is this targeted for? Please can you mark this accordingly?
Craig
- backported by
-
JDK-2199010 support versioning and pack in plugin and webstart without need for version based download protocol
-
- Resolved
-
- duplicates
-
JDK-6566558 pack200 and version download protocol support without server-side requirement
-
- Closed
-
- relates to
-
JDK-6672250 Regression: new jnlp.packEnabled property breaks sophisticated applets using LiveConnect
-
- Closed
-
-
JDK-6665053 Access denied when read jnlp.packEnabled jnlp.packEnabled property
-
- Closed
-