Gradle Framework plugin

[mcdittmar]

This is the step I'd prefer to take, rather than PR #11.

It defines a work space which includes the required files for using the gradle framework to execute the various vo-dml toolkit tasks. The work/README.md file contains the instructions.

The branch also includes new versions of the vo-dml/XML, vo-dml/HTML (and PNG) files which are generated using the new workflow. They have been verified as being equivalent to the earlier versions (with certain improvements in the HTML)!. This is a really good step, as it restores the ability to create and validate the model and generate the secondary representations. I now have the option of continuing to develop the model as I have been, or migrating to use the DSL and use Modelio only for diagrams.

NOTE: this change set intentionally retains the Volute location for the Measurements model association, there is another Issue which addresses migrating to the REC version.

[pdowler]

I'm curious about the workflow and use of these tools. I see that the vo-dml file is included in version control even though it is generated. Is that true and the XMI file in "model" the defintive source?

I assume the modelling tool can read that XMI back in for future editing... does that means all modellers have to use that tool?

I've always valued having the vo-dml representation being the definitive source so that diffs in version control (eg pull requests) clearly show what changed. If the vo-dml is generated, that's no longer true (especially longer term).

And aside: why not a build.gradle in the root of the project with a "build" target that validates the model and generates the docs? And the aside of the aside: what is the min/max gradle version? I see mavenLocal and mavenCentral so I think max is < 7.0 (6.8.3??)

[mcdittmar]

Pat,

I'm curious about the workflow and use of these tools. I see that the vo-dml file is included in version control even though it is generated. Is that true and the XMI file in "model" the defintive source?

My workflow has been to use Modelio for the modeling (including all diagrams, and text). This is exported to an XMI file, and it is stored in the repo. So this is pretty much the 'working source'. By definition the vo-dml/XML is the 'definitive source' for the model... however it is generated. In the past, there has been an ant-based system to perform these conversions, this gradle framework is one Paul has been working and this PR migrates to using it.

The modeling tool can import the xmi, but the diagrams are not included in the export, so it is not a clean pick-up for someone else. Other modelers do NOT have to use that tool, but up till recently, they'd have to do some serious work to use something else.

One of the nice things with the Toolkit is that it does a vo-dml/XML to vo-dml/DSL conversion. So one option is to convert to DSL and modify that in future revisions. This may be the path I take for future updates.

I've always valued having the vo-dml representation being the definitive source so that diffs in version control (eg pull requests) clearly show what changed. If the vo-dml is generated, that's no longer true (especially longer term).

I don't enjoy working directly with the vo-dml/XML, but that is certainly an option. Since the vo-dml/XML is the definitive source, the update to that would represent the model changes.

And aside: why not a build.gradle in the root of the project with a "build" target that validates the model and generates the docs? And the aside of the aside: what is the min/max gradle version? I see mavenLocal and mavenCentral so I think max is < 7.0 (6.8.3??)

Paul submitted PR #11 which is more integrated (at the base level). Much like your questions about the Modelio workflow, I didn't want to tie the repo to using the toolkit just yet. It's more of a "This is how I work the models, but the resulting products are the more important items." My goal is to make the connection, work with it, and see where it goes from here.

I can't speak to the min/max gradle versions: perhaps @pahjbo can address that.

[pahjbo]

This PR does do more than just add the gradle tools support, so muddies the water a bit compared to #11 as it changes the model as well. The minimum gradle version support is v7 (at least that is where I started, I have not bothered with testing lower) - In fact you will see in #11 that the exact version of the gradle wrapper is 7.5.1 - the intention is that the vodml plugin will work with all future versions, although I suspect that moving to v8 would break things just at the moment.

I am giving a demo in the interop in which I am hoping to demostrate the advantages of the new (well it is now a couple of years old and vodsl is nearly 10 years old) tooling and workflow.

[mcdittmar]

This PR does do more than just add the gradle tools support, so muddies the water a bit compared to #11 as it changes the model as well.

The vo-dml/xml file is updated in this PR, but the content is not. The file included here is what the toolkit produces. The deltas are:

• whitespace
• lastModified date
• schemaLocation is the ivoa.net URL vs a file on my local system.

Similar situation with the HTML.

I wanted this to be such that if someone pulled it and followed the instructions, they'd get the same results.