You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should be able to use gradle to build the content packs. Each pack can be a gradle sub project, possibly even one sub project per pack version. We can then use gradle to manage the dependencies between packs and do all the packaging.
The text was updated successfully, but these errors were encountered:
We may be able to use a gradle plugin to do something similar to what was done in stroom for downloading specific versions of released content pack zips from github, thus treating it a bit like maven central.
This would rely on each version of a pack being tagged and released with a name conforming to a strict convention.
This may need to be looked at in conjunction with #11.
The PR #15 adds in a gradle build that can handle pack dependencies. The versioning issue still remains, but this is a wider issue as it needs to be thought about with a view to how we want Stroom to handle different versions of entities. Does each new version of an entity get a new UUID, in which case when we import a new version that is only a patch version e.g. 1.0.0 -> 1.0.1 do we really want a whole new entity in stroom.
An alternative may be to issue a new UUID when we have a breaking change (major version uplift) , but this would mean existing entities with dependencies on our v1.0.1 entity would automatically adopt the new version. Possibly not always desirable.
Another alternative would be for Stroom to manage versions within an entity so entities can reference another entity by uuid and version.
We should be able to use gradle to build the content packs. Each pack can be a gradle sub project, possibly even one sub project per pack version. We can then use gradle to manage the dependencies between packs and do all the packaging.
The text was updated successfully, but these errors were encountered: