Stefan Seifert wrote> >> One minor thing, the current proposal uses the Maven coordinates to >> describe artifacts. It's using the path part of a maven url, so >> basically group id, artifact id, version are separated by a slash. It >> seems that the notation of separating these things by a colon is more >> common/natural. And we'll probably switch to that. > > i always stumbled about this in the current provisioning model as well - > afaik this is the most used standard to describe maven artifact coordinates > in a single string: > https://maven.apache.org/pom.html#Maven_Coordinates > > that means the following syntax variants are allowed: > > groupId:artifactId:version > groupId:artifactId:packaging:version > groupId:artifactId:packaging:classifier:version
Thanks for the pointer Stefan. We should definitely support this, I'll update the code. For some reason we have based the provisioning model and therefore the feature model on https://ops4j1.jira.com/wiki/spaces/paxurl/pages/3833866/Mvn+Protocol > > in the slingstart maven plugin we added support for special maven integration: > - including properties from maven pom inside provisioning model > - leaving out artifact version from provisioning model and getting it from > the pom dependencies > > is it planned to support something like this in sling feature as well? this > was very useful when provision models where declared in context of a maven > reactor build with all versions in one place (e.g. central parent pom). > otherwise you need to define the versions twice - in the maven poms and in > the sling feature/provision model, which is a source for errors. > I think the answer is yes and no :) The feature model itself does not support this - to keep it simple. The tooling, e.g. the maven tooling can read a file and post process it and I hope that we can do all the maven magic there without having to bake something into the model. Properties should be easy, versioning might be a little bit more tricky, but I think it should be doable. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
