Support for BLD?

[hrstoyanov]

Currently VSCode support only Gradle or Maven projects - it does not have independent project structure - is this correct? I am looking a BLD as an alternative build tool, and it seems this is impossible?

[Achal1607]

Please refer to #74 for more info

[robaho]

It doesn't seem that BLD has anyway to export a dependency list, source directories, etc. - and since it is completely defined within code, the possibilities are infinite.

I don't see how the plugin could work with this - unless you have to duplicate the structure/configuration using another configuration (e.g. gradle?) or through a UI/settings.

[hrstoyanov]

If JavaVSCode support a non-Maven/Gradle project description format BLD could export to it. For example IntelliJ can work with Java projects without Gradle or Maven present

[robaho]

If JavaVSCode support a non-Maven/Gradle project description format BLD could export to it. For example IntelliJ can work with Java projects without Gradle or Maven present

But that is because IntelliJ includes its own project build/dependency tools and formats. Similarly with Eclipse (the .classpath and .settings files).

[robaho]

Also, if BLD was going to export a project description file, why not export a simple gradle "dependency/source location" file instead? You could still use BLD to perform the actual build, but the gradle file will allow integration with the IDE.

I am not a huge fan of gradle, but for something like this it seems the easiest path.

[lahodaj]

This extension does not really (as far as I know) have its own canonical custom project description format/metadata to which project's description could be exported. It typically reads the information directly from some build system. Internally, the project model is a set of APIs that provides information about files and directories, not a file format.

That said, I can see several possible directions here:

• can BLD export interesting project configuration information to some formats already? Like what are the source roots, and for each source root what is the classpath/module-path/processor path, output directory, source level, and other compiler settings? Is there a link to see how that looks like/works? Is there a specification of the format(s)?
• if BLD can export to other formats, is there a specific reason why it cannot export to either pom.xml or build.gradle?
• the extension supports settings which include extra VM Options, and these are used not only for running, but also for support of the source-file launcher, where it is used to configure the internal compiler options. For simple enough projects, it may be enough to simply specify the correct classpath/module-path in this option. Will not work well with multiple interdependent source roots, though, as this is a single global setting. This relates to https://github.com/oracle/javavscode/issues/74, but even the current state may be enough when BLD would generate the values. (The upcoming update is mostly support for working directory, relative paths, @ files, but these do not seem so important in case a machine would generate the values.)
• mostly for completeness: in NetBeans, there is/was Ant FreeForm project. It is a not much used, has not been updated to support module-path, it is fairly difficult to understand, and has other problems, hence has not been included in the extension. But, this is a file format that is very close to the internal APIs. So, in theory (no promises) if BLD and other systems could generate the FreeForm project, we could theoretically talk of/consider including that module/project type. This is probably not the best option, though, and supporting some more sensible project metadata would almost surely be better. An example of the FreeForm configuration is this: https://github.com/apache/netbeans/blob/38b5a05fd99ac0f8e8bec2a3be591fe29c60ad9a/java/ant.freeform/test/unit/data/example-projects/simple/nbproject/project.xml

[robaho]

BLD is only code. It should be trivial to implement an 'export to gradle' function. As I said, it only needs to be a minimal gradle file for dependency and source/test locations.

[hrstoyanov]

@lahodaj @robaho @Achal1607 I tried to use BLD for multi-module jars project, possibly hosting the modules in different git repos - arguably the most challenging enterprise case. It is doable - I got it to work, and it brings interesting capabilities, much more intuitive that Maven or Gradle. However, I had to manually configure IntelliJ project files, which I did hot appreciate. Here is the test project and discord discussions, if you are interested.

The BLD initial project wizard would generate IntelliJ and some VSCode project files , but you are on your own for multi-project setup.

I am a bit skeptical about generate Maven or Gradle files, because BLD is just Java - far more capable that the shackles imposed by Gradle/Maven. I had some other ideas for complex projects expressed here.

Anyway, I encourage you to try BLD on a small toy project and see for yourself. I found its API a pleasure to work with, very easy to use and liberating, also very performant. The project owners are also nice folks and very helpful.

[robaho]

It doesn’t need to generate a full gradle file - only the project entries along with their source locations and downloaded dependency directories.

It is only to allow the vscode plugin to understand the hierarchy

multi project gradle builds with a gradle file per project would be more complex though

[robaho]

