Snapshot of APIs as of release 10.0

[jtulach]

After each release NetBeans should snapshot its APIs as described at the time of release paragraph. I've just applied the steps to version 10.0 in the git repository:

$ git checkout 10.0
$ ant clean; ant build
$ ant gen-sigtests-release # I had to fix the nbbuild/build.xml a bit to make this work
$ git stash
$ git checkout master
$ git pull
$ git checkout -b SnapshotOfAPIsAsOfRelease100
$ git stash pop
$ git add .
$ git commit -m "Snapshot of APIs as of 910bd74bf46d079e49925f702432c74d54ec705c (tag: 10.0-vc5, tag: 10.0, release100)"

You can find the result in this request. Ideally this process would be part of the release steps next time. CC @lkishalmi

[jtulach]

This target wasn't ready for the new, cluster based, structure of the repository.

[jtulach]

All the APIs

This change has one, interesting side effect. The .sig files are now added to every module with some OpenIDE-Module-Public-Packages. Btw. that is the reason why there is so many new files added.

As a consequence we now have the same safety net for developing APIs all over the NetBeans code base. E.g. when we make an incompatible change in some APIs, we get a warning (as a failed travis or even local build) and we can take corrective actions.

Solving the friend dependency problem!?

With such infrastructure in place I wouldn't be afraid to open up (step by step and case by case) more modules with friend dependencies to public. Their API is still going to lack documentation, but if we open them and classify as under development, then at least our fellow developers will not have to play wild tricks to use them. Moreover, we'll be able to guarantee backward compatibility with released Apache NetBeans versions thanks to having the SigTest check in place.

[jtulach]

There are many new files - looks like every module with some public packages got its snapshot.

[lkishalmi]

https://issues.apache.org/jira/browse/NETBEANS-1848 created as a JIRA counterpart.

[emilianbold]

This is an area I know little of. Could we move the active page about this on http://netbeans.apache.org/wiki/ and explain more what this is all about.

I understand this would help us make sure we don't expose more than expected in terms of public API. Do we even call this on the build server?

When would I need to use this stuff on my machine?

[jtulach]

I have no idea how to edit the so called "wiki". Wikis usually come with an edit button. I cannot find any at http://netbeans.apache.org/wiki/ Searching for "edit" text doesn't find anything useful either. Anyway, that is not a complain to be solved in this PR.

Yes, the API check is part of the travis build. See line 27. E.g. the build is supposed to fail when anyone makes an incompatible API change.

The aa8466e change makes this check part of single module build - when you press F11 in a module with some API - e.g. platform/openide.util.lookup and there is an incompatible change then the build fails.

[geertjanw]

Jaroslav Tulach (jtulach) has access already to https://cwiki.apache.org/confluence/display/NETBEANS.

[jtulach]

Can I get some approvals, please? Although these checks were already in for the NetBeans Platform and nobody found a problem, The extension of the API compatibility checks to all modules with an API deserves some agreement.

Re. Emilian's "make sure we don't expose more than expected" - actually no. These checks still allow you to add new elements to the API compatibly. These test only prevent us from removing APIs accidentally. E.g. They only check backward binary compatibility.

[lkishalmi]

Well, it seems the method how this was done is documented. i see no reason not to integrate this into master. So I approve this change, if that means something.

[geertjanw]

Great, approved.