Skip to end of metadata
Go to start of metadata

This page will serve as brainstorm for all the features that maven should provide in order to support builds in other languages than Java.

Inicial discussion is for C and C++ builds.

Currently there are two plugins: NAR Plugin and native C-build Plugin

Explanation of the NAR plugin
The nar plugin builds a jar with a file that acts as a pointer to other files in the repo:

  • one artifactId-version-x.jar, where x is common, noarch or something like that, having files that are common among all systems.
  • several artifactId-version-AOL.jar, where aol is the system identifier, having files that are specific to that system.

AOL stand for Architecture, OS, Linker, but may not be enough, the values needed to identify uniquely a system are

  • architecture (i386, powerpc,...)
  • operating system (windows, unix, linux,...)
  • distribution (suse 9, fedora 4, cygwin 1.1.7,...)
  • compiler
  • version of the compiler

Distribution may imply the os in all cases but one, under windows you may have cygwin or other environment.

This would be hard to manage, so the proposed system id is:

  • architecture
  • operating system
  • user defined (suse 9)

This new type would be mapped in the repository expanded (at least in the local repository) because the compiler doesn't understand compressed files. It may be stored in the remote repo as a tgz an uncompressed when downloaded, deleting the compressed version and keeping the name.

NOTE take a look at the naming convention used by linux

This will work for almost any organization, where there isn't a lot of similar environments. eg. for a version of a distribution there's no people with different compiler versions. This won't work for a internet wide binary repository, so the suggestion is to limit it to source artifacts.

At some point in the future we may try to standardize the user defined portion.

BTW this problem also happens in java, where you can have different compiler versions (1.3, 1.4, 1.5,...)

For building all the current plugins use the cpp ant tasks

  • No labels


  1. Distribution is different for others too. E.g. Gentoo can be installed with a Linux or BSD based system (on the same architecture).

    Version is similar to Java. You may be able to link and run artifacts build with a specific version of a compiler with others build with other versions. But as in Java, there's no guarantee. Basic problem is, that you cannot define the supported version range even in the POM, since the artifact is always named the same.

    Unfortunately there's another problem, since you cannot necessarily mix the artifacts build with different compilers. This is especially true for C++ in Windows. DLLs built with MSVC, Borland, Mingw gcc, Cygwin gcc, ... are NOT compatible. Pure C code might result in compatible artifacts, but even this is not necessarily true.

  2. Jörg makes a good point.

    I think that adding a systemId to the artifact in the repository is important, and that system ID should be well defined. I think it may be appropriate to have subdirectories within version for the artifacts of each system id.

    The defined system id would need to be able to degrade - eg if I ask for i686, I can get i386 if i686 is not there.

    Dependencies would not specify the system ID - this would always be the selected target environment (if we are doing cross compilation - which we may do in profiles to allow multiple builds from one). The target environment would default to the current environment. This would ensure that you don't end up mixing and matching different types.

    This definitely adds a new dimension to Maven - I look forward to it!

  3. We can help the NAR plugin guys creating a new type to avoid that indirection they add. This type would store things in the repo uncompressed, eg groupId/artifactId/version/artifactId-version-arch/stuff