@lahodaj @robaho @Achal1607 I tried to use BLD for multi-module jars project, possibly hosting the modules in different git repos - arguably the most challenging enterprise case. It is doable - I got it to work, and it brings interesting capabilities, much more intuitive that Maven or Gradle. However, I had to manually configure IntelliJ project files, which I did hot appreciate. Here is the test project and discord discussions, if you are interested.

As an aside @hrstoyanov I took a look at your sample project and tbh I don't think BLD is for me. There is a lot of lines of code across 3 files for what appears to be a pretty simple setup with dependencies. There are also "magic" methods like configureHelidonServer(this); - where is that code defined? I also don't like have the "run options" being controlled in the build setup (e.g. runWebApp()).

There are some things I like - especially the idea/basic design - but I think it needs a lot of work on the harness to simplify and standardize the build & test & run code and operations. Just my two cents.

[lahodaj]

I don't want to spend a lot of time on what I think of BLD, because it is not quite relevant here. But part of my opinion that is relevant here is that the advantage of Maven (and Gradle) is that tools (read: IDEs) can (AFAIK) auto-configure from it, at least to some pretty good degree. (Note that auto-configuration from Ant was "much harder" and BLD actually appears to be relatively similar to Ant. It was an improvement when we could auto-configure from Maven/pom.xml, and not expect an IDE-specific description of projects from the users.) I am not quite sure if it is feasible to maintain (semi-)manually several copies of the IDE metadata for the projects, which seem to be what BLD is doing/suggesting right now. I probably would not be eager to maintain metadata for even one IDE.

So, getting back to this extension, I think having a way to auto-configure the IDE without manually maintaining the (additional) metadata would be preferred.

Peeking very quickly at the projects, I am not quite clear why it wouldn't be possible to create at least limited Gradle metadata so that the IDE(s) would know where are the source roots, and what the classpath/module path is. But I am very far from Gradle expert (or even a Maven expert). So that still may be one angle.

Given BLD is not the only imperative model-less build system, there are other approaches that could be investigated. For example, the IDE could (partially) auto-configure from a list of commands issued. This might be similar to compile_commands.json used for C/C++ - just a list of commands used to build the project. Obviously, the build tool would be responsible for generating that, and keeping the file up-to-date as needed.

There were several experiments of auto-configuration based on commands executed in the past ~2 decades, with a fairly limited success. But, it still may be better than nothing. So, this may be something to investigate (no promises here, though). But, the build tool would need to describe what which commands/tasks it is executing, without that there's not much that could be realistically done.

[hrstoyanov]

@robaho It is some code, maybe not the best one, but you write it once :-) I suggested to the BLD developers a way to reduce/pre-generate this initial boiler plate

... regarding configureHelidon (...): Maven has BOMs (bill-of-material) where you can fix the version of artifacts for all your projects. Gradle takes this a notch further with the concept of catalogs where you can do BOMs, but also cluster artifacts that tend to go together, so you do not repeat them all over the place - Gragel catalog "bundles".

...Therefore, I added a simple interface PerunPlatform that can do all of the above and even more! This is very natural BLD extension to be used in all your builds and just make sense (could have also be implemented as Enum btw). Compare that to the convoluted documentation for Gradle and Maven!

You can see I was pushing BLD to exceed Maven and Gradle in the most complex configurations, something the BLD authors never tried. It resulted in some (probably wacky code) but the pain in configuring manually IntelliJ is what I did not like

[robaho]

@hrstoyanov the other major difference I see with BLD vs Gradle, is that BLD doesn't have any dependency management. Gradle tracks the dependencies at the source/class level, and then only compiles and/or runs tests that need to happen after other changes. So for very large projects, Gradle speeds up the build process significantly.

Anyway, not really a topic for this project, but as I pointed out a few times, I think the course of action is to add support for generating a basic gradle file as a build artifact to the BLD codebase.

[hrstoyanov]

@lahodaj if you run the bld wizard to create a simple project, it will generate both InteiilJ abd VScode configs, but I never looked into the vs code config , really doubt it is meant for this Oracle extension. You mentioned Netbeans "Freeform" - is this something that allows you to configure your Netbeans project/this extension without Gradle/Maven - that might work?

I do not have all the answers either .. but the Java community does need a build tool that is .. just Java. I find it unacceptable that in 2024 our build tools require XML , Kotlin, Groovy or some other death-end language, which is why I look at BLD. We can build docker images or configure entire cloud clusters in Pure java already .

[hrstoyanov]

