Will there be a recursive Jar: content mechanism so that there can be a single
file object representing an entire application and all of its dependencies?
Gregg Wonderly
Sent from my iPhone
> On Dec 7, 2015, at 10:46 PM, Alan Bateman wrote:
>
>> On 07/12/2015 17:18, Stephane Epardaud wrote:
>
To summarize, I have thus far seen these two needs on the list:
1) The need to specify a list of jar modules by name. This is to support
identifying what modules out of a set need to loaded. An example use case
would be the "target" directory of a Maven project, where more than one
module artifact
On 12/07/2015 11:46 AM, Alan Bateman wrote:
On 07/12/2015 17:18, Stephane Epardaud wrote:
Hi,
When there is a -modulepath argument, is it a path in the Unix sense?
With a list of File.pathSeparator-separated folders?
Ceylon produces `.car` files instead of `.jar` files, but they're really
zi
On 07/12/2015 17:18, Stephane Epardaud wrote:
Hi,
When there is a -modulepath argument, is it a path in the Unix sense?
With a list of File.pathSeparator-separated folders?
Ceylon produces `.car` files instead of `.jar` files, but they're really
zip files like jars. Will Java examine the file t
Hi,
When there is a -modulepath argument, is it a path in the Unix sense?
With a list of File.pathSeparator-separated folders?
Ceylon produces `.car` files instead of `.jar` files, but they're really
zip files like jars. Will Java examine the file type to determine that
it's a zip file, or will i
