I fear that this will make this information impossible to maintain rather than just difficult and confusing, as, IIUC, there will now be two possible sources of data for every item in the catalog, and there’s a 50% to 100% chance one of them is wrong. Can you provide a complete end-to-end use case where this is a good idea?
i have no idea if it’s remotely practical, but I wonder if a tool to go from an item in the catalog to it’s source would be possible. Making it easier to find and edit this information is certainly a good idea! David Jencks > On Apr 16, 2020, at 8:05 AM, Claus Ibsen <[email protected]> wrote: > > Hi > > The information we put together for camel-catalog are assembled from > source code, pom.xml, and potentially other places. > > I have thought of having a csv file (or whatever format) in the root > of components folder, where we can override the information that are > being used. As this allows to easily maintain that information instead > of having to go to each .java source code for the @UriEndpoiint and > whatnot. > > So the csv file could be something like > > artifactId=camel-ftp,name=ftps,description=Bla bla,supportLevel=Preview > > We can of course use other formats. Or have different files for > components, languages, data formats, others, etc and then have a fixed > order, so you can easily edit this from even a spreadsheet > > Any thoughts? > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
