Re: [RESULT] [VOTE] Apache Maven Surefire 3.0.0-M7
David, Sending from my mobile, so will be short. I wrote the roadmap with purpose you was talking about. We can discuss it in a voice conf which would be much faster and you can help us too but it would not be done by the way to fire a random PRs. I neededed a break because of my job and illness but this happens. Regarding the release of 2.22.3, this is ready to go. Maybe somebody wants to backport some latest fixes... T Dňa pi 10. 6. 2022, 19:52 David Karr napísal(a): > Well, we had found that we couldn't get all the required variations of > JUnit 5 working in Maven without the M release, so we had to upgrade. We > have tested our scenarios with M7, including test suites and mixed Junit4 > and JUnit5 tests, and we're not seeing any problems (including one scenario > that produced the BufferOverflow exception with M6). > > The thing is, if you're not confident enough with it to produce a non-M > release, that makes us a little nervous also. The scenarios we've tested > are a tiny fraction of the services that will be using this. I don't expect > to see any unexpected problems, but that's normal. > > However, I can certainly understand you concluding you don't have enough > data to really be confident it's fully ready. The one thing we've > determined in our testing is that if a particular service finds some > unexpected problem at any level of the JUnit 5 upgrade (starting with > simply upgrading the surefire version to 3.0.0-M7), they can simply stay > with JUnit 4 and Surefire 2.x, and they can move forward with that, while > we file that as a scenario that we need to troubleshoot. We can live with > that. > > On Wed, Jun 8, 2022 at 6:20 PM Olivier Lamy wrote: > > > On Wed, 8 Jun 2022 at 04:29, David Karr > > wrote: > > > > > Now that M7 is released, I have a feeling I know the answer to this, > but > > > what are your thoughts about when a full release will go out with these > > > latest changes? I'm currently evaluating whether we can upgrade our > > > internal platform to support Junit 5. As far as we know, M7 will > address > > > the last problem we were seeing (buffer overflow), and we'll be testing > > > that this morning, but my "platform" team only has a small set of > > services > > > we can easily test platform upgrades with. Our platform is used by a > > large > > > number of services. Using a "beta" version carries some amount of > > > indeterminate risk (sort of redundant), so I have to be more careful > > about > > > planning for contingencies if we discover unexpected problems from the > M7 > > > version in other services we don't directly support. Those > contingencies > > > include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12 > > > (upgrading this will be coming soon), and only using JUnit 4. > > > > > > > > > Well I think using Mx is because we are a bit conservative :) > > version naming is a bit of a chicken and egg problem! > > We'd like to have more feedback/tests (even issues :)) etc.. from the > real > > world but as it's called M* people do not upgrade. > > I do not see real issues with junit5. > > BUT I think there are still some problems with JPMS and the default (and > > non configurable) options used. > > Let me explain that. First you need to know surefire (and few other > plugins > > such compiler, javadoc) rely on a library called plexus-java which from a > > list of jars will parse all the module-info files to build a sort of > graph > > and so build the module-path and the classpath. > > 3.0.0-M5 has been released in June 2020 with plexus-java 1.0.5 from > > February 2020. > > 3.0.0-M6 has been released at the end of March 2022 with plexus-java > 1.1.1 > > from January 2022. > > It's always 2 years between those releases and by the way plenty of > changes > > in the plexus-java library (because of some issues with compiler, javadoc > > etc..) > > (With my committer of Jetty project hat) we use JPMS now and moving from > > 3.0.0-M5 to M6 is impossible because of > > https://issues.apache.org/jira/browse/SUREFIRE-2057 which is breaking > > change in plexus-java > > and now upgrading to M7 is impossible either because of another issue > > (which I need to create a jira for it). (but there is a gist explaining > the > > problem here > > https://gist.github.com/olamy/d651e21fd89b73612a42e3617a1d0261 > > ) > > Ideally I'd like to have more configurable options for jpms (e.g module > > graph resolution) because actually it's based on some assumptions which > can > > be wrong for some use cases. > > I'm currently collecting use cases etc... Then I will create a Jira to > ask > > for comments (such as what do you want guys to be configurable for jpms: > > test scope should be in module-path or classpath, same for provided, do > we > > need to add automatically providers to the module-path even if it's a > test > > dependency). > > I think this needs to be fixed before removing the M* :) because jpms get > > more and more adoptions now. > > > > > >
Re: [RESULT] [VOTE] Apache Maven Surefire 3.0.0-M7
Well, we had found that we couldn't get all the required variations of JUnit 5 working in Maven without the M release, so we had to upgrade. We have tested our scenarios with M7, including test suites and mixed Junit4 and JUnit5 tests, and we're not seeing any problems (including one scenario that produced the BufferOverflow exception with M6). The thing is, if you're not confident enough with it to produce a non-M release, that makes us a little nervous also. The scenarios we've tested are a tiny fraction of the services that will be using this. I don't expect to see any unexpected problems, but that's normal. However, I can certainly understand you concluding you don't have enough data to really be confident it's fully ready. The one thing we've determined in our testing is that if a particular service finds some unexpected problem at any level of the JUnit 5 upgrade (starting with simply upgrading the surefire version to 3.0.0-M7), they can simply stay with JUnit 4 and Surefire 2.x, and they can move forward with that, while we file that as a scenario that we need to troubleshoot. We can live with that. On Wed, Jun 8, 2022 at 6:20 PM Olivier Lamy wrote: > On Wed, 8 Jun 2022 at 04:29, David Karr > wrote: > > > Now that M7 is released, I have a feeling I know the answer to this, but > > what are your thoughts about when a full release will go out with these > > latest changes? I'm currently evaluating whether we can upgrade our > > internal platform to support Junit 5. As far as we know, M7 will address > > the last problem we were seeing (buffer overflow), and we'll be testing > > that this morning, but my "platform" team only has a small set of > services > > we can easily test platform upgrades with. Our platform is used by a > large > > number of services. Using a "beta" version carries some amount of > > indeterminate risk (sort of redundant), so I have to be more careful > about > > planning for contingencies if we discover unexpected problems from the M7 > > version in other services we don't directly support. Those contingencies > > include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12 > > (upgrading this will be coming soon), and only using JUnit 4. > > > > > Well I think using Mx is because we are a bit conservative :) > version naming is a bit of a chicken and egg problem! > We'd like to have more feedback/tests (even issues :)) etc.. from the real > world but as it's called M* people do not upgrade. > I do not see real issues with junit5. > BUT I think there are still some problems with JPMS and the default (and > non configurable) options used. > Let me explain that. First you need to know surefire (and few other plugins > such compiler, javadoc) rely on a library called plexus-java which from a > list of jars will parse all the module-info files to build a sort of graph > and so build the module-path and the classpath. > 3.0.0-M5 has been released in June 2020 with plexus-java 1.0.5 from > February 2020. > 3.0.0-M6 has been released at the end of March 2022 with plexus-java 1.1.1 > from January 2022. > It's always 2 years between those releases and by the way plenty of changes > in the plexus-java library (because of some issues with compiler, javadoc > etc..) > (With my committer of Jetty project hat) we use JPMS now and moving from > 3.0.0-M5 to M6 is impossible because of > https://issues.apache.org/jira/browse/SUREFIRE-2057 which is breaking > change in plexus-java > and now upgrading to M7 is impossible either because of another issue > (which I need to create a jira for it). (but there is a gist explaining the > problem here > https://gist.github.com/olamy/d651e21fd89b73612a42e3617a1d0261 > ) > Ideally I'd like to have more configurable options for jpms (e.g module > graph resolution) because actually it's based on some assumptions which can > be wrong for some use cases. > I'm currently collecting use cases etc... Then I will create a Jira to ask > for comments (such as what do you want guys to be configurable for jpms: > test scope should be in module-path or classpath, same for provided, do we > need to add automatically providers to the module-path even if it's a test > dependency). > I think this needs to be fixed before removing the M* :) because jpms get > more and more adoptions now. > > > > > > > > > > > > > > > On Mon, Jun 6, 2022 at 4:16 PM Olivier Lamy wrote: > > > > > Hi > > > The vote has passed. > > > +1 Enrico, Hervé, Michael, Romain, Slawomor, Olivier > > > > > > PMC quorum reached. I will continue the release process. > > > > > > cheers > > > Olivier > > > > > >
Re: [RESULT] [VOTE] Apache Maven Surefire 3.0.0-M7
On Thu, 9 Jun 2022 at 16:25, Romain Manni-Bucau wrote: > Well, I already wrote it on multiple threads but let try to refine that: > > 1. (Side note) we can need another thread ;) > 2. Surefire 3 is stable and reasons to hold a final release are internal > and not user facing so we can do a final > 3. JPMS is *not* supported for the reason you mentionned > well I wouldn’t say *not* but partially or incorrectly (but this is very subjective :)) anyway I created this for discussion https://issues.apache.org/jira/browse/SUREFIRE-2097 > 4. We never managed to get a version policy support so current state is > last version + best effort which means for surefire that there is no final > version supported (how can it be?) but also means we can do a new final > major version each week without much drawback so we can do a 3.0.0 now, a > 4.0.0 in a month supporting JPMS and even maybe a 5.0.0 in 2 months > dropping our legacy abstraction to align on mainstream ones instead of > stacking them (it is some work but hopes it illustrates we can do final > releases) > > Le jeu. 9 juin 2022 à 03:20, Olivier Lamy a écrit : > > > On Wed, 8 Jun 2022 at 04:29, David Karr > > wrote: > > > > > Now that M7 is released, I have a feeling I know the answer to this, > but > > > what are your thoughts about when a full release will go out with these > > > latest changes? I'm currently evaluating whether we can upgrade our > > > internal platform to support Junit 5. As far as we know, M7 will > address > > > the last problem we were seeing (buffer overflow), and we'll be testing > > > that this morning, but my "platform" team only has a small set of > > services > > > we can easily test platform upgrades with. Our platform is used by a > > large > > > number of services. Using a "beta" version carries some amount of > > > indeterminate risk (sort of redundant), so I have to be more careful > > about > > > planning for contingencies if we discover unexpected problems from the > M7 > > > version in other services we don't directly support. Those > contingencies > > > include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12 > > > (upgrading this will be coming soon), and only using JUnit 4. > > > > > > > > > Well I think using Mx is because we are a bit conservative :) > > version naming is a bit of a chicken and egg problem! > > We'd like to have more feedback/tests (even issues :)) etc.. from the > real > > world but as it's called M* people do not upgrade. > > I do not see real issues with junit5. > > BUT I think there are still some problems with JPMS and the default (and > > non configurable) options used. > > Let me explain that. First you need to know surefire (and few other > plugins > > such compiler, javadoc) rely on a library called plexus-java which from a > > list of jars will parse all the module-info files to build a sort of > graph > > and so build the module-path and the classpath. > > 3.0.0-M5 has been released in June 2020 with plexus-java 1.0.5 from > > February 2020. > > 3.0.0-M6 has been released at the end of March 2022 with plexus-java > 1.1.1 > > from January 2022. > > It's always 2 years between those releases and by the way plenty of > changes > > in the plexus-java library (because of some issues with compiler, javadoc > > etc..) > > (With my committer of Jetty project hat) we use JPMS now and moving from > > 3.0.0-M5 to M6 is impossible because of > > https://issues.apache.org/jira/browse/SUREFIRE-2057 which is breaking > > change in plexus-java > > and now upgrading to M7 is impossible either because of another issue > > (which I need to create a jira for it). (but there is a gist explaining > the > > problem here > > https://gist.github.com/olamy/d651e21fd89b73612a42e3617a1d0261 > > ) > > Ideally I'd like to have more configurable options for jpms (e.g module > > graph resolution) because actually it's based on some assumptions which > can > > be wrong for some use cases. > > I'm currently collecting use cases etc... Then I will create a Jira to > ask > > for comments (such as what do you want guys to be configurable for jpms: > > test scope should be in module-path or classpath, same for provided, do > we > > need to add automatically providers to the module-path even if it's a > test > > dependency). > > I think this needs to be fixed before removing the M* :) because jpms get > > more and more adoptions now. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 6, 2022 at 4:16 PM Olivier Lamy wrote: > > > > > > > Hi > > > > The vote has passed. > > > > +1 Enrico, Hervé, Michael, Romain, Slawomor, Olivier > > > > > > > > PMC quorum reached. I will continue the release process. > > > > > > > > cheers > > > > Olivier > > > > > > > > > >
Re: [RESULT] [VOTE] Apache Maven Surefire 3.0.0-M7
Well, I already wrote it on multiple threads but let try to refine that: 1. (Side note) we can need another thread ;) 2. Surefire 3 is stable and reasons to hold a final release are internal and not user facing so we can do a final 3. JPMS is *not* supported for the reason you mentionned 4. We never managed to get a version policy support so current state is last version + best effort which means for surefire that there is no final version supported (how can it be?) but also means we can do a new final major version each week without much drawback so we can do a 3.0.0 now, a 4.0.0 in a month supporting JPMS and even maybe a 5.0.0 in 2 months dropping our legacy abstraction to align on mainstream ones instead of stacking them (it is some work but hopes it illustrates we can do final releases) Le jeu. 9 juin 2022 à 03:20, Olivier Lamy a écrit : > On Wed, 8 Jun 2022 at 04:29, David Karr > wrote: > > > Now that M7 is released, I have a feeling I know the answer to this, but > > what are your thoughts about when a full release will go out with these > > latest changes? I'm currently evaluating whether we can upgrade our > > internal platform to support Junit 5. As far as we know, M7 will address > > the last problem we were seeing (buffer overflow), and we'll be testing > > that this morning, but my "platform" team only has a small set of > services > > we can easily test platform upgrades with. Our platform is used by a > large > > number of services. Using a "beta" version carries some amount of > > indeterminate risk (sort of redundant), so I have to be more careful > about > > planning for contingencies if we discover unexpected problems from the M7 > > version in other services we don't directly support. Those contingencies > > include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12 > > (upgrading this will be coming soon), and only using JUnit 4. > > > > > Well I think using Mx is because we are a bit conservative :) > version naming is a bit of a chicken and egg problem! > We'd like to have more feedback/tests (even issues :)) etc.. from the real > world but as it's called M* people do not upgrade. > I do not see real issues with junit5. > BUT I think there are still some problems with JPMS and the default (and > non configurable) options used. > Let me explain that. First you need to know surefire (and few other plugins > such compiler, javadoc) rely on a library called plexus-java which from a > list of jars will parse all the module-info files to build a sort of graph > and so build the module-path and the classpath. > 3.0.0-M5 has been released in June 2020 with plexus-java 1.0.5 from > February 2020. > 3.0.0-M6 has been released at the end of March 2022 with plexus-java 1.1.1 > from January 2022. > It's always 2 years between those releases and by the way plenty of changes > in the plexus-java library (because of some issues with compiler, javadoc > etc..) > (With my committer of Jetty project hat) we use JPMS now and moving from > 3.0.0-M5 to M6 is impossible because of > https://issues.apache.org/jira/browse/SUREFIRE-2057 which is breaking > change in plexus-java > and now upgrading to M7 is impossible either because of another issue > (which I need to create a jira for it). (but there is a gist explaining the > problem here > https://gist.github.com/olamy/d651e21fd89b73612a42e3617a1d0261 > ) > Ideally I'd like to have more configurable options for jpms (e.g module > graph resolution) because actually it's based on some assumptions which can > be wrong for some use cases. > I'm currently collecting use cases etc... Then I will create a Jira to ask > for comments (such as what do you want guys to be configurable for jpms: > test scope should be in module-path or classpath, same for provided, do we > need to add automatically providers to the module-path even if it's a test > dependency). > I think this needs to be fixed before removing the M* :) because jpms get > more and more adoptions now. > > > > > > > > > > > > > > > On Mon, Jun 6, 2022 at 4:16 PM Olivier Lamy wrote: > > > > > Hi > > > The vote has passed. > > > +1 Enrico, Hervé, Michael, Romain, Slawomor, Olivier > > > > > > PMC quorum reached. I will continue the release process. > > > > > > cheers > > > Olivier > > > > > >
Re: [RESULT] [VOTE] Apache Maven Surefire 3.0.0-M7
On Wed, 8 Jun 2022 at 04:29, David Karr wrote: > Now that M7 is released, I have a feeling I know the answer to this, but > what are your thoughts about when a full release will go out with these > latest changes? I'm currently evaluating whether we can upgrade our > internal platform to support Junit 5. As far as we know, M7 will address > the last problem we were seeing (buffer overflow), and we'll be testing > that this morning, but my "platform" team only has a small set of services > we can easily test platform upgrades with. Our platform is used by a large > number of services. Using a "beta" version carries some amount of > indeterminate risk (sort of redundant), so I have to be more careful about > planning for contingencies if we discover unexpected problems from the M7 > version in other services we don't directly support. Those contingencies > include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12 > (upgrading this will be coming soon), and only using JUnit 4. > Well I think using Mx is because we are a bit conservative :) version naming is a bit of a chicken and egg problem! We'd like to have more feedback/tests (even issues :)) etc.. from the real world but as it's called M* people do not upgrade. I do not see real issues with junit5. BUT I think there are still some problems with JPMS and the default (and non configurable) options used. Let me explain that. First you need to know surefire (and few other plugins such compiler, javadoc) rely on a library called plexus-java which from a list of jars will parse all the module-info files to build a sort of graph and so build the module-path and the classpath. 3.0.0-M5 has been released in June 2020 with plexus-java 1.0.5 from February 2020. 3.0.0-M6 has been released at the end of March 2022 with plexus-java 1.1.1 from January 2022. It's always 2 years between those releases and by the way plenty of changes in the plexus-java library (because of some issues with compiler, javadoc etc..) (With my committer of Jetty project hat) we use JPMS now and moving from 3.0.0-M5 to M6 is impossible because of https://issues.apache.org/jira/browse/SUREFIRE-2057 which is breaking change in plexus-java and now upgrading to M7 is impossible either because of another issue (which I need to create a jira for it). (but there is a gist explaining the problem here https://gist.github.com/olamy/d651e21fd89b73612a42e3617a1d0261 ) Ideally I'd like to have more configurable options for jpms (e.g module graph resolution) because actually it's based on some assumptions which can be wrong for some use cases. I'm currently collecting use cases etc... Then I will create a Jira to ask for comments (such as what do you want guys to be configurable for jpms: test scope should be in module-path or classpath, same for provided, do we need to add automatically providers to the module-path even if it's a test dependency). I think this needs to be fixed before removing the M* :) because jpms get more and more adoptions now. > > > On Mon, Jun 6, 2022 at 4:16 PM Olivier Lamy wrote: > > > Hi > > The vote has passed. > > +1 Enrico, Hervé, Michael, Romain, Slawomor, Olivier > > > > PMC quorum reached. I will continue the release process. > > > > cheers > > Olivier > > >
Re: [RESULT] [VOTE] Apache Maven Surefire 3.0.0-M7
Now that M7 is released, I have a feeling I know the answer to this, but what are your thoughts about when a full release will go out with these latest changes? I'm currently evaluating whether we can upgrade our internal platform to support Junit 5. As far as we know, M7 will address the last problem we were seeing (buffer overflow), and we'll be testing that this morning, but my "platform" team only has a small set of services we can easily test platform upgrades with. Our platform is used by a large number of services. Using a "beta" version carries some amount of indeterminate risk (sort of redundant), so I have to be more careful about planning for contingencies if we discover unexpected problems from the M7 version in other services we don't directly support. Those contingencies include staying on Surefire 2.22.0, but still using Spring Boot 2.3.12 (upgrading this will be coming soon), and only using JUnit 4. On Mon, Jun 6, 2022 at 4:16 PM Olivier Lamy wrote: > Hi > The vote has passed. > +1 Enrico, Hervé, Michael, Romain, Slawomor, Olivier > > PMC quorum reached. I will continue the release process. > > cheers > Olivier >
