You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Nigel Daley (JIRA)" <ji...@apache.org> on 2007/08/01 06:06:53 UTC
[jira] Updated: (RIVER-161) Coalesce jars from multiple source dirs
while retain current Manifest Classpath semantics
[ https://issues.apache.org/jira/browse/RIVER-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nigel Daley updated RIVER-161:
------------------------------
Description:
Bugtraq ID [6227228|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6227228]
"I would like to have an additional wrap method on
com.sun.jini.tool.JarWrapper that takes java.io.File arguments instead
of String arguments and that doesn't have the limitation that all jar
files to be wrapped are in the same directory. In the Class-Path entry
of the Manifest files the referenced jar files should be listed as being
in the same directory (as required by specification).
This RFE is the result of the future ability of Seven to serve jar files
that seems (from the requestor perspective) to be in the same directory
but are served from different locations on the filing system. I can work
around this by moving all jar files involved to a temp directory, apply
jar wrapping over there, move the wrapped jar file to the final location
and remove the temp directory, but I would prefer a better way of doing
this."
was:
Bugtraq ID [6227228 |http://bugs.sun.com/bugdatabase/view_bug.do?bug_id= 6227228]
"I would like to have an additional wrap method on
com.sun.jini.tool.JarWrapper that takes java.io.File arguments instead
of String arguments and that doesn't have the limitation that all jar
files to be wrapped are in the same directory. In the Class-Path entry
of the Manifest files the referenced jar files should be listed as being
in the same directory (as required by specification).
This RFE is the result of the future ability of Seven to serve jar files
that seems (from the requestor perspective) to be in the same directory
but are served from different locations on the filing system. I can work
around this by moving all jar files involved to a temp directory, apply
jar wrapping over there, move the wrapped jar file to the final location
and remove the temp directory, but I would prefer a better way of doing
this."
> Coalesce jars from multiple source dirs while retain current Manifest Classpath semantics
> -----------------------------------------------------------------------------------------
>
> Key: RIVER-161
> URL: https://issues.apache.org/jira/browse/RIVER-161
> Project: River
> Issue Type: New Feature
> Components: com_sun_jini_tool
> Reporter: Nigel Daley
> Priority: Minor
>
> Bugtraq ID [6227228|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6227228]
> "I would like to have an additional wrap method on
> com.sun.jini.tool.JarWrapper that takes java.io.File arguments instead
> of String arguments and that doesn't have the limitation that all jar
> files to be wrapped are in the same directory. In the Class-Path entry
> of the Manifest files the referenced jar files should be listed as being
> in the same directory (as required by specification).
> This RFE is the result of the future ability of Seven to serve jar files
> that seems (from the requestor perspective) to be in the same directory
> but are served from different locations on the filing system. I can work
> around this by moving all jar files involved to a temp directory, apply
> jar wrapping over there, move the wrapped jar file to the final location
> and remove the temp directory, but I would prefer a better way of doing
> this."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.