[GitHub] DominikSuess commented on a change in pull request #14: Issue/sling 8038
DominikSuess commented on a change in pull request #14: Issue/sling 8038
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/14#discussion_r228343399
##
File path:
src/main/java/org/apache/sling/feature/maven/mojos/AbstractRepositoryMojo.java
##
@@ -65,7 +65,12 @@
@Override
public void execute() throws MojoExecutionException, MojoFailureException {
-final File artifactDir = new
File(this.project.getBuild().getDirectory(), repositoryDir);
+final File artifactDir ;
Review comment:
@simonetripodi the intention was to get rid of a project dir and make this
independent of a project - following patterns of other maven plugins I detect
the unreplaced project build dir to handle this case. If triggered in a non
project folder the target folder can be defined relative to execution dir or
absolute.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] DominikSuess commented on a change in pull request #14: Issue/sling 8038
DominikSuess commented on a change in pull request #14: Issue/sling 8038 URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/14#discussion_r228343381 ## File path: src/main/java/org/apache/sling/feature/maven/mojos/AbstractRepositoryMojo.java ## @@ -47,7 +47,7 @@ /** * The directory to store the artifacts into. */ -@Parameter(defaultValue = "artifacts") +@Parameter(defaultValue = "artifacts", property = "repositoryDir") Review comment: @simonetripodi this is intentional as I want to be able to fully control the target directory of the download target when not executing within a maven project context. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SLING-8047) Rendered/exported JSON requested via SlingRequestProcessor is not written to output stream
[
https://issues.apache.org/jira/browse/SLING-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664263#comment-16664263
]
Jason E Bailey commented on SLING-8047:
---
Thank you for raising this issue! I see you also created a pull request against
the models. Could you do one for the default get servlets as well?
> Rendered/exported JSON requested via SlingRequestProcessor is not written to
> output stream
> --
>
> Key: SLING-8047
> URL: https://issues.apache.org/jira/browse/SLING-8047
> Project: Sling
> Issue Type: Bug
> Components: Feature Model, Servlets
>Reporter: Philip Mundt
>Assignee: Jason E Bailey
>Priority: Major
> Attachments:
> SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch,
> SLING-8047-ExportServlet-does-not-write-to-output-stream.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
> exported JSON representation of a resource, we ran into the problem of the
> response always being empty. The HTML rendering worked without any issue.
> (See example code of [Get the rendered HTML for an AEM resource, component or
> page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
> or [https://stackoverflow.com/a/34218708])
> Main, observed difference seem to be the method calls to print writer:
> h4. JsonRenderer
> {{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
> {{#write}} method of response's print writer.
> h4. ExportServlet (via JacksonExporter)
> {{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method
> of response's print writer.
> h4. HTMLRenderer
> {{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
> {{#print}} and {{#println}} methods of response's print writer.
> h3. Further observations
> When the print writer's {{autoFlush}} property is set to true and one uses
> the {{#println}} method instead of {{#write}}, the {{JsonRenderer}} will
> flush the print writer's buffer to the output stream. Due to wrapping the
> response in
> {{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
> {{autoFlush=false}}) this does not work for the {{ExportServlet}}.
> When adding implicit {{#flush()}} calls to both classes, both request
> scenarios will work. According to the servlet specification, it should not be
> necessary to flush the print writer, as the container must immediately flush
> all remaining content to the client upon "termination of the service method
> of the servlet".
> Please find two test cases for (where implicit {{#flush()}} calls were added):
> * JsonRenderer ({{sling-org-apache-sling-servlets-get}}):
> [^SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch]
> * ExportServlet ({{sling-org-apache-sling-models-impl}}):
> [^SLING-8047-ExportServlet-does-not-write-to-output-stream.patch]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-8047) Rendered/exported JSON requested via SlingRequestProcessor is not written to output stream
[
https://issues.apache.org/jira/browse/SLING-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason E Bailey reassigned SLING-8047:
-
Assignee: Jason E Bailey
> Rendered/exported JSON requested via SlingRequestProcessor is not written to
> output stream
> --
>
> Key: SLING-8047
> URL: https://issues.apache.org/jira/browse/SLING-8047
> Project: Sling
> Issue Type: Bug
> Components: Feature Model, Servlets
>Reporter: Philip Mundt
>Assignee: Jason E Bailey
>Priority: Major
> Attachments:
> SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch,
> SLING-8047-ExportServlet-does-not-write-to-output-stream.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
> exported JSON representation of a resource, we ran into the problem of the
> response always being empty. The HTML rendering worked without any issue.
> (See example code of [Get the rendered HTML for an AEM resource, component or
> page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
> or [https://stackoverflow.com/a/34218708])
> Main, observed difference seem to be the method calls to print writer:
> h4. JsonRenderer
> {{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
> {{#write}} method of response's print writer.
> h4. ExportServlet (via JacksonExporter)
> {{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method
> of response's print writer.
> h4. HTMLRenderer
> {{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
> {{#print}} and {{#println}} methods of response's print writer.
> h3. Further observations
> When the print writer's {{autoFlush}} property is set to true and one uses
> the {{#println}} method instead of {{#write}}, the {{JsonRenderer}} will
> flush the print writer's buffer to the output stream. Due to wrapping the
> response in
> {{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
> {{autoFlush=false}}) this does not work for the {{ExportServlet}}.
> When adding implicit {{#flush()}} calls to both classes, both request
> scenarios will work. According to the servlet specification, it should not be
> necessary to flush the print writer, as the container must immediately flush
> all remaining content to the client upon "termination of the service method
> of the servlet".
> Please find two test cases for (where implicit {{#flush()}} calls were added):
> * JsonRenderer ({{sling-org-apache-sling-servlets-get}}):
> [^SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch]
> * ExportServlet ({{sling-org-apache-sling-models-impl}}):
> [^SLING-8047-ExportServlet-does-not-write-to-output-stream.patch]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [whiteboard] introducing the tag modifier
With regard to the rewriter.
In the simplest form you could have a several services that take a
Stream and return a Stream so that it could build up a full
process stream which is then used to parse the html.
The easiest implementation of that would take on a similar structure to the
existing rewriter, without having the generator and processor as you mentioned.
However, what would probably be more beneficial is to have the processing of
this html being done in asynchronous manner so that a a large document could be
parsed, processed, and pushed without maintaining state. The state in this case
being the full document.
There's a couple of ways that could be handled, but I'm still exploring. I'm
diving into async contexts to see if that would be helpful. Which might lead to
implementing Asynchorous Servlet support in a more structured format. That
might be really useful on a large scale.
- Jason
On Thu, Oct 25, 2018, at 2:33 PM, Daniel Klco wrote:
> Jason,
>
> This sounds like a great tool to create a new Rewriter. Would you see
> having OSGi Components as a subtype of Consumer being registered to provide
> the Transformers? Is there any reason to have a separate Generator and
> Processor?
>
> Thanks,
> Dan
>
> On Thu, Oct 25, 2018 at 12:57 PM Jason E Bailey wrote:
>
> > Yeah, I'm really bad for naming bundles.
> >
> > The new bundle currently provides a new "html5-generator" that will work
> > with the existing rewriter.
> >
> > How it works is that it uses the same rules that web browsers do to
> > determine when a tag in a document is one that needs to be handled or if
> > it's part of a text area. It then creates an Element object for that given
> > section and passes it along when requested. This is a pull based parser
> > with no structural validation. It won't re-write your html unless you
> > specifically request it to.
> >
> > An example generic usage:
> > Tag.stream(inputStream, "UTF-8").filter(elem -> elem.getType() ==
> > ElementType.START_TAG).count();
> >
> > or a more complex one:
> >
> > stream.map(element -> {
> > if (element.containsAttribute("href")) {
> > String value = element.getAttributeValue("href");
> > if (value != null && value.startsWith("/")) {
> > element.setAttribute("href", "http://www.apache.org; +
> > value);
> > }
> > }
> > if (element.containsAttribute("src")) {
> > String value = element.getAttributeValue("src");
> > if (value != null && value.startsWith("/")) {
> > element.setAttribute("src", "http://www.apache.org; +
> > value);
> > }
> > }
> > return element;
> > }).map(HtmlStreams.TO_HTML).forEach(System.out::print);
> >
> > Which would parse all of your html, find hrefs and src attributes that are
> > relational and rewrite them as full paths, then convert the individual
> > nodes back to HTML.
> >
> > - Jason
> >
> >
Re: [whiteboard] introducing the tag modifier
Jason,
This sounds like a great tool to create a new Rewriter. Would you see
having OSGi Components as a subtype of Consumer being registered to provide
the Transformers? Is there any reason to have a separate Generator and
Processor?
Thanks,
Dan
On Thu, Oct 25, 2018 at 12:57 PM Jason E Bailey wrote:
> Yeah, I'm really bad for naming bundles.
>
> The new bundle currently provides a new "html5-generator" that will work
> with the existing rewriter.
>
> How it works is that it uses the same rules that web browsers do to
> determine when a tag in a document is one that needs to be handled or if
> it's part of a text area. It then creates an Element object for that given
> section and passes it along when requested. This is a pull based parser
> with no structural validation. It won't re-write your html unless you
> specifically request it to.
>
> An example generic usage:
> Tag.stream(inputStream, "UTF-8").filter(elem -> elem.getType() ==
> ElementType.START_TAG).count();
>
> or a more complex one:
>
> stream.map(element -> {
> if (element.containsAttribute("href")) {
> String value = element.getAttributeValue("href");
> if (value != null && value.startsWith("/")) {
> element.setAttribute("href", "http://www.apache.org; +
> value);
> }
> }
> if (element.containsAttribute("src")) {
> String value = element.getAttributeValue("src");
> if (value != null && value.startsWith("/")) {
> element.setAttribute("src", "http://www.apache.org; +
> value);
> }
> }
> return element;
> }).map(HtmlStreams.TO_HTML).forEach(System.out::print);
>
> Which would parse all of your html, find hrefs and src attributes that are
> relational and rewrite them as full paths, then convert the individual
> nodes back to HTML.
>
> - Jason
>
>
[whiteboard] introducing the tag modifier
Yeah, I'm really bad for naming bundles.
The new bundle currently provides a new "html5-generator" that will work with
the existing rewriter.
How it works is that it uses the same rules that web browsers do to determine
when a tag in a document is one that needs to be handled or if it's part of a
text area. It then creates an Element object for that given section and passes
it along when requested. This is a pull based parser with no structural
validation. It won't re-write your html unless you specifically request it to.
An example generic usage:
Tag.stream(inputStream, "UTF-8").filter(elem -> elem.getType() ==
ElementType.START_TAG).count();
or a more complex one:
stream.map(element -> {
if (element.containsAttribute("href")) {
String value = element.getAttributeValue("href");
if (value != null && value.startsWith("/")) {
element.setAttribute("href", "http://www.apache.org; + value);
}
}
if (element.containsAttribute("src")) {
String value = element.getAttributeValue("src");
if (value != null && value.startsWith("/")) {
element.setAttribute("src", "http://www.apache.org; + value);
}
}
return element;
}).map(HtmlStreams.TO_HTML).forEach(System.out::print);
Which would parse all of your html, find hrefs and src attributes that are
relational and rewrite them as full paths, then convert the individual nodes
back to HTML.
- Jason
[jira] [Resolved] (SLING-8000) CMS - Convert modal dialog pages to a modal base
[ https://issues.apache.org/jira/browse/SLING-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason E Bailey resolved SLING-8000. --- Resolution: Fixed updated > CMS - Convert modal dialog pages to a modal base > > > Key: SLING-8000 > URL: https://issues.apache.org/jira/browse/SLING-8000 > Project: Sling > Issue Type: Improvement >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > Fix For: App CMS 0.10.2 > > > currently the request for dialogs is returning the full page with a > subsection to be pulled out for the modal dialog. > create a new base page of modal and convert the pages to be a subtype of this > page type where appropriate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7986) CMS - introduce new js lib to decorate elems on dom insertion
[ https://issues.apache.org/jira/browse/SLING-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason E Bailey resolved SLING-7986. --- Resolution: Fixed new nomnom.js has been introduced to handle element decoration > CMS - introduce new js lib to decorate elems on dom insertion > - > > Key: SLING-7986 > URL: https://issues.apache.org/jira/browse/SLING-7986 > Project: Sling > Issue Type: Improvement > Components: App CMS >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > Fix For: App CMS 0.10.2 > > > added a new js lib and broke out several of the old decorators into new files > and re-wrote them to fit the new lib. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7752) Deserializing and serializing a feature model file suffles the configurations
[ https://issues.apache.org/jira/browse/SLING-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663807#comment-16663807 ] ASF GitHub Bot commented on SLING-7752: --- andreituicu commented on issue #2: SLING-7752 - Deserializing and serializing a feature model file suffles the configurations URL: https://github.com/apache/sling-org-apache-sling-feature/pull/2#issuecomment-433072825 @bosschaert Please let me know if there is anything more required here. Thank you! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Deserializing and serializing a feature model file suffles the configurations > - > > Key: SLING-7752 > URL: https://issues.apache.org/jira/browse/SLING-7752 > Project: Sling > Issue Type: Bug > Components: Feature Model >Reporter: Andrei Tuicu >Priority: Major > Fix For: Feature Model IO 0.1.4 > > > h3. Problem > Deserializing and serializing a feature model file suffles the > configurations. This happens, because unordered maps (HashMaps/Hashtables) > are used in the implementations. The problem is relevant in the context of > adding these files in code versioning systems, because a minor change to a > file, done in an automated fashion, produces a big diff in the versioning > system and it becomes very hard to see exactly what is the relevant change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] andreituicu commented on issue #2: SLING-7752 - Deserializing and serializing a feature model file suffles the configurations
andreituicu commented on issue #2: SLING-7752 - Deserializing and serializing a feature model file suffles the configurations URL: https://github.com/apache/sling-org-apache-sling-feature/pull/2#issuecomment-433072825 @bosschaert Please let me know if there is anything more required here. Thank you! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SLING-7964) Make the suffix optional for included resources
[
https://issues.apache.org/jira/browse/SLING-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663779#comment-16663779
]
John Mitchell commented on SLING-7964:
--
[~rombert] Not sure if I tagged this correctly to appear on the radar - but let
me know if I haven't.
> Make the suffix optional for included resources
> ---
>
> Key: SLING-7964
> URL: https://issues.apache.org/jira/browse/SLING-7964
> Project: Sling
> Issue Type: Improvement
>Affects Versions: Dynamic Include 3.1.2
>Reporter: John Mitchell
>Priority: Minor
>
> I'm using Sling Dynamic Includes to cache re-usable content for search
> results. That is to say that the search results are dynamic - but the content
> of the individual results are not.
> The structure of the page was that the original request from the browser had
> a suffix to indicate the search query:
> {code:java}
> /path/to/search/results/page.html/query/for/the/search{code}
> The search results were inserted using non-synthetic page resources and a
> included selector to render a specific form of that page. The problem was
> that the original suffix of the parent request was included in the SSI
> include - so that there were numerous versions of the child resource, and
> therefore didn't achieve the cache hit ratio we were looking for.
> This PR adds a new option that makes this optional (current behaviour
> maintained by default) - so that this "reverse" dynamic include use case is
> catered for.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[
https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663523#comment-16663523
]
Oliver Lietz commented on SLING-7935:
-
[~rombert], the modules are referenced from
{{org.apache.sling.karaf-launchpad-oak-tar-integration-tests}}. Snapshot
dependencies are not practically as new tests are added steadily and often only
work with (non-testing) snapshot dependencies in features/starter.
> Consolidate all 'launchpad-testing' modules into a single git repository
>
>
> Key: SLING-7935
> URL: https://issues.apache.org/jira/browse/SLING-7935
> Project: Sling
> Issue Type: Task
> Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 12
>
>
> We currently have seven testing-related modules in Git:
> * org-apache-sling-launchpad-integration-tests
> * org-apache-sling-launchpad-test-bundles
> * org-apache-sling-launchpad-test-fragment
> * org-apache-sling-launchpad-testing
> * org-apache-sling-launchpad-testing-war
> * org-apache-sling-launchpad-test-services
> * org-apache-sling-launchpad-test-services-war
> All of these are related to testing the starter application and typically we
> only release them when the starter is also released. As such, it's a pain to
> manually keep versions in sync and release the modules one by one. This is
> one scenario where a single git repository would make sense.
> Whether this should be the actual starter repository or a starter-testing one
> is something that is not set in stone, but the current situation is not
> optimal.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[ https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663502#comment-16663502 ] Robert Munteanu commented on SLING-7935: [~olli] - do you need to reference it outside the launchpad-testing modules? You should just use snapshot depedencies. > Consolidate all 'launchpad-testing' modules into a single git repository > > > Key: SLING-7935 > URL: https://issues.apache.org/jira/browse/SLING-7935 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter 12 > > > We currently have seven testing-related modules in Git: > * org-apache-sling-launchpad-integration-tests > * org-apache-sling-launchpad-test-bundles > * org-apache-sling-launchpad-test-fragment > * org-apache-sling-launchpad-testing > * org-apache-sling-launchpad-testing-war > * org-apache-sling-launchpad-test-services > * org-apache-sling-launchpad-test-services-war > All of these are related to testing the starter application and typically we > only release them when the starter is also released. As such, it's a pain to > manually keep versions in sync and release the modules one by one. This is > one scenario where a single git repository would make sense. > Whether this should be the actual starter repository or a starter-testing one > is something that is not set in stone, but the current situation is not > optimal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SLING-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[
https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663493#comment-16663493
]
Oliver Lietz edited comment on SLING-7935 at 10/25/18 9:40 AM:
---
[~rombert], binding all testing modules to the starter version prevents
improving incrementally und using them. Currently I'm seeing an issue with
DavEx and would like to fix it:
{code:java}
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.001 s
<<< FAILURE! - in
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest
[ERROR]
testDescriptor(org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest)
Time elapsed: 0 s <<< ERROR!
java.lang.NoClassDefFoundError:
org/apache/jackrabbit/webdav/client/methods/BaseDavRequest
at
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest.setUp(DavExIntegrationTest.java:47)
Caused by: java.lang.ClassNotFoundException:
org.apache.jackrabbit.webdav.client.methods.BaseDavRequest
at
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest.setUp(DavExIntegrationTest.java:47)
{code}
But releasing this module now as version 12 doesn't make sense. What's the plan
for such cases?
was (Author: olli):
[~rombert], binding all testing modules to the starter version prevents
improving incrementally und using them. Currently I'm seeing an issue with
DavEx and would like to fix it:
{code}
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.001 s
<<< FAILURE! - in
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest
[ERROR]
testDescriptor(org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest)
Time elapsed: 0 s <<< ERROR!
java.lang.NoClassDefFoundError:
org/apache/jackrabbit/webdav/client/methods/BaseDavRequest
at
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest.setUp(DavExIntegrationTest.java:47)
Caused by: java.lang.ClassNotFoundException:
org.apache.jackrabbit.webdav.client.methods.BaseDavRequest
at
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest.setUp(DavExIntegrationTest.java:47)
{code}
But releasing this module now as version 13 doesn't make sense. What's the plan
for such cases?
> Consolidate all 'launchpad-testing' modules into a single git repository
>
>
> Key: SLING-7935
> URL: https://issues.apache.org/jira/browse/SLING-7935
> Project: Sling
> Issue Type: Task
> Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 12
>
>
> We currently have seven testing-related modules in Git:
> * org-apache-sling-launchpad-integration-tests
> * org-apache-sling-launchpad-test-bundles
> * org-apache-sling-launchpad-test-fragment
> * org-apache-sling-launchpad-testing
> * org-apache-sling-launchpad-testing-war
> * org-apache-sling-launchpad-test-services
> * org-apache-sling-launchpad-test-services-war
> All of these are related to testing the starter application and typically we
> only release them when the starter is also released. As such, it's a pain to
> manually keep versions in sync and release the modules one by one. This is
> one scenario where a single git repository would make sense.
> Whether this should be the actual starter repository or a starter-testing one
> is something that is not set in stone, but the current situation is not
> optimal.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[
https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663493#comment-16663493
]
Oliver Lietz commented on SLING-7935:
-
[~rombert], binding all testing modules to the starter version prevents
improving incrementally und using them. Currently I'm seeing an issue with
DavEx and would like to fix it:
{code}
[ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.001 s
<<< FAILURE! - in
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest
[ERROR]
testDescriptor(org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest)
Time elapsed: 0 s <<< ERROR!
java.lang.NoClassDefFoundError:
org/apache/jackrabbit/webdav/client/methods/BaseDavRequest
at
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest.setUp(DavExIntegrationTest.java:47)
Caused by: java.lang.ClassNotFoundException:
org.apache.jackrabbit.webdav.client.methods.BaseDavRequest
at
org.apache.sling.launchpad.webapp.integrationtest.DavExIntegrationTest.setUp(DavExIntegrationTest.java:47)
{code}
But releasing this module now as version 13 doesn't make sense. What's the plan
for such cases?
> Consolidate all 'launchpad-testing' modules into a single git repository
>
>
> Key: SLING-7935
> URL: https://issues.apache.org/jira/browse/SLING-7935
> Project: Sling
> Issue Type: Task
> Components: Launchpad
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter 12
>
>
> We currently have seven testing-related modules in Git:
> * org-apache-sling-launchpad-integration-tests
> * org-apache-sling-launchpad-test-bundles
> * org-apache-sling-launchpad-test-fragment
> * org-apache-sling-launchpad-testing
> * org-apache-sling-launchpad-testing-war
> * org-apache-sling-launchpad-test-services
> * org-apache-sling-launchpad-test-services-war
> All of these are related to testing the starter application and typically we
> only release them when the starter is also released. As such, it's a pain to
> manually keep versions in sync and release the modules one by one. This is
> one scenario where a single git repository would make sense.
> Whether this should be the actual starter repository or a starter-testing one
> is something that is not set in stone, but the current situation is not
> optimal.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
