On Wed, May 8, 2019 at 8:15 AM Jaroslav Tulach <[email protected]> wrote:
> Dne středa 8. května 2019 7:30:55 CEST jste napsal(a): > > On Wed, May 8, 2019 at 6:25 AM Jaroslav Tulach < > [email protected]> > > > > wrote: > > > Dne úterý 7. května 2019 2:46:19 CEST, Damjan Jovanovic napsal(a): > > > > Hi > > > > > > > > I am trying to develop some improvements to Java Free-Form projects, > > > > such > > > > as auto-detection of the Java version and sources classpath from the > Ant > > > > file, but I am struggling to import Ant into the java/java.freeform > > > > > > module. > > > > > > > In fact, it seems NetBeans goes to great lengths to avoid ever using > Ant > > > > APIs directly: in the whole repository, org.apache.tools.ant.Project > is > > > > only ever imported in extide/o.apache.tools.ant.module/src-bridge. > > > > > > > > Are NetBeans modules not allowed to use Ant directly? Why? > > > > > > Hello Damjan, > > > I guess it is for historic reasons. In the early stages, when Ant was > > > developed hectically, it wasn't very compatible from the Java API > point of > > > view. This separation might have been primarily a shield against > > > incompatible > > > changed. > > > > > > The other aspect is that the Ant support can run with any installed > > > version of > > > Ant, not just the bundled one. I think. > > > > Thank you. That makes sense. > > > > I now have a different problem. > > > > I found NetBeans's Ant parser in > > > extide/o.apache.tools.ant.module/src/org/apache/tools/ant/module/api/support > > /TargetLister.java [1] > > and patched > > > java/java.freeform/src/org/netbeans/modules/java/freeform/ui/SourceFoldersPa > > nel.java [2] > > to use it to extract Ant targets, search the child XML nodes of the > > "compile" target for the "javac" task, and extract more information (eg. > > Java version) from it. It worked, but the node attributes I get are from > > before Ant's variable substitution, ie. something like "${java.version}" > > instead of "1.7". > > > > Then I patched [1] to perform variable substitution on targets, but it's > > like the patched JAR is not getting used. The JULI logging I added in [1] > > isn't performed, and when I step into it with jdb, the line numbers are > > wrong, and calling > > TargetLister.class.getProtectionDomain().getCodeSource().getLocation() > from > > [2] definitely gives me the right path for [1] and disassembling that > class > > with javap shows the changes I made, yet it's like a completely different > > class is getting used... > > Who knows? Maybe it is the startup cache: http://wiki.netbeans.org/ > StartupCache - it is usually cleaned by "ant build" in a module, but > something > may be broken. `touch nbbuild/netbeans/**/.lastModified` files may help. > > Thank you. That at least showed what I was doing wasn't working; I've been using NetBeans 10.0 and selectively overwriting modules with patched modules built from Git. If I build the whole of NetBeans from Git instead, it fails on "Activating Java SE..." and complains it's running on JRE, which it isn't. Adding --jdkhome=/usr/local/openjdk8 makes it exit during startup without any errors. This is without my changes, on commit e9ecefdbe6702af327fd89d4ad0233d0565b2e48, FreeBSD 11.2 amd64 OpenJDK 1.8.0_202. Let me try build 10.0 itself (release100 branch right?) and if that works, then git bisect.
