Building JavaDoc and Sources JARs

[Richard Bair]

> I've enabled that property and I now get a bunch of errors (100+), some random samples: 

I just ran it both on open and closed builds and am not seeing any errors. I'm on the latest graphics team repo. Are you building from master? (Not that it should matter). You had a build working before?

> I see properties talking about linking to the JavaDoc for the whole JDK (which I'm now downloading). I will set this up but I don't think it's going to solve most of those errors? 

I wouldn't imagine so. I'm pretty sure I don't have that configured.

> Some general feedback: Seems like a lot of hoops to jump through and magic in the build still. I'm just trying to get some JavaDoc here, nothing fancy. Apart from the errors working, it's not overly intuitive that I have to set a BUILD_JAVADOC=true to make 'gradle javadoc' work - can't the gradle command just force the jdoc to build? The gradle stuff is definitely better than before but it's still not a check it out and get busy coding setup, which I'm hoping is the eventual goal. 

Yes, good question. The reason there is a flag is so that when you build the sdk (the default target at present) it doesn't build the javadoc which most developers would find irritating every time they needed to run some test code (although it doesn't bother me at all because I just develop from IDEA and it doesn't run the gradle build for incremental stuff). I don't know if the javadoc task can set the BUILD_JAVADOC flag early enough in the build cycle...

> The IntelliJ project that comes down with it doesn't just open either. It seems to be dependent on all the other JDK projects

Which projects? I'm guessing rt-closed and deploy. Really the way it should be setup is the iml files for those modules should live in the rt-closed / deploy directories, and then the modules.xml just references them. I think then you could just open it and go.

> being there. I don't know how Gradle works, but the Maven approach to this would be that all your bits and pieces are stand-alone artefacts/modules with their own POM. Each one could be built on their own (and the jar is then put in a repo) and then they all just reference each other as needed. If you guys deployed to repositories (literally a filesystem that follows a naming convention - not that hard!) for your builds and deployed each of the modules, then community developers could just reference these instead of having to build and reference bits and pieces that they have no interest in. 

We are doing the work to make it possible to publish to repositories (and have been doing so for months). We will do so when we can.

I'm assuming here you're talking about publishing real builds (at least OpenJFX ones) and not on a local developers machine ('cause there'd be no advantage to that alone). But maybe you can help me understand another part of this problem, which is that suppose we have two developers, A and B. A is on some code two weeks old. B is completely up to date. B does some fix and pushes it. The build server builds the artifacts and puts them in the repo. The next time A does a build, it grabs the latest built artifacts for the code A isn't building (WebView, for instance) and there is a compile/link error because the new binaries from B are out of sync with the 2 week old code that A is building with.

Normally you version for things like this, but in this case we're talking about shared libraries that are unversioned -- they're SNAPSHOT. But one snapshot is not equal to another. How to handle this? Right now in the closed builds we have an explicit "ant update" step you have to run to get the latest binaries.

Richard