I have recieved an off-list email from the original writers and have found out the processEntry piece was there for OS-issues. I'll just make it an optional attribute.
IMHO, jlink isn't a bad addition, I've used it a few times myself... but maybe I've missed additions to zipfileset. You could of course currently simulate jlink merging of jars by unjar'ing all jars and then jar'ing back up, but this is really, really slow. When I submit stuff in for merging manifests, however, it should become a bit more unique. -Brian > -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 14, 2001 4:17 AM > To: [EMAIL PROTECTED] > Subject: Re: jlink code question > > > First off all, the <jlink> task is a nice example of why we should be > careful with what we add to Ant. It seems it is more or less > unmaintained, there are some known issues and no one of the committers > really feels comfortable enough with the code to dive into it. Even > more, most of its functionality has been superseded by the nested > <zipfileset> element of <zip> and friends. > > It has been me, who committed the task, so I'm just blaming myself. > > On Tue, 13 Nov 2001, Brian Deitte <[EMAIL PROTECTED]> wrote: > > > Hi all, I'm rewriting a good chunk of the jlink task (I needed it to > > handle meta-inf and manifests) > > what are you trying to do with it, that you couldn't do with <jar>? > > > In jlink.processEntry(), there is a chunk of code that renames files > > that aren't named ".class" to ".class" if possible. Was there a > > "Java bug" reasoning behind this? > > Honestly, I have no idea. > > > I'd rather not mess with the files when merging the jars. > > I agree with this, but as I don't know why the code is in there in the > first place ... > > Stefan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
