[jira] [Created] (SLING-8161) MockSlingHttpServletResponse.sendError(int sc, String msg) does not save msg String
Rob McDougall created SLING-8161: Summary: MockSlingHttpServletResponse.sendError(int sc, String msg) does not save msg String Key: SLING-8161 URL: https://issues.apache.org/jira/browse/SLING-8161 Project: Sling Issue Type: Improvement Components: Servlets, Testing Affects Versions: Servlet Helpers 1.1.8, Servlet Helpers 1.1.10 Reporter: Rob McDougall org.apache.sling.servlethelpers.MockSlingHttpServletResponse.sendError(int sc, String msg) saves the sc parameter, but discards the msg parameter. This makes it impossible to verify the contents of the message in unit tests that use this mock. It would be trivial to add a member variable of type String to the class in order to store that message and then add a getter to retrieve it. This would make it possible to verify the contents of the message in a unit test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8161) MockSlingHttpServletResponse.sendError(int sc, String msg) does not save msg String
[ https://issues.apache.org/jira/browse/SLING-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786926#comment-16786926 ] Rob McDougall commented on SLING-8161: -- Thank you for your attention to this issue. It will help make my unit tests more robust. Thanks again. > MockSlingHttpServletResponse.sendError(int sc, String msg) does not save msg > String > --- > > Key: SLING-8161 > URL: https://issues.apache.org/jira/browse/SLING-8161 > Project: Sling > Issue Type: Improvement > Components: Servlets, Testing >Affects Versions: Servlet Helpers 1.1.8, Servlet Helpers 1.1.10 >Reporter: Rob McDougall >Assignee: Stefan Seifert >Priority: Minor > Fix For: Servlet Helpers 1.1.10 > > > org.apache.sling.servlethelpers.MockSlingHttpServletResponse.sendError(int > sc, String msg) saves the sc parameter, but discards the msg parameter. This > makes it impossible to verify the contents of the message in unit tests that > use this mock. > It would be trivial to add a member variable of type String to the class in > order to store that message and then add a getter to retrieve it. This would > make it possible to verify the contents of the message in a unit test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8424) Enhance Request Parameter Handling to Emulate HTML Forms
[ https://issues.apache.org/jira/browse/SLING-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848224#comment-16848224 ] Rob McDougall commented on SLING-8424: -- PR Created ([#6|[https://github.com/apache/sling-org-apache-sling-servlet-helpers/pull/6]) > Enhance Request Parameter Handling to Emulate HTML Forms > > > Key: SLING-8424 > URL: https://issues.apache.org/jira/browse/SLING-8424 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Servlet Helpers 1.1.10 >Reporter: Rob McDougall >Priority: Major > > Currently, the MockSlingHttpServletRequest class is set up to mock query > parameters only. It assumes that all request parameters are Strings. It > does not track things like contentType of each parameter. > I've prototyped some changes to the code in order to allow the mocking of > HTML form submissions (including file uploads). I'd like to submit a PR with > those changes. > I'm raising this issue for discussion before generating the PR in case there > is any other ongoing work that I'm not aware of or if there are objections to > the idea. > If you want to preview the changes ahead of the PR, they are in a fork of the > code available here: > [https://github.com/rmcdouga/sling-org-apache-sling-servlet-helpers] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8424) Enhance Request Parameter Handling to Emulate HTML Forms
Rob McDougall created SLING-8424: Summary: Enhance Request Parameter Handling to Emulate HTML Forms Key: SLING-8424 URL: https://issues.apache.org/jira/browse/SLING-8424 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Servlet Helpers 1.1.10 Reporter: Rob McDougall Currently, the MockSlingHttpServletRequest class is set up to mock query parameters only. It assumes that all request parameters are Strings. It does not track things like contentType of each parameter. I've prototyped some changes to the code in order to allow the mocking of HTML form submissions (including file uploads). I'd like to submit a PR with those changes. I'm raising this issue for discussion before generating the PR in case there is any other ongoing work that I'm not aware of or if there are objections to the idea. If you want to preview the changes ahead of the PR, they are in a fork of the code available here: [https://github.com/rmcdouga/sling-org-apache-sling-servlet-helpers] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-10061) slingUrl configuration parameter is ignored during install-bundle step
Rob McDougall created SLING-10061:
-
Summary: slingUrl configuration parameter is ignored during
install-bundle step
Key: SLING-10061
URL: https://issues.apache.org/jira/browse/SLING-10061
Project: Sling
Issue Type: Bug
Components: Maven Plugins and Archetypes
Affects Versions: Sling Maven Plugin 2.4.2, Sling Maven Plugin 2.4.0
Reporter: Rob McDougall
I have a pom.xml file with the following dependency in it:
{code:java}
org.apache.sling
maven-sling-plugin
2.3.8
http://${aem.host}:${aem.port}/system/console
WebConsole
{code}
${aem.host} is set to localhost and ${aem.port} is set to 4502.
It works fine when the version is set to 2.3.8 but when I moved to 2.4.0 or
2.4.2 I get the following message on the console:
{code:java}
[INFO] --- sling-maven-plugin:2.4.0:install (install-bundle) @ fluentforms.core
---
[INFO] Installing Bundle
com._4point.aem.fluentforms.core(C:\Users\Rob.McDougall\OneDrive - 4Point
Solutions Ltd\Documents\Eclipse FluentAPI
Workspace\fluentforms\core\target\fluentforms.core-0.0.2-SNAPSHOT.jar) to
http://localhost:8080/system/console via WebConsole
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 22.770 s
[INFO] Finished at: 2021-01-12T16:58:35-05:00
[INFO]
[ERROR] Failed to execute goal
org.apache.sling:sling-maven-plugin:2.4.0:install (install-bundle) on project
fluentforms.core: Installation on http://localhost:8080/system/console failed,
cause: Installation failed, cause: Not Found -> [Help 1]{code}
I have tried manipulating the value in but the plugin appears to be
ignoring that setting completely and using the default value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-12130) Update Apache Sling Hamcrest Matchers to use latest version of Hamcrest libraries
[ https://issues.apache.org/jira/browse/SLING-12130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783402#comment-17783402 ] Rob McDougall commented on SLING-12130: --- So, I went ahead and fixed it, but I am running across a code coverage issue with SonarCube. There's some code I didn't write but that I modified (added types to an untyped Generic). This particular class didn't have good code coverage to begin with but, being keen, I added tests. The problem is the new test code uncovered a problem with the previously untested code. The code pertains to an if statement that tries to handle the case where the object passed in is a Map or a Dictionary object. The Map code works just fine, but the Dictionary code creates a Stack Overflow error. I'd like to just remove it. Dictionary is old and its only subclass is HashTable (which implements Map), so the only use case we lose is if someone has a custom class the derives from Dictionary but does not implement Map. Given how old Dictionary is, I would like to just remove that code and not handle that case. Strictly speaking this is a breaking change however it seems like quite a remote possibility that any code would, in practice, actually break. Before I do that however, I'd like to get the OK to make that change. > Update Apache Sling Hamcrest Matchers to use latest version of Hamcrest > libraries > - > > Key: SLING-12130 > URL: https://issues.apache.org/jira/browse/SLING-12130 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > Fix For: Testing Hamcrest 1.0.4 > > > The Apache Sling Hamcrest Matchers use hamcrest-library 1.3 > ([here|[https://github.com/apache/sling-org-apache-sling-testing-hamcrest/blob/master/pom.xml]).] > This version is circa 2012. The latest (2.2) is from 2019 ([as shown > here|[https://central.sonatype.com/artifact/org.hamcrest/hamcrest-core/versions]).] > > Is it OK if I make a PR to update to the latest version? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12130) Update Apache Sling Hamcrest Matchers to use latest version of Hamcrest libraries
[
https://issues.apache.org/jira/browse/SLING-12130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783394#comment-17783394
]
Rob McDougall commented on SLING-12130:
---
OK, PR created:
[https://github.com/apache/sling-org-apache-sling-testing-hamcrest/pull/2]
It's failing because of some JavaDoc comments that I didn't change. If you're
OK with it, I will fix it by converting text using `` tags to use \{@code}
instead.
> Update Apache Sling Hamcrest Matchers to use latest version of Hamcrest
> libraries
> -
>
> Key: SLING-12130
> URL: https://issues.apache.org/jira/browse/SLING-12130
> Project: Sling
> Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
> Fix For: Testing Hamcrest 1.0.4
>
>
> The Apache Sling Hamcrest Matchers use hamcrest-library 1.3
> ([here|[https://github.com/apache/sling-org-apache-sling-testing-hamcrest/blob/master/pom.xml]).]
> This version is circa 2012. The latest (2.2) is from 2019 ([as shown
> here|[https://central.sonatype.com/artifact/org.hamcrest/hamcrest-core/versions]).]
>
> Is it OK if I make a PR to update to the latest version?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
Rob McDougall created SLING-12131: - Summary: Update sling-parent pom.xml to include JUnit5 dependencies Key: SLING-12131 URL: https://issues.apache.org/jira/browse/SLING-12131 Project: Sling Issue Type: Task Reporter: Rob McDougall JUnit4 is in maintenance mode (no updates in the last 2 years and then only security fixes). I think updating projects to JUnit5 should be encouraged. I am thinking this should be a relatively easy change of adding the junit-jupiter and junit-vintage-engine into the Dependency Management section of the sling-parent. Once this is done, individual projects could switch to the vintage-engine (at the very least) or move to jupiter by switching the dependency in their project pom. Some day down the road, the JUnit 4 dependencies could be removed. Projects that have not updated to JUnit5 (vintage or jupiter) by that time are likely no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12130) Update Apache Sling Hamcrest Matchers to use latest version of Hamcrest libraries
[ https://issues.apache.org/jira/browse/SLING-12130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783667#comment-17783667 ] Rob McDougall commented on SLING-12130: --- OK, I've updated the PR and removed the Dictionary code. Everything now passes. > Update Apache Sling Hamcrest Matchers to use latest version of Hamcrest > libraries > - > > Key: SLING-12130 > URL: https://issues.apache.org/jira/browse/SLING-12130 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > Fix For: Testing Hamcrest 1.0.4 > > > The Apache Sling Hamcrest Matchers use hamcrest-library 1.3 > ([here|[https://github.com/apache/sling-org-apache-sling-testing-hamcrest/blob/master/pom.xml]).] > This version is circa 2012. The latest (2.2) is from 2019 ([as shown > here|[https://central.sonatype.com/artifact/org.hamcrest/hamcrest-core/versions]).] > > Is it OK if I make a PR to update to the latest version? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12130) Update Apache Sling Hamcrest Matchers to use latest version of Hamcrest libraries
Rob McDougall created SLING-12130: - Summary: Update Apache Sling Hamcrest Matchers to use latest version of Hamcrest libraries Key: SLING-12130 URL: https://issues.apache.org/jira/browse/SLING-12130 Project: Sling Issue Type: Task Reporter: Rob McDougall The Apache Sling Hamcrest Matchers use hamcrest-library 1.3 ([here|[https://github.com/apache/sling-org-apache-sling-testing-hamcrest/blob/master/pom.xml]).] This version is circa 2012. The latest (2.2) is from 2019 ([as shown here|[https://central.sonatype.com/artifact/org.hamcrest/hamcrest-core/versions]).] Is it OK if I make a PR to update to the latest version? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784161#comment-17784161 ] Rob McDougall commented on SLING-12131: --- So, at this point, I think no-one is arguing that the JUnit5 BOM dependency shouldn't be added. The only discussion is whether the JUnit4 dependency should be removed sometime down the road (and maybe how far down the road that is). Given that, unless anyone objects, I am going to create a PR for this. > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784163#comment-17784163
]
Rob McDougall commented on SLING-12131:
---
{quote}A quick google turned up that the OpenRewrite projct
{quote}
I've used this before and it works well, but I haven't used it for custom
@Rules (which I would imagine don't migrate well).
{quote}There are custom @Rule implementations that are non-trivial to migrate.
There are runners, that may not be trivial to migrate, either. The difference
between assertions and some ootb \{{@Rule}}s can likely be covered with
automation.
{quote}
Well, complete conversion to JUnit5 Jupiter should not be required before the
JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should handle custom
@Rules and whatever other JUnit4 constructs are being used. That's all I am
talking about. Once that is done, the dependency on the unmaintained JUnit4 is
removed. Conversion from Vintage to Jupiter can take as long as it takes.
> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
> Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only
> security fixes). I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the
> junit-jupiter and junit-vintage-engine into the Dependency Management section
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at
> the very least) or move to jupiter by switching the dependency in their
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed. Projects
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely
> no longer maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12139) Bump versions of dependencies in sling-org-apache-sling-testing-hamcrest to latest
Rob McDougall created SLING-12139: - Summary: Bump versions of dependencies in sling-org-apache-sling-testing-hamcrest to latest Key: SLING-12139 URL: https://issues.apache.org/jira/browse/SLING-12139 Project: Sling Issue Type: Task Components: Testing Reporter: Rob McDougall There are a couple of older versions being referenced in the pom. Specifially: org.apache.sling.testing.sling-mock 1.8.0->3.4.14 org.apache.sling:sling 47->52 My plan is to do both under this issue and in one PR but with separate commits. If you'd prefer separate issues or PRs, just let me know. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784231#comment-17784231
]
Rob McDougall commented on SLING-12131:
---
{quote}So I think we're finding common ground :) I'm conceding that migrating
is desirable, and you seem to be conceding that it's a best-effort exercise and
some parts of such a migration can be non-trivial.
{quote}
Agreed, I think we all want to do what's best. And I absolutely agree that
the transition to the jupiter-engine is not going to happen overnight.
I hadn't realized that the JUnit Vintage engine includes JUnit4 as a transitive
dependency.
I guess I'm not really looking to remove JUnit4 (just yet :)). I'm maybe just
looking to substitute the explicit JUnit4 dependency for the transitive
dependency in the JUnit5 Vintage engine. That (at least) moves the ball a
little. It also makes the projects dependent on the newer junit-vintage-engine
rather than on the older junit dependency, which I think is a step forward.
I've started on the PR and am using the sling-hamcrest-matchers project as my
test project to ensure JUnit 4 compatibility.
Can you point me to a sling project that uses the custom JUnit4 rules? I will
attempt to use that as a second testbed to ensure nothing breaks by using the
JUnit5 dependencies.
> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
> Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only
> security fixes). I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the
> junit-jupiter and junit-vintage-engine into the Dependency Management section
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at
> the very least) or move to jupiter by switching the dependency in their
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed. Projects
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely
> no longer maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784482#comment-17784482 ] Rob McDougall commented on SLING-12131: --- OK, will do. Thanks for the pointers. > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784085#comment-17784085 ] Rob McDougall commented on SLING-12131: --- > Also, there is virtually no value in doing so, because you can use junit4 and > junit5 side-by-side I disagree. JUnit4 will be unmaintained at some point (it may already be now, not sure). In theory, the switch to JUnit5 vintage should be pretty painless (just a pom.xml change and re-run the tests). Projects that are being maintained will make this change. If no one cares to make such a trivial change to a project over a two year period (or pick some longer period if you wish), then who knows what other dependencies are not being updated. Software is more like milk than wine - it does not get better with age. Old dependencies cause work for developers using those libraries (I myself experienced this which is why I raised SLING-12130). If we have to force someone to exclude dependencies from their maven files, I would prefer to make people who are running old versions of libraries do the work rather than those who are current. I'm not in favour of unnecessary work, however I would argue that this is necessary work. I don't think you can argue against the idea that at some point all active projects will have to move to JUnit5, it's just a matter of when. At what point to you designate a project as "unmaintained" and prune it? Two years? Five years? Ten years? I would argue that whatever that period is, then that's how long you wait before dropping Junit4 from the pom. I don't believe "never" is an acceptable answer. > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784113#comment-17784113 ] Rob McDougall commented on SLING-12131: --- > Testing dependencies are never transitive and therefore should not affect > simple consumers of any Sling bundles! My point is not really related to testing dependencies. My point is that unmaintained projects will have outdated dependencies that cause work for developers. A reliable indicator that a project is unmaintained is that it does not move to JUnit5. This means that removal of Junit4 after some finite period causing breakage is an indicator that the project is unmaintained. Do we want to keep an obsolete dependency in the parent pom for the sole purpose of allowing unmaintained projects to compile? If the answer to that question is "yes", then my question would be for how long? If the answer to that is "forever", then that says that you don't intend to ever prune unmaintained projects. That doesn't sound like a reasonable stance to me, If the answer is for some finite period, then that would mean that it would be safe to remove an obsolete dependency (in this case JUnit 4) after that finite period (whatever it is). > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784113#comment-17784113 ] Rob McDougall edited comment on SLING-12131 at 11/8/23 4:19 PM: > Testing dependencies are never transitive and therefore should not affect > simple consumers of any Sling bundles! My point is not really related to testing dependencies. My point is that unmaintained projects will have outdated dependencies that cause work for developers. A reliable indicator that a project is unmaintained is that it does not move to JUnit5 (vintage-engine, at least). This means that removal of Junit4 after some finite period causing breakage is an indicator that the project is unmaintained. Do we want to keep an obsolete dependency in the parent pom for the sole purpose of allowing unmaintained projects to compile? If the answer to that question is "yes", then my question would be for how long? If the answer to that is "forever", then that says that you don't intend to ever prune unmaintained projects. That doesn't sound like a reasonable stance to me, If the answer is for some finite period, then that would mean that it would be safe to remove an obsolete dependency (in this case JUnit 4) after that finite period (whatever it is). was (Author: robmcdougall): > Testing dependencies are never transitive and therefore should not affect > simple consumers of any Sling bundles! My point is not really related to testing dependencies. My point is that unmaintained projects will have outdated dependencies that cause work for developers. A reliable indicator that a project is unmaintained is that it does not move to JUnit5. This means that removal of Junit4 after some finite period causing breakage is an indicator that the project is unmaintained. Do we want to keep an obsolete dependency in the parent pom for the sole purpose of allowing unmaintained projects to compile? If the answer to that question is "yes", then my question would be for how long? If the answer to that is "forever", then that says that you don't intend to ever prune unmaintained projects. That doesn't sound like a reasonable stance to me, If the answer is for some finite period, then that would mean that it would be safe to remove an obsolete dependency (in this case JUnit 4) after that finite period (whatever it is). > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790081#comment-17790081 ] Rob McDougall edited comment on SLING-12131 at 11/27/23 1:25 PM: - [PR Created|https://github.com/apache/sling-parent/pull/40] Discretion being the better part of valour, I decided to leave the explicit JUnit4 version in the pom.xml rather than rely on the transient from JUnit5 Vintage Engine. I checked out a small number of sling projects, altered them to use the updated parent pom and they compiled OK except for apache.sling.junit.teleporter which experienced a bunch of maven enforcer plugin errors that are unrelated to the junit change but rather connected to some new enforcer rules that have been implemented since the last time the parent pom dependency was updated. After that, as a test,, I took some of the projects that worked and switched them over to jUnit Vintage engine and that seemed to work. I'm thinking that any additional work to actually utilize the new dependency will have to wait until version 60 of the sling-parent is actually released, otherwise the PRs will contain references to the 60-SNAPSHOT version which is additional work to merge. If that's not the case, let me know and I can start work on moving some of the projects from JUnit4 to JUnit5 sooner. was (Author: rmcdouga): [PR Created|https://github.com/apache/sling-parent/pull/40] Discretion being the better part of valour, I decided to leave the explicit JUnit4 version in the pom.xml rather than rely on the transient JUnit5 Vintage Engine. I checked out a small number of sling projects, altered them to use the updated parent pom and they compiled OK except for apache.sling.junit.teleporter which experienced a bunch of maven enforcer plugin errors that are unrelated to the junit change but rather connected to some new enforcer rules that have been implemented since the last time the parent pom dependency was changed. After that, as a test,, I took some of the projects that worked and switched them over to jUnit Vintage engine and that seemed to work. I'm thinking that any additional work to actually utilize the new dependency will have to wait until version 60 of the sling-parent is actually released, otherwise the PRs will contain references to the 60-SNAPSHOT version which is additional work to merge. If that's not the case, let me know and I can start work on moving some of the projects from JUnit4 to JUnit5 sooner. > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790081#comment-17790081 ] Rob McDougall commented on SLING-12131: --- PR Created Discretion being the better part of valour, I decided to leave the explicit JUnit4 version in the pom.xml rather than rely on the transient JUnit5 Vintage Engine. I checked out a small number of sling projects, altered them to use the updated parent pom and they compiled OK except for apache.sling.junit.teleporter which experienced a bunch of maven enforcer plugin errors that are unrelated to the junit change but rather connected to some new enforcer rules that have been implemented since the last time the parent pom dependency was changed. After that, as a test,, I took some of the projects that worked and switched them over to jUnit Vintage engine and that seemed to work. I'm thinking that any additional work to actually utilize the new dependency will have to wait until version 60 of the sling-parent is actually released, otherwise the PRs will contain references to the 60-SNAPSHOT version which is additional work to merge. If that's not the case, let me know and I can start work on moving some of the projects from JUnit4 to Junit5 sooner. > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790081#comment-17790081 ] Rob McDougall edited comment on SLING-12131 at 11/27/23 1:24 PM: - [PR Created|https://github.com/apache/sling-parent/pull/40] Discretion being the better part of valour, I decided to leave the explicit JUnit4 version in the pom.xml rather than rely on the transient JUnit5 Vintage Engine. I checked out a small number of sling projects, altered them to use the updated parent pom and they compiled OK except for apache.sling.junit.teleporter which experienced a bunch of maven enforcer plugin errors that are unrelated to the junit change but rather connected to some new enforcer rules that have been implemented since the last time the parent pom dependency was changed. After that, as a test,, I took some of the projects that worked and switched them over to jUnit Vintage engine and that seemed to work. I'm thinking that any additional work to actually utilize the new dependency will have to wait until version 60 of the sling-parent is actually released, otherwise the PRs will contain references to the 60-SNAPSHOT version which is additional work to merge. If that's not the case, let me know and I can start work on moving some of the projects from JUnit4 to JUnit5 sooner. was (Author: rmcdouga): PR Created Discretion being the better part of valour, I decided to leave the explicit JUnit4 version in the pom.xml rather than rely on the transient JUnit5 Vintage Engine. I checked out a small number of sling projects, altered them to use the updated parent pom and they compiled OK except for apache.sling.junit.teleporter which experienced a bunch of maven enforcer plugin errors that are unrelated to the junit change but rather connected to some new enforcer rules that have been implemented since the last time the parent pom dependency was changed. After that, as a test,, I took some of the projects that worked and switched them over to jUnit Vintage engine and that seemed to work. I'm thinking that any additional work to actually utilize the new dependency will have to wait until version 60 of the sling-parent is actually released, otherwise the PRs will contain references to the 60-SNAPSHOT version which is additional work to merge. If that's not the case, let me know and I can start work on moving some of the projects from JUnit4 to Junit5 sooner. > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12139) Bump versions of dependencies in sling-org-apache-sling-testing-hamcrest to latest
[ https://issues.apache.org/jira/browse/SLING-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob McDougall updated SLING-12139: -- Description: There are a couple of older versions being referenced in the pom. Specifially: org.apache.sling.testing.sling-mock 1.8.0->3.4.14 org.apache.sling:sling 47->52 org.apache.sling.api 2.4.0->2,22.0 My plan is to do both under this issue and in one PR but with separate commits. If you'd prefer separate issues or PRs, just let me know. was: There are a couple of older versions being referenced in the pom. Specifially: org.apache.sling.testing.sling-mock 1.8.0->3.4.14 org.apache.sling:sling 47->52 My plan is to do both under this issue and in one PR but with separate commits. If you'd prefer separate issues or PRs, just let me know. > Bump versions of dependencies in sling-org-apache-sling-testing-hamcrest to > latest > -- > > Key: SLING-12139 > URL: https://issues.apache.org/jira/browse/SLING-12139 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Rob McDougall >Priority: Minor > > There are a couple of older versions being referenced in the pom. > Specifially: > org.apache.sling.testing.sling-mock 1.8.0->3.4.14 > org.apache.sling:sling 47->52 > org.apache.sling.api 2.4.0->2,22.0 > > My plan is to do both under this issue and in one PR but with separate > commits. If you'd prefer separate issues or PRs, just let me know. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12144) Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock
Rob McDougall created SLING-12144: - Summary: Bump non-sling dependencies to latest in org.apache.sling.testing.sling-mock Key: SLING-12144 URL: https://issues.apache.org/jira/browse/SLING-12144 Project: Sling Issue Type: Task Reporter: Rob McDougall Bump dependencies: Mockito: 4.7.0 -> 5.7.0 commons-lang 2.6 -> commons-lang3 3.13.0 commons-io 2.11.0 -> 2.13.0 commons-collectios4 4.2 -> 4.4 JUnit5 5.2.0 -> 5.10.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
