All the extensions have been updated for bld 2.1:

• bld ANTLR4 extension
• bld Archive extension
• bld Checkstyle extension
• bld Command Line Execution extension
• bld Generated Version extension
• bld JaCoCo Report extension
• bld Kotlin extension
  • bld Detekt extension
  • bld Dokka extension
• bld PIT Mutation Testing extension
• bld PMD extension
• bld Property File extension
• bld Spring Boot extension
• bld TestNG extension
• bld Tests Badge extension

All the extensions have also been updated:

• bld ANTLR4 extension
• bld Archive extension
• bld Checkstyle extension
• bld Command Line Execution extension
• bld Generated Version extension
• bld JaCoCo Report extension
• bld Kotlin extension
  • bld Detekt extension
  • bld Dokka extension
• bld PIT Mutation Testing extension
• bld PMD extension
• bld Property File extension
• bld Spring Boot extension
• bld TestNG extension
• bld Tests Badge extension

All the extensions have also been updated:

• ANTLR4 extension
• Archive extension
• Checkstyle extension
• Command Line Execution extension
• Generated Version extension
• JaCoCo Report extension
• PIT Mutation Testing extension
• PMD extension
• Property File extension
• Spring Boot extension
• TestNG extension
• Tests Badge extension

The Kotlin extension has been completely reworked. It now compiles using a local installation of the Kotlin compiler, making it possible to test with multiple versions of Kotlin. Dokka now has its own extension. There's also a Kotlin project template on GitHub with support for the Dokka and Detekt extensions.

We just released bld 1.9.0, the pure Java build tool for developers who don't like dealing with build tools:

• Improvements and clarifications to bld create commands
• Improvements to Visual Studio Code templates
• Updated dependency versions in project templates

The following extensions have also been updated:

• bld Checkstyle extension
• bld Command Line Execution extension
• bld Detekt extension
• bld Generated Version extension
• bld JaCoCo Report extension
• bld Kotlin extension
• bld PIT Mutation Testing extension
• bld PMD extension
• bld Property File extension
• bld Spring Boot extension
• bld TestNG extension

Getting started has never been easier, either manually or using SDKMAN!, Homebrew or JBang :

• bash -c "$(curl -fsSL https://rife2.com/bld/create.sh)"
• sdk install bld
• brew install rife2/tools/bld
• jbang com.uwyn.rife2:bld:1.9.0

If you're using bld with Spring Boot you might like the following:

• bld Spring Boot Extension
• Spring Boot Example Project for bld

bld now supports Kotlin via a couple new extensions:

• bld Kotlin Extension
• bld Detekt Extension

When converting an existing website, you will most likely want to redirect old URLs to the new ones. RIFE2 makes it pretty simple. For example, to redirect:

https://example.com/news/2023/09/11

to

https://example.com/search?year=2023&month=09&day=11

You can easily convert the path info into parameters, by doing something like:

public class ExampleSite extends Site {
    //...
    private void redirectMoved(Context c, String url) {
        c.setStatus(301);
        c.addHeader("Location", url);
    }

    private void setRedirects() {
        //.. 
        get("/news", PathInfoHandling.MAP(
                        m -> m.p("year"),
                        m -> m.p("year").s().p("month"),
                        m -> m.p("year").s().p("month").s().p("day")),
                c -> redirectMoved(c, c.urlFor(searchUrl).params(c.parameters()).toString()));
    }

    @Override
    public void setup() {
        //..
        setRedirects();
    }
}

@gbevin said in Extensions:

@ethauvin maybe extensions can declare which dependencies they rely upon, without setting a specific version number. When bld encounters that, it warns the developer that those dependencies are needed and that versions can be configured in a properties file? After that, it will just download those dependencies automatically without relying on a specific version from the extension.

That's a great idea. Like it a lot.

@gbevin said in Extensions:

@ethauvin I think that a big appeal of Gradle and Maven is everything required to run all the project tasks is done automatically, this significantly reduces the efforts when working with a team or onboarding new developers. It also ensures that there are common versions across all the team members to ensure consistent and coherent behavior. Having a lot of extensions require manual installation of what's required to run them, defeats much of what makes them useful imho. Even if you rely on the command line API, I would still declare the required dependencies in the compile scope.

