[PATCH] jlink task

[Matthew Kuperus Heun <ma...@gaerospace.com>]

Greetings:

This is my first contribution to ant.  I hope it is helpful to 
others.  Judging by recent posts, there may be some interest.  It may 
be helpful to consider merging (no pun intended) some of the 
functionality of jlink with the jar task or vice versa.  I'm open to 
suggestions.

I apologize for not providing diffs here: I don't have a means to 
generate those.  Sorry.

This task is based on code by Patrick Beard.

Description:

Links entries from sub-builds and libraries.

The jlink task can be used to build jar and zip files, similar to the 
jar task. However, jlink provides options for controlling the way 
entries from input files are added to the output file. Specifically, 
capabilities for merging entries from multiple zip or jar files is 
available.

If a mergefile is specified directly (eg. at the top level of a 
mergefiles pathelement) and the mergefile ends in ".zip" or ".jar", 
entries in the mergefile will be merged into the outfile. A file with 
any other extension will be added to the output file, even if it is 
specified in the mergefiles element. Directories specified in either 
the mergefiles or addfiles element are added to the output file as 
you would expect: all files in subdirectories are recursively added 
to the output file with appropriate prefixes in the output file 
(without merging).

jlink will fail if duplicate entries are found in the mergefiles.

jlink ignores META-INF directories in mergefiles. Users should supply 
their own manifest information for the output file.

It is possible to refine the set of files that are being jlinked. 
This can be done with the includes, includesfile, excludes, 
excludesfile, and defaultexcludes attributes on the addfiles and 
mergefiles nested elements. With the includes or includesfile 
attribute you specify the files you want to have included by using 
patterns. The exclude or excludesfile attribute is used to specify 
the files you want to have excluded. This is also done with patterns. 
And finally with the defaultexcludes attribute, you can specify 
whether you want to use default exclusions or not. See the section on 
directory based tasks, on how the inclusion/exclusion of files works, 
and how to write patterns. The patterns are relative to the base 
directory.

The Details:

I have attached three .java files that provide the source code for 
jlink.  Also, I have attached a first cut at some html documentation 
for the task.

Comments and bug reports are welcome.

Cheers,

Matt

Re: [PATCH] jlink task

[Matthew Kuperus Heun <ma...@gaerospace.com>]

OK.  I'll grab the latest version and re-post my jlink patch.

Cheers,

Matt


>At 4:51 PM -0400 9/6/00, Matthew Kuperus Heun wrote:
>>jlink will fail if duplicate entries are found in the mergefiles.
>
>I've fixed this in the latest version of jlink. The first entry 
>found will be used, subsequent entries will be ignored.
>
>- Patrick
>--
>
>// Patrick C. Beard
>// Java Runtime Enthusiast -- "Will invoke interfaces for food."
>// mailto:beard@netscape.com

-- 


--

Matthew Kuperus Heun
Global Aerospace Corporation
+1 (978) 922-7115 (voice & fax)
<http://www.gaerospace.com>
<ma...@gaerospace.com>

Re: [PATCH] jlink task

[Patrick Beard <be...@netscape.com>]

At 4:51 PM -0400 9/6/00, Matthew Kuperus Heun wrote:
>jlink will fail if duplicate entries are found in the mergefiles.

I've fixed this in the latest version of jlink. The first entry found 
will be used, subsequent entries will be ignored.

- Patrick
-- 

// Patrick C. Beard
// Java Runtime Enthusiast -- "Will invoke interfaces for food."
// mailto:beard@netscape.com

Re: Nightly Builds Have Old Source Code

[Paul Hodgetts <pa...@zzyzxtek.com>]

Stefan Bodewig wrote:

 > >>>>> "PH" == Paul Hodgetts <pa...@zzyzxtek.com> writes:
 >
 >  PH> I was just trying to update to the latest nightly build version,
 >  PH> and it looks like the nightly builds dated 08-Sep-2000 03:31
 >  PH> contain at least some old source code.
 >
 > I've just checked the nightly build of 2000-09-11 (looked into tar.gz
 > only though). Conor's and my latest commits are missing, everything
 > else looks fine.

2000-09-10 was OK as well.  But 2000-09-08 had an old EjbcHelper.java,
prior to all the rework.  Maybe something glitched on that day's build?
FWIW, I usually grab the .zip versions.

Thanks for checking,
-Paul Hodgetts

Re: Nightly Builds Have Old Source Code

[Stefan Bodewig <bo...@bost.de>]

>>>>> "PH" == Paul Hodgetts <pa...@zzyzxtek.com> writes:

 PH> I was just trying to update to the latest nightly build version,
 PH> and it looks like the nightly builds dated 08-Sep-2000 03:31
 PH> contain at least some old source code.

I've just checked the nightly build of 2000-09-11 (looked into tar.gz
only though). Conor's and my latest commits are missing, everything
else looks fine.

Stefan

Nightly Builds Have Old Source Code

[Paul Hodgetts <pa...@zzyzxtek.com>]

I was just trying to update to the latest nightly build version,
and it looks like the nightly builds dated 08-Sep-2000 03:31
contain at least some old source code.

For example, the EjbcHelper task now looks to be the old version
when the paths were just String, not Path, and before it checked
build.compiler for Jikes, etc.  I don't know what else is old,
since I stopped there until I can compile a current version.

Perhaps someone needs to take a look at the nightly build process
and make sure it is checking out the very latest source files for
inclusion in the nightly build zips.

Thanks,
Paul Hodgetts