[
https://issues.apache.org/jira/browse/SLING-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15545285#comment-15545285
]
Konrad Windszus edited comment on SLING-6068 at 10/6/16 1:15 PM:
-----------------------------------------------------------------
There are some more issues which need to be resolved
5. the launchpad JAR might conflict with the Maven module's main artifact, so
it should either be written to a dedicated folder within the build directory or
the file name should be extended (by something like `-launchpad`). Any other
approaches or ideas how to deal with conflicting files?
6. the additionally attached artifact (being added in
https://github.com/apache/sling/blob/trunk/tooling/maven/slingstart-maven-plugin/src/main/java/org/apache/sling/maven/slingstart/PackageMojo.java#L90)
is not considered during the goal `start` in
https://github.com/apache/sling/blob/trunk/tooling/maven/slingstart-maven-plugin/src/main/java/org/apache/sling/maven/slingstart/run/StartMojo.java#L389.
We can either always add add a dependency to the `slingstart` artifact in case
there was a provisioning model found (which would then be picked up by
https://github.com/apache/sling/blob/trunk/tooling/maven/slingstart-maven-plugin/src/main/java/org/apache/sling/maven/slingstart/run/StartMojo.java#L419)
or iterate through the list of attached artifacts and get the one with the
classifier `app`. I would rather go for the first approach here.
[~cziegeler] Any feedback would be appreciated :-)
was (Author: kwin):
There are some more issues which need to be resolved
# the launchpad JAR might conflict with the Maven module's main artifact, so it
should either be written to a dedicated folder within the build directory or
the file name should be extended (by something like `-launchpad`). Any other
approaches or ideas how to deal with conflicting files?
# the additionally attached artifact (being added in
https://github.com/apache/sling/blob/trunk/tooling/maven/slingstart-maven-plugin/src/main/java/org/apache/sling/maven/slingstart/PackageMojo.java#L90)
is not considered during the goal `start` in
https://github.com/apache/sling/blob/trunk/tooling/maven/slingstart-maven-plugin/src/main/java/org/apache/sling/maven/slingstart/run/StartMojo.java#L389.
We can either always add add a dependency to the `slingstart` artifact in case
there was a provisioning model found (which would then be picked up by
https://github.com/apache/sling/blob/trunk/tooling/maven/slingstart-maven-plugin/src/main/java/org/apache/sling/maven/slingstart/run/StartMojo.java#L419)
or iterate through the list of attached artifacts and get the one with the
classifier `app`. I would rather go for the first approach here.
[~cziegeler] Any feedback would be appreciated :-)
> slingstart-maven-plugin: Allow to start a quickstart JAR based on a
> provisioning model even for non "slingstart" packagings
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-6068
> URL: https://issues.apache.org/jira/browse/SLING-6068
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
> Affects Versions: Slingstart Maven Plugin 1.4.4
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>
> Currently the {{slingstart-maven-plugin}} can only start a server based on
> textual model definitions in case the maven module is of packaging
> "slingstart"
> (https://sling.apache.org/documentation/development/slingstart.html#starting-a-server).
>
> For ITs it is often beneficial to have them in the same module as the tested
> classes itself (which in most cases have packaging {{bundle}}). Therefore it
> would be nice, if even for other packaging values all model definitions below
> {{src/main/provisioning}} would be considered during the goal {{start}}
> (which must first build the quickstart.jar out of the models and then start
> it).
> Compare also with the readme in
> https://github.com/apache/sling/blob/trunk/testing/samples/bundle-with-it/pom.xml#L196.
> This would be especially helpful for ITs leveraging the {{TeleporterRule}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
