Development of sculptor cartridges

[Kirill Alexandrovsky]

Hi

As was discussed in previous issue, sculptor cartridges that were developed should be shared with community.
I don't actually know how many custom cartridges are out there, but it's a shame if there are many of them, but they aren't publicly available.

So the questions are:
1. How could custom cartridges be shared? (github fork => new cartridge => pull request, separate project + maven artifact in some repository, etc)
2. What are the requirements for new cartridges? I suppose that reviewing their code will be tiresome business, maybe they should be provided AS-IS.

Thank you

[Torsten Juergeleit]

This is an important topic. The current approach of bundling the cartridges with the Sculptor distribution doesn't scale (different release cycle).

We need to decouple the cartridges from Sculptors build and release cycle. E.g. right now I have a few improvements for the Spring Data JPA cartridge but I must wait for the next Sculptor release to publish a new version of this cartridge.  

So regarding point 1 I suggest using a separate repository for each cartridge. This gives every cartridge it's own collaborators/team, branches, tickets, watch, stars, forks, pull requests...

The creation of a repository for a new cartridge could be triggered by creating a ticket in the Sculptor repository. This ticket provides a (unique) id, a (descriptive) name and a short description of the cartridge.

A few thoughts regarding point 2:

• every cartridge needs a unique id (lowercase alpha) which is used in various places, e.g. repo name, Maven artefact ID, Java package, property "cartridges="
• every cartridge should uses the same release / deployment process for publishing to Maven Central, e.g. by inheriting from a shared / common POM
  

Maybe we can come up with a Maven archetypes for creating a skeleton of a new Sculptor cartridge.

Any thoughts?

/Torsten

[Kirill Alexandrovsky]

 

I suggest using a separate repository for each cartridge. This gives every cartridge it's own collaborators/team, branches, tickets, watch, stars, forks, pull requests...

I agree, it's the only way to maintain cartridges. Although it means that cartridges should be synchronized with Sculptor version by their creators.

every cartridge needs a unique id (lowercase alpha) which is used in various places, e.g. repo name, Maven artefact ID, Java package, property "cartridges="

Thanks for clarifying, because right now we're making a set of UX cartridges, which aim to provide code generation for IFML patterns. This set contains base cartridge with classes and empty methods, and derived cartridges that override base cartridge with actual UI implementation (web app based on Errai framework in our case). So they should have naming convention of their own. At first I tried "UXbase" and "UXerrai", and it was working, but also looking a little non-consistent with other artifacts, so I changed their naming to "ux_base" and "ux_errai", snake case instead of camel. I guess this is preferred way.

every cartridge should uses the same release / deployment process for publishing to Maven Central, e.g. by inheriting from a shared / common POM

Maybe we can come up with a Maven archetypes for creating a skeleton of a new Sculptor cartridge.

Unfortunately I'm not a pro with maven so I don't know how to actually create an archetype yet (or how to publish generated artifact). But I can definitely say that archetypes is a way to go. They were extremely helpful during tutorials. And extending simple archetype-based project with generator extension was non-trivial task at first.
Regarding common pom - I thought that specifying sculptor-cartridges as a parent artifact in cartridge's pom is enough.

Anyway, I'm ready to contribute any possible way I can. At least in testing.

Thanks

[Torsten Juergeleit]

I suggest using a separate repository for each cartridge. This gives every cartridge it's own collaborators/team, branches, tickets, watch, stars, forks, pull requests...
I agree, it's the only way to maintain cartridges. Although it means that cartridges should be synchronized with Sculptor version by their creators.

Exactly. Within the cartridges POM the Sculptor version is specified in a property which is used to define the dependency on Sculptors generator library.

every cartridge needs a unique id (lowercase alpha) which is used in various places, e.g. repo name, Maven artefact ID, Java package, property "cartridges="
Thanks for clarifying, because right now we're making a set of UX cartridges, which aim to provide code generation for IFML patterns. This set contains base cartridge with classes and empty methods, and derived cartridges that override base cartridge with actual UI implementation (web app based on Errai framework in our case).

Interesting. Just curious: How is Sculptor as a generator for business-tier-related domain models helpful in the context of user interaction flow models (other than for CRUD guis)?

Previous version of Sculptor had a separate DSL for defining CRUD guis. But this feature was dropped from version 3.0 due to lack of user demand.

So they should have naming convention of their own. At first I tried "UXbase" and "UXerrai", and it was working, but also looking a little non-consistent with other artifacts, so I changed their naming to "ux_base" and "ux_errai", snake case instead of camel. I guess this is preferred way.

Snake case is ok for Java packages and Sculptor cartridge property. In the Maven artefact ID and the GitHub repository name I would go with hyphens instead of underscores.

Btw. cartrdige names of "ux_base" or "ux_errai" seem very generic. How about a descriptive prefix, e.g. "ifml_"?

every cartridge should uses the same release / deployment process for publishing to Maven Central, e.g. by inheriting from a shared / common POM
Maybe we can come up with a Maven archetypes for creating a skeleton of a new Sculptor cartridge.

Unfortunately I'm not a pro with maven so I don't know how to actually create an archetype yet (or how to publish generated artifact). But I can definitely say that archetypes is a way to go. They were extremely helpful during tutorials. And extending simple archetype-based project with generator extension was non-trivial task at first.

So I'll try to come up with a Maven archetype for creating new Sculptor cartridges.

 

Regarding common pom - I thought that specifying sculptor-cartridges as a parent artifact in cartridge's pom is enough.

Yes, good idea. This gives the Sculptor project a chance to propagate cartridge-related settings via this POM instead using Sculptors parent POM.

Anyway, I'm ready to contribute any possible way I can. At least in testing.

Good to know. I'm starting to create a prototype version of the Spring Data JPA cartridge by using this new approach. Maybe you can review it out and give some feedback.

If the approach of this prototype suits your needs then you can leverage it for your own cartridges.

/Torsten

[Torsten Juergeleit]

A prototype version of a GitHub repository for the Spring Data JPA cartridge (by using this new approach) is available here: https://github.com/sculptor/sculptor-cartridge-springdatajpa/
This repository provides the following features needed for every cartridge:

• Gitflow workflow and .gitignore configuration
• Maven POM which uses the latest release version of Sculptors cartridge POM as parent and all the specific details of the cartridge (GitHub repo, bug tracker, developer, ...)
• License
  
• Readme

A few things are still missing:

• GitHub teams for cartridge-specific repo admins and developers
• Travis CI configuration
• In the POM the <url/> and <description/> tags are missing - so they are inherited from the parent POM.
• A script for releasing to Maven Central

WDYT?

/Torsten

[Anton Hughes]

HI Torsten

This is really helpful - thanks!

Its good that you included the gitflow plugin too.

Thanks and kind regards

Anton