Patch: Speed up NetBeans IDE execution

[Jaroslav Tulach]

After bit of experimenting I concluded that the best way is to trigger the
build of all dependencies only when it is needed. I reported issue to make
it standard behavior in NetBeans:
https://netbeans.org/bugzilla/show_bug.cgi?id=251142

Until destiny of issue #251142 is decided, here is my modification of mx
system:

$ hg diff mxtool/mx.py
diff -r a47eb3db81bb mxtool/mx.py
--- a/mxtool/mx.py      Thu Mar 12 11:42:16 2015 +0100
+++ b/mxtool/mx.py      Fri Mar 13 09:52:13 2015 +0100
@@ -4170,6 +4170,31 @@
     out.open('project', {'name' : p.name, 'default' : 'default', 'basedir'
: '.'})
     out.element('description', data='Builds, tests, and runs the project '
+ p.name + '.')
     out.element('import', {'file' : 'nbproject/build-impl.xml'})
+    out.open('target', {'name' : '-post-init'})
+    out.open('pathconvert', {'property' : 'comma.javac.classpath',
'pathsep' : ','})
+    out.element('path', {'path' : '${javac.classpath}'})
+    out.close('pathconvert')
+
+    out.open('restrict', {'id' : 'missing.javac.classpath'})
+    out.element('filelist', {'dir' : '${basedir}', 'files' :
'${comma.javac.classpath}'})
+    out.open('not');
+    out.element('exists');
+    out.close('not');
+    out.close('restrict')
+
+    out.element('property', {'name' : 'missing.javac.classpath', 'refid' :
'missing.javac.classpath'})
+
+    out.open('condition', {'property' : 'no.dependencies', 'value' :
'true'})
+    out.element('equals', {'arg1' : '${missing.javac.classpath}', 'arg2' :
''})
+    out.close('condition')
+
+    out.element('property', {'name' : 'no.dependencies', 'value' :
'false'})
+
+    out.open('condition', {'property' : 'no.deps'})
+    out.element('equals', {'arg1' : '${no.dependencies}', 'arg2' : 'true'})
+    out.close('condition')
+
+    out.close('target')
     out.open('target', {'name' : '-post-compile'})
     out.open('exec', {'executable' : sys.executable})
     out.element('env', {'key' : 'JAVA_HOME', 'value' : jdk.jdk})

It will check for existence of all JARs needed by javac on classpath and if
one of them is missing, it will trigger the deep dependency build.
Otherwise it does the local one.
-jt


2015-03-12 11:05 GMT+01:00 Doug Simon <doug.simon at oracle.com>:

>
> > On Mar 12, 2015, at 5:42 AM, Jaroslav Tulach <jaroslav.tulach at gmail.com>
> wrote:
> >
> > 2015-03-11 20:51 GMT+01:00 Doug Simon <doug.simon at oracle.com>:
> > Your suggestion sounds good. I’ll have to defer to you as to how we
> generate project configurations to offer those different menu options.
> >
> > I checked with Tomáš and currently there is no way to influence pop-up
> menu of this type of project from its configuration files. Tomáš can fix
> that for NetBeans 8.1 - or at least make "Build with Dependencies" action
> available as is common in Maven projects...
> >
> > Meanwhile I can only hack with various Clean/Build tricks. My favourite
> one is:
> >
> > 1. Build/Clean action operates only locally as well as other actions,
> like Run, Test.
> > 2. Clean action marks the project to be eligible for complete rebuild so
> subsequent action (like Build) builds with all dependencies.
> >
> > A bit magical, but it optimizes for the main usecase - e.g. fast work
> with single project. Unless there are objections, I can prepare the patch.
>
> Ok, sounds good.
>
> > -jt
> >
> > I have experience with Eclipse (where saving a file is the only explicit
> build step I need*).
> > * in theory - unfortunately Eclipse has its own issues which is only
> resolved by refreshing a few times.
>
> I’ve seen that and if I recall correctly we disable it as well. One reason
> we disable it is that it bypasses ant altogether (according to my
> understanding of http://wiki.netbeans.org/FaqCompileOnSave) which means
> the post-compile actions we generate into build.xml are ignored. This makes
> the compile-on-save behavior different from Eclipse (where post compile
> actions are run) and we wanted to avoid the confusion. So yes, this means
> you effectively should always run ‘mx build’ on the command line before
> running the VM if you’re developing with NetBeans.
>
> -Doug
>
>
> >
> > PS: NetBeans has such mode as well, but I usually turn it of because its
> occasional quirks.
> >
> > > On Mar 11, 2015, at 7:08 PM, Jaroslav Tulach <
> jaroslav.tulach at gmail.com> wrote:
> > >
> > > It might be better to leave the choice in hands on the person that
> does the build. E.g. have two menu items in project pop-up menu to "Build"
> and "Build with Dependencies" (I am trying to find out if that is
> possible). Or do something different on "Build" vs. "Clean and Build" (I
> know how to do it). Or leave "Clean and Build" action fast. But "Clean"
> followed by "Build" do the complete build with dependencies (I know how to
> do it as well).
> > >
> > > Choosing the dependency-build style when invoking mx.sh seems to
> global and too early too me.
> > > -jt
> > >
> > >
> > > 2015-03-11 12:53 GMT+01:00 Doug Simon <doug.simon at oracle.com>:
> > > Hi Jaroslav,
> > >
> > > > On Mar 11, 2015, at 11:52 AM, Jaroslav Tulach <
> jaroslav.tulach at gmail.com> wrote:
> > > >
> > > > Hi.
> > > > I am using Graal with NetBeans and found various operations (rebuild
> of a
> > > > single module, execution) too slow. I believe the reason is that
> NetBeans try
> > > > to ensure all dependant projects are up-to-date. I guess this is
> unnecessary.
> > >
> > > Ideally, an IDE should ensure all dependents are up to date when the
> project they depend on changes. Unfortunately, this is a little slow in
> Netbeans since it out-souces the updating to ant which isn’t very
> incremental.
> > >
> > > > The usual workflow is to do:
> > > >
> > > > $ ./mx build
> > > >
> > > > and only then rebuild individual parts in the IDE, right?
> > >
> > > With your patch, this will become the *required* workflow for NetBeans
> users. The ‘mx build’ step will probably take as long NetBeans doing the
> updating itself but at least it is an explicit step as opposed to occurring
> each time one edits a file in NetBeans. In Eclipse, this is all somewhat
> faster given that it does more precise propagation of updates.
> > >
> > > I propose making this setting conditional on a variable in mx/env.
> Something like:
> > >
> > > NETBEANS_UPDATE_DEPENDENTS=false
> > >
> > > How does that sound? Of course, the variable would only have an effect
> when running ‘mx netbeansinit’.
> > >
> > > -Doug
> > >
> >
> >
>
>