Introducing Byldan: A .NET Version of Maven

December 12, 2008 By Shane Isbell

3 minute read time

If you are a .NET developer and like the Maven concept but don't want to install Maven and Java on your system, Byldan is a project definitely worth looking into. Last year, Byldan started as an experimental, Mavenish build system written in C# but is now the basis for doing a full Maven port to .NET.

At the time I started Byldan, I had been working on NMaven for more than a year and had encountered a lot of issues of getting Maven to play nice with NMaven. I wanted to see what a build system might look like in pure .NET.

The first thing I noticed was the very significant speed enhancements of building a project with Byldan versus NMaven. I also needed to get the reactor build order straightened out and after searching around found NGenerics, which allowed me to do a topological sort on project dependencies. The .NET open-source community may not be as large as Java, but there is some good stuff out there.

The final thing I noticed was I couldn't find a good library for creating tar files (or even zip) to package the distribution, as any existing tools were either commercial or GPL licensed. So I implemented my own: Archivist.

At the time, I knew that getting full support for the pom, with interpolation and inheritance of all the elements would be a major task, so I settled on a simplified version of the pom for Byldan. But now, with the new project builder coming out soon in Maven 3.0-alpha1, I can tackle this problem head on. I recently converted maven-shared-model and maven-project-builder to .NET assemblies using ikvmc. Since these projects are self contained, only relying on JDK dependencies, this was a simple conversion from Java byte-code to a .NET assembly. Now I can use the same project builder in Byldan as I do in Maven. This code looks like:

javaUtil::List domainModels = new javaUtil::ArrayList();
domainModels.add(new ByldanProjectDomainModel(new FileInputStream(projectFileInfo.FullName)));

ModelTransformerContext ctx = new ModelTransformerContext(
javaUtil::Arrays.asList( new ArtifactModelContainerFactory(), new IdModelContainerFactory() ) );

ByldanProjectDomainModel model = (ByldanProjectDomainModel) ctx.transform(domainModels,
    new PomTransformer(new PomDomainModelFactory()),
    new PomTransformer(new PomDomainModelFactory()));

The code in C# is almost exactly the same as Java, I just need to qualify some of the namespaces, like java.util. We are using the same libraries to handle pom constructing, whether its Maven/NMaven, Mercury or Byldan, whether it's Java or .NET.

Now that Byldan project files are in line with the Maven ones, I'm currently looking for other areas to align, like repository format and artifact types. The assembly to support IKVM generated assemblies comes prepackaged with Mono but not Microsoft .NET, so I also have some work there. Expect an official 0.5 release sometime over the next week.

Regarding the long-term plans, Maven 3.0-alpha2 is going to be focused on full Mercury integration with Maven, allowing us to dump the old artifact resolver code. This has interesting implications for both NMaven and Byldan. I'll go down to the Sonatype offices next month and meet with Oleg to discuss how we can port Mercury to .NET for use in Byldan. We will also discuss toolchain support and how to use Maven toolchains to customize SAT rules, which we will eventually need to handle platform aware resolution of Java artifacts and .NET assemblies.

Tags: Nexus Repo Reel, Sonatype Says, Everything Open Source, Maven, dotnet, byldan

Written by Shane Isbell

Shane is a former Developer at Sonatype. He has 15 years of experience developing in mobile and embedded environments and is an expert in Android and Java. He works across the full-stack from embedded to server and is passionate about open-source.