@robaho agreed. BLD tracks dependencies only via a (local) Maven repo it seems , and I can see this being a problem for an IDE (which needs to parse/index zipped java source files) BLD is different because you it is imperative - you tell it/code it what to do explicitly. Maven and Gradle are declarative - they figure out the dependency graph (and cache it for performnce). Both approaches have pros and cons.

fyi: @ethauvin @gbevin - this is an interesting discussion thread you may want to chime in.

[robaho]

@robaho agreed. BLD tracks dependencies only via a (local) Maven repo it seems , and I can see this being a problem for an IDE (which needs to parse/index zipped java source files) BLD is different because you it is imperative - you tell it/code it what to do explicitly. Maven and Gradle are declarative - they figure out the dependency graph (and cache it for performnce). Both approaches have pros and cons.

fyi: @ethauvin @gbevin - this is an interesting discussion thread you may want to chime in.

Yes, but when I tell BLD "compile my project" I would expect it to only compile the files that have changed (and their dependencies). It sounds like you rely on the IDE (in this case Intellij) to perform the incremental build analysis for running/debugging, and then only use BLD for CI on a server / final builds & packaging - when users are not waiting.

[hrstoyanov]

I might be wrong on that, but javac is so fast, it would not matter anyway

[robaho]

I might be wrong on that, but javac is so fast, it would not matter anyway

I think it is more about figuring out the test dependencies to avoid running the tests that don't have any dependent changes.

[lahodaj]

@lahodaj if you run the bld wizard to create a simple project, it will generate both InteiilJ abd VScode configs, but I never looked into the vs code config , really doubt it is meant for this Oracle extension. You mentioned Netbeans "Freeform" - is this something that allows you to configure your Netbeans project/this extension without Gradle/Maven - that might work?

Well, pre-generated IDE config is nice - but what happens when one changes the build configuration? Even something as simple as changing the source level? Do I go to all of these IDE configs/metadata and fix them manually? And then start all the IDEs and verify the config? To me, that sounds fairly unfriendly.

For NetBeans' Ant FreeForm - there's such a thing, but I think it is considered a dead end even by NetBeans developers (it is considered semi-deprecated for so long it was not even updated to support the modular paths) . There are other kinds of Ant-based projects in NetBeans (some of which support Java modules), but none of them is included with this extension at this time. And while some of them might in theory possibly be used to describe the project, I am not really convinced it is reasonable to maintain yet-another copy of the config for your project. In any case - why would this old-fashioned config (in XML, among other things) be better than a Gradle build config stub?

I do not have all the answers either .. but the Java community does need a build tool that is .. just Java. I find it unacceptable that in 2024 our build tools require XML , Kotlin, Groovy or some other death-end language, which is why I look at BLD. We can build docker images or configure entire cloud clusters in Pure java already .

TBH, I don't think I personally(!) have a too strong opinion on what language build tools should use (in general). Where I have an opinion is ability to auto-configure (my) IDE from the project, and not maintaining IDE configurations. I think maintaining (multiple) IDE configurations is simply not feasible.

One of the ways that may possibly be worth investigating is (as noted above) listing all the commands used to build a project. The IDE could chew through that, and hopefully(!) figure the things out. At least if the project is not doing too much "special" stuff. But, the built tool would need to produce this and keep it up-to-date. Not saying this will happen, just that this may be something to consider/investigate, and something that seems more feasible to me in the long run that expecting users to maintain one of the Ant projects replicating the configuration inside the BLD tool.

[ethauvin]

I've only skimmed through this thread, so please excuse me if someone else already mentioned that bld can export a POM file, just add the following to your build file:

@BuildCommand(value = "pom-root", summary = "Generates the POM file in the root directory")
public void pomRoot() throws FileUtilsErrorException {
    PomBuilder.generateInto(publishOperation().fromProject(this).info(), dependencies(),
        new File(workDirectory, "pom.xml"));
}

I use that all the time to fool tools like Snyk, etc. into treating a bld project like a Maven one.

@Override
public void compile() {
    super.compile();
    pomRoot();
}

Likewise, I don't know if VSCode would pick up on it, but it might be something to look into.

[robaho]

I've only skimmed through this thread, so please excuse me if someone else already mentioned that bld can export a POM file, just add the following to your build file...

That is exactly what is needed @ethauvin - thanks for the reply.

[Achal1607]

Closing this issue due to inactivity. Please feel free to reopen it if you have any further questions.