Use boolean flag to create apidoc menu

[ebarboni]

attempt to make apidoc generation according to a flag instead of url.
remove apidoc prior to 8.2 link

will need to recommit on the previous release branch.

[neilcsmith-net]

Looks good. And allowing apidocurl, etc. to be unspecified should make it easier for VSNetBeans to use its own json file and leave out a bunch of stuff it doesn't need?

@JaroslavTulach please can we get a vsnetbeansrelease.json for the upcoming VSNetBeans release? Will simplify things with out of band releases. Should just be a case of overriding the default json file property somewhere in the build files.

[neilcsmith-net]

I just spent 15min looking for the build issue that @JaroslavTulach had with older VSNetBeans release to realise it's already covered by this change! 😄

[JaroslavTulach]

@JaroslavTulach please can we get a vsnetbeansrelease.json for the upcoming VSNetBeans release?

See apache/netbeans-jenkins-lib#46 - I am particularly afraid of duplicating the same data in two files for 12.5.0, 12.6.0, etc. releases.

[neilcsmith-net]

@JaroslavTulach normally I'd be the first to agree with you on data duplication, but as also mentioned there, we're losing the canonical record of Apache IDE releases in that file, which is also important because it's used elsewhere. Let's keep conversation on that there.

[JaroslavTulach]

@JaroslavTulach please can we get a vsnetbeansrelease.json for the upcoming VSNetBeans release? Will simplify things with out of band releases. Should just be a case of overriding the default json file property somewhere in the build files.

This is the current build configuration for VSNetBeans:

ant build-source-config -Dmetabuild.branch=$METABRANCH -Dmetabuild.jsonurl=$METAURL
ant build -Ddo.build.windows.launchers=true -Dmetabuild.branch=$METABRANCH -Dmetabuild.jsonurl=$METAURL

cd java/java.lsp.server/
ant build-vscode-ext -Dvsix.version=$VERSION -D3rdparty.modules=$MODULES -Dmetabuild.jsonurl=$METAURL

I can certainly change $METAURL to point to something else, but I don't know which script you'd like me to modify!?

[neilcsmith-net]

I can certainly change $METAURL to point to something else, but I don't know which script you'd like me to modify!?

Yes, looking at that I guess changing $METAURL will have to do. I was thinking there was an Ant file inside java/java.lsp.server that was triggering the IDE build - my mistake.

[neilcsmith-net]

@ebarboni if we keep the VSNetBeans releases in the same json file, a flag to pick up what is and isn't an IDE release might be useful for this and other problems. On the other hand, that would still involve VSNetBeans having to configure the build differently, so still probably better as a separate file IMO.

[ebarboni]

this pr is more for cleaning up apidoc once done on other release branches,

If we add some flag on the json, (non impacting the netbeans repo) we may also have for example in the release branches
https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release126/14/artifact/
containing vsix files to get ready for release for normale release and with some works handling for the vsrelease1263 so we pick as we pick maven, installer, nbm during release

Will have impact on https://github.com/apache/netbeans-jenkins-lib/blob/master/vars/asfMainNetBeansBuild.groovy that is old and can be upgraded to fit

[neilcsmith-net]

Yes, I understand that. Still all easier with separate JSON files. There's the other stuff on the VM that reads the JSON file too - I just realised I don't think you had the current update-netbeans-javadoc.php in the puppet PR?

[ebarboni]

My bad, I use the content from the PR on netbeans-tools. PR created to resynchronize.
This script could use the new flag to filter what to scan on ci-build

I put do not merge because of this:
The only current drawback is that IDE scan for all previous version including vsversion like 12.5.301, I'm not sure what it involve in vscode
https://github.com/apache/netbeans/search?q=apachepreviousversion
Maybe I should add to this PR the filter VSIX flag just to be ready for the future and backported to previous branches

I would prefer one file to keep all what is build on netbeans repo because if we need management. Thinking on release removal, it will involve recomputing date to get apichangelog and I would prefer one place for that.

[neilcsmith-net]

@ebarboni definitely my bad! 😄 I'd meant to update that PR with my changes.

The problem is how many places we're going to have to build in logic to filter by release type. I realise there's no right answer here - both have problems.

[ebarboni]

in fact "publish_apidoc":"false" is kind of "vsix_only":"true" so we can filter the list no using another boolean.

for the build in https://github.com/apache/netbeans-jenkins-lib/blob/master/vars/asfMainNetBeansBuild.groovy this is up to us. (Will try to make that possible so we can have common way on "X.X release" and for the X.X.301)

for apidoc with the new flag we just avoid curl 404 in the vm if we patch to scan for the publish flag.

I'm not sure the other place where we use the json.

[neilcsmith-net]

Well, from 13 we'll have X (and X.301 potentially). I'm still curious to see what that breaks! 😄

That 404 took out the entire Javadoc publishing process if I remember rightly.

I don't know what the other places we use the json are, or what we might need in future - that's my concern. And if we start filtering for this flag inside the build, then VSNetBeans will still have to special case it.

[ebarboni]

version X worked for 10, just the apidoc/update catalog need the X.0

[neilcsmith-net]

Thanks! Let's see how we get on with this.

Let's take the flags discussion elsewhere. Having thought on this, I think if we do keep in one file, we need two truth-y values for is_ide and is_vsix rather than a false-y one vsix-only. To fix some of the issues we're likely to need to filter the list both ways, and some are IDE only. Or we add a category array with ide and vsix - future proof for the next thing someone wants in here! 😄