To provide a bit of background here - data formats don’t come with the ability to generate model classes on their own.  That’s something we added for XML, XSD, JSON, and JSON schema because it was relatively straightforward.  As we move to other types (CSV is a good example), it’s not quite as easy, so we will have to evaluate these on a case-by-case basis. Ditto for the configuration of a data format.  For JSON, we aren’t using any non-default configuration at all right now.  For JAXB, we are specifying one configuration option (the context path).  Contrast that with the options available for the CSV data format.  The UI will likely need to provide a lot more configuration visibility for something like CSV.

I mention this because other data formats won’t just be a matter of selecting a type and pointing at a file - there’s more to it than that.  That’s why this first iteration is just focused on allowing the user to define their own data format and generate their own model classes.  Then in our wizard we just ask them for the model class they want to use along with the id of the data format.


On Mar 19, 2015, at 5:52 PM, Keith Babo <> wrote:

On Mar 19, 2015, at 5:07 PM, Johnny Verhaeg <> wrote

Why are those gotchas?  It still sounds like what I suggested about merging the custom data formats with our known ones would still work and no extra fields would be needed.  What am I missing?

How would you know what custom data formats to merge ahead of time?  Let’s say the user creates a custom XYZDataFormat for a proprietary XYZ format that they use.  There’s no way for us to know about this format.

Even for existing data formats, the requirements may go beyond just pointing at a file, especially if the file is an instance document and the configuration supplies details on how that instance document is used to generate model classes and/or configure the data format itself.

~ keith

jbosstools-fuse-dev mailing list