Supporting the 'class' modifier in the Workspace Projects

GENERAL
1

If you’re using the bnd Workspace model, releasing to a Maven Repository becomes remarkably simple. You can even release multiple JARs from a single project using sub bundles. However, one missing feature was the ability to include auxiliary files.

Maven follows a specific naming convention when releasing artifacts to a directory. Each artifact’s name is constructed using the GAV (Group:Artifact:Version) format. For instance, the GAV for bndlib is biz.aQute.bnd:biz.aQute.bndlib:7.0.0. This GAV is then mapped to a file path, with the group expanded into a hierarchy based on dots. The metadata, represented by the POM file, is located at:

  ${group.replace('.','/')}/${artifact}/${version}/${artifact}-${version}.pom

Occasionally, there is a need to release additional files, such as project sources or javadoc. This is accomplished using a classifier. For instance, you can typically find the sources in a path like:

  ${group.replace('.','/')}/${artifact}/${version}/${artifact}-${version}-${classifier}.pom

However, until recently, bnd projects were unable to create their own class files. Fortunately, this limitation has now been addressed!

-maven-release \
       extra;\
        path=files/feature.json;
        class=feature

You can now take any file from a project that releases to Maven and add it as a class file to the release. The -maven-release instruction already supported parameters for source and javadoc generation but you can now add one or more extra keys in the parameters. The extra takes a path to a file and a class. If no class is specified, it will make a dummy class.

Very easy and sometimes a life saver. Enjoy

2

I just wanted to note that it might be better to use classifier instead of class as this can be confused with java-class files and makes it hard to read:

Also extra might be a obvious choice from a technical point of view, from maven terminology artifact is a much more better term (as maven reference such things as attached artifact of a project):
https://www.mojohaus.org/build-helper-maven-plugin/attach-artifact-mojo.html

3

The problem is that maven terminology is for artifact is overloaded and often ambiguous in many contexts. I.e. the artifact id is actually the id of the abstract thing that is released over time, it is only a part of the id of an archive (the actual file). That is why I created a set of classes in bnd modeling an unambiguous naming for the maven entities:

  • Archive (Revision,classifier,packaging)
  • Revision (Program, Version)
  • Program (groupid,artifactid)

However, for this new function, I mistakenly thought I’d use ‘class’ in the Archive class but we used classifier there as well so it is more consistent. So that was a good catch. And since instead of extra the use of archive would be more consistent so I changed that as well.

Thanks.

4

An artifact do not need to be an archive, it can be anything(especially in your example it is a textfile formatted as json …

An artifact has an id, a group a version (and type) and a classifier (that can be empty) and if it is resolved it has a file.

5

An artifact has an id, a group a version (and type) and a classifier (that can be empty) and if it is resolved it has a file

See how you have to woozle because the id of your artifact is not the artifact id? :slight_smile:

I think I once had a discussion about this with Jason van Zijl and I recall he agreed that the name artifact id was a bit unfortunate. But it is in the mist of time. Anyway, spent enough time on this topic.