On Sat, 27 Jan 2018 at 08:51 Emilian Bold <emilian.b...@protonmail.ch>
wrote:

> Would be nice to also see this bug reported to SUSE so we can reference it
> in the future.
>
> I've looked into this a bit - I think we would need to provide a bit more
information to SUSE/Fedora to help them take some action. Unfortunately I
have not found the root cause yet. I am assuming that Debian-based distros
are OK and fedora-based ones are not, though there is the complication that
Debian has version 1.9 and Fedora 1.10. Neither distro makes many changes
to the stock ant source code.
Fedora applies a patch to remove setting the classpath from the ant.jar
manifest, details here:
http://pkgs.fedoraproject.org/cgit/rpms/ant.git/tree/
Debian has some patches which are to help reproducible builds.
https://packages.debian.org/stretch/ant

So it seems to me the problem lies in the classpath patch.

I have been testing with FC27. If I run ant from the netbeans directory it
fails building the websvc.saas.api module as previously noted; it can't
find the default manifest. This I tracked down to the call to
org.apache.tools.ant.taskdefs.Manifest.getDefaultManifest() (
https://git-wip-us.apache.org/repos/asf?p=ant.git;a=blob;f=src/main/org/apache/tools/ant/taskdefs/Manifest.java;h=483d8c689ce35e28cf5118cc13c4c80c2db99361;hb=HEAD#l786
)
If I re-run ant (without ant clean) I get a different error, which
shouldn't happen. I should get the same error repeatedly.

Also note that the Manifest class is in the same jar as the default
manifest, so, if it were a classpath thing, I can't understand why
Manifest.class is accessible but the default manifest is not.

That's as far as I have got, if anyone has any insights as to how this can
happen please let me know.

Peter

Reply via email to