Descriptors piling up in incremental builds

[reckart]

When using the omtd-share-maven-plugin in incremental builds in Eclipse, descriptors start piling up in the output folders. This is due to the plugin checking if the descriptor already exists in the target folder and appending a number to the descriptor file in this case:

            File outFile = new File(descriptorsDir, descriptorPath+fileExtension);
            try {
                if (outFile.exists()) {
                    descriptorPath += (countGenerated+1);
                    outFile = new File(descriptorsDir, descriptorPath+fileExtension);
                }

                this.toXML(ds.getOmtdShareDescriptor(), outFile);
                descriptorsManifest.append(
                        new URI(null, null, descriptorPath + fileExtension, null).getRawPath())
                        .append("\n");

                ++countGenerated;
            }
            catch (IOException | XMLStreamException | JAXBException | URISyntaxException e) {
                throw new MojoExecutionException("Unable to generate descriptor", e);
            }

This was introduced by @greenwoodma in a865a1e643fa625f45816f305435d37f2b14d60c with the comment

if multiple components end up pointing to the same omtds.xml files then add a counter to the filename -- useful for UIMA components the share the same anaysis engine

In combination with the uimaFIT Maven plugin, there should never be more than one descriptor pointing to a given class. This could only happen with manually maintained descriptors.

[greenwoodma]

It's definitely not a bug as that code was added specifically because it is possible to have more than one automatically generated descriptor pointing to the same class. This code was added during the Paris meeting to handle such a case in a maven artifact being developed by Jonas from Frontiers. I can't remember the full details (not being a UIMA person I'm struggling to be sure I've got the right terminology) but he had one analysis engine which was essentially configured in three different ways. All three configurations needed to be exposed as different components to OMTD, but all somehow referenced the same class and so although the OMTD maven plugin could detect all three it wrote the descriptor files out one on top of the other. The solution was to add the numeric suffix to ensure that all the files were generated separately so that the platform could see them.

Now it may be that the specific set of circumstances are rare, but given it's possible I can't see any other sensible way of naming the files. Maybe a better alternative would be to fix your eclipse project so it deletes the files even on incremental builds?

[reckart]

I have fixed the code such that it adds the disambiguating numbers but without relying on checking on the presence of files. The code now internally keeps track of the IDs.

[greenwoodma]

That's a much better idea