I actually think that is one of the worst thing about Grade or Maven, having to deal with plugins that use antiquated libraries. It's a never ending battle, plugins depends on specific versions and all have to mach. Gradle build files are littered with dependency exclusion on most large projects. It's a nightmare to manage.

How would you feel if you couldn't specify which version of JUnit 5 or TestNG to use? Both Gradle and Maven requires you to do so. They are plugins that are used in the test scope, and like most of them do, they required some dependencies.

@gbevin said in Extensions:

@ethauvin do we want to not have any dependencies? It seems that when people install an extension, they'd want it to just be ready to go and pull down everything required to work.

I think most people want to use the version of the tool that works for their needs, not the version that we provide, and that we keep on having to update when new versions are out.

This is no different that people having to install the JUnit or TestNG dependencies for their project.

@gbevin said in Extensions:

@ethauvin love seeing how straightforward it seems to make these!

Yeah, and I'm starting to think the command line approach is the better one. No dependencies, not locked to a specific version, etc.

And yet another one in testing

• bld PIT Mutation Testing extension

There are a couple new extensions in testing right now:

• bld Checkstyle extension
• bld Command Line Execution extension

That's bld, Josh. Cheers! :spock-hand:

@gbevin said in bld advocacy ideas:

@ethauvin I've found that really tricky, since at first glance, the Gradle version there looks actually easier and more concise, until you actually have to evolve and work with it. That's been imho the most difficult thing to convey.

I wasn't looking at making it more concise. I could have made the bld version a lot shorter, but I purposely made it the exact same number of lines. I was just trying to showcase what you can do in bld.

But I can see your point.

How about also doing some side-by-side comparisons? Something like…

@booniepepper said in bld advocacy ideas:

For my two cents, I'd say Android is probably a lost cause. For better or for worse, Android is going to be locked in to Gradle for a very long time.

Agreed.

I think bld's other advantage is that it fits the bill for a simple and stable tool like ant before it.

Gradle fits the bill for a very complex build tool, and has costs in stability since all the features necessitate refinement over time and that turns into churn/toil. That's not bad, some problems are legitimately complex and they benefit from a complex tool -- I also don't think that's a majority of projects at all.

Completely agree. I've converted over 30 projects to bld, and I've yet to find something I did in Gradle that I couldn't simply do in bld.

That's why I created the TestNG and JaCoCo extensions, etc. I just didn't want to copy-paste the same build code over and over. Like you often have to in Gradle, or Maven.

I've written plugins for Gradle before, and once again that is infinitely more complicated than doing an extension in bld.

So... it's not really an idea, but a thought that there's a storm-a-brewing, and it might position bld really well for people that want something a little more simple and stable. (But not ant)

I think Geert and I are a pretty big proponent of the KISS principle. Do one thing and do it well, don't throw in the kitchen sink.

I'm pretty sure we could make bld cook breakfast in the morning, but we won't. Now, if you want to write an extension to do just that, be my guest.

Thanks for the great feedback.

@gbevin said in bld advocacy ideas:

@ethauvin maybe a short video as an animated gif that can play directly on the website?

That's an idea. Will be catchy too.

@gbevin said in bld advocacy ideas:

You might be onto something here, any thoughts on how to better convey that?

I'm not entirely sure yet. I was thinking a short video or maybe a nice graphic outlining the process. But those require extra steps, which people don't usually go for at first.

We need to figure how to convey all of this in a concise and appealing form.

I've started programming on a Tandy III when I was 9 years old and haven't stopped since then.

I was born and raised in France, but moved to the US when I was offered a job at Apple in my late teens.

After Apple, I started and sold a few companies and did a lot of consulting.

You probably know me as the author of one of the first daily linkblog, mostly focused on Java, which I ran for 7 years in the early 2000s. Or maybe as the author of a weekly column published in the Java Developer's Journal around the same time frame.

In recent years, I've been doing a lot of Kotlin, but Geert got me back into the Java fold, and I've been helping with both bld and RIFE2.