Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Vladimir Sitnikov]

Robert> According to the ASF the -sources.zip are the official release, not
the git tag

That's right

Robert>In this case you don't control the EOL, it is based on the OS of the
release manager.

Is it? I would disagree here.

For instance, Apache JMeter produces both -src.zip (CRLF), and -src.tar.gz
with LF-defaults for text files.
Of course, one might take -src.tar.gz and try building it on Windows,
however that is not like RM's machine controls EOL.

On top of that, https://reproducible-builds.org/ is a thing, so it makes
sense to be able to reproduce release files independent of the release
manager (=producezips with the same sha512 on different OS)

So both Git and the release script control the way the release is produced.

Input data could contain both variations of the EOL styles by the way,
which might be handy for EOL-targeted tests. That is Git repo could just
contain a file with CRLF, and a file with LF. So would have the release
zip.

However I would agree some sort of the treatment should be baked into the
test.

Vladimir

Re: Naming of ITs in maven-release

[Clemens Quoss]

Hi Robert,
having put some more thought into it I was thinking:  maybe the IT 
should prove that the jira issue integrates with the plugin.  In that 
case the name would be OK and I would also have a path for providing an 
IT for MRELEASE-229.  As of now there are no ITs for release:rollback.   
I will have to set that up completely from scratch.  This will take some 
time.


Cheers, Clemens

Am 22.07.2019 um 23:39 schrieb Robert Scholte:

Hi Clemens,

since the codebase is already rather old, you'll see that naming 
convention has changed over the years.
Nowadays I prefer to to start with the JIRA id, followed by a very 
short statement of the IT.
In the end I'm more important that there is at least a test than the 
name.


Just keep in mind that in general things will succeed.
But what if one test breaks for a certain reason.
Having the JIRA id is very handy to identify if you're introducing 
regression or not.


thanks,
Robert

On Sun, 14 Jul 2019 12:06:31 +0200, Clemens Quoss  
wrote:



Hello everyone,

one more question regarding the name of the ITs in maven-release (or 
maybe generally):


Seeing that the tests are named after the jira issues i am wondering 
if that would be the right thing to do.


Shouldn't they be named after the functionality they are testing?

I for my part, being new to the whole thing, have provided a PR for 
MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1].


Now i would like to see if there are IT for ScmTagPhase to help me in 
my orientation.


For goal prepare there seem to exist the following:

...

10.07.2019  08:16      completion-goals
17.02.2019  23:40      flat-multi-module
10.07.2019  08:16      forked-basic
10.07.2019  08:16      invoker-basic
10.07.2019  08:16   833 invoker.properties
10.07.2019  08:15      MRELEASE-128
10.07.2019  08:15      MRELEASE-156
10.07.2019  08:15      MRELEASE-161
10.07.2019  08:15     MRELEASE-161-dependencyManagement
10.07.2019  08:15      MRELEASE-420
10.07.2019  08:15      MRELEASE-483
10.07.2019  08:15      MRELEASE-533
10.07.2019  08:15      MRELEASE-571_M3
10.07.2019  08:16      MRELEASE-618
10.07.2019  08:16      MRELEASE-667
17.02.2019  23:40      MRELEASE-834
10.07.2019  08:16      MRELEASE-966
10.07.2019  08:16      MRELEASE-976
10.07.2019  08:16      regular-multi-module

...

Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, 
maybe not.  I will have to look into everyone of them to decide.


Would there be a test or tests named 'scm-tag-phase' or 
'scm-tag-phase-MRELEASE-...' this would be of help, at least to me.


Or have I misunderstood some fundamental concept here?

Regards,

Clemens

[1] https://github.com/apache/maven-release/pull/29


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: ITs in maven-release

[Clemens Quoss]

Hi Robert,
thanks for the insight.  Shouldn't it fail with JDK 7 Update 80 even 
with this parameter since the backport for TLSv1.2 came with Update 95 [0]?
Since when does this requirement exist?  Just checked it:  I'm using UK 
mirror [1].  This works without TLSv1.2. Maybe thats why i didn't 
noticed before.
But we had problem at work contacting the Atlassian Repo from our Nexus 
that ran with JDK 7 Update 80.  In that case we switched back to JDK 6 
Update 211.


Cheers, Clemens

[0] 
https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client

[1] http://uk.maven.org/maven2/

Am 22.07.2019 um 23:45 schrieb Robert Scholte:
The plugin is indeed still Java 7 compatible, but that means you must 
execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK 7, 
otherwise it'll fail because this is a requirement when downloading 
from Central.
Our CI server scripts already add this argument when running with Java 
7, on your local machine it must be done by hand. This is not 
restricted to the integration tests. Try to remove your local repo and 
start any project running with Maven and Java 7, it'll fail very fast, 
i.e. by the first plugin.


thanks,
Robert

On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss  
wrote:



Hello everyone,

I have provided a PR for MRELEASE-229 [1] and added some JUnit tests 
recently.


Now I was wondering if i should provide an IT, too, and had a look 
into it:


Running

mvn verify -Prun-its

with Maven 3.6.1 and JDK 7 Update 80 fails:

...

[INFO] Building: projects\perform\MRELEASE-459\pom.xml
[INFO] run post-build script verify.groovy
[INFO]   The post-build script did not succeed. assert matcher.find()
    |   |
    |   false
    java.util.regex.Matcher[pattern=\Q[DEBUG] Additional 
arguments: \E(?:-Dhttps.protocols=TLSv1.2 
)?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745 lastmatch=]
[INFO]   projects\perform\MRELEASE-459\pom.xml  
FAILED (10.4 s)


...

IMHO it has something to do with TLSv1.2 not being backported to JDK 
7 Update 80.  But i may be wrong.


With JDK 8 Update 212 the tests run successfully.

My question is:  Should the IT still run with JDK 7?  I thought so 
since maven-release can still be build with it.  If some versions of 
JDKs are not capable of being used for IT, shouldn't the IT run fail 
fast (by enforcing the eligible versions)?


That was one question I have now redarding the ITs of maven-release.  
I post my other questions in separate mails.


Regards,

Clemens

[1] https://github.com/apache/maven-release/pull/29



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: ITs in maven-release

[Robert Scholte]

The plugin is indeed still Java 7 compatible, but that means you must  
execute it with -Dhttps.protocols=TLSv1.2 when building it with JDK 7,  
otherwise it'll fail because this is a requirement when downloading from  
Central.
Our CI server scripts already add this argument when running with Java 7,  
on your local machine it must be done by hand. This is not restricted to  
the integration tests. Try to remove your local repo and start any project  
running with Maven and Java 7, it'll fail very fast, i.e. by the first  
plugin.


thanks,
Robert

On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss  wrote:


Hello everyone,

I have provided a PR for MRELEASE-229 [1] and added some JUnit tests  
recently.


Now I was wondering if i should provide an IT, too, and had a look into  
it:


Running

mvn verify -Prun-its

with Maven 3.6.1 and JDK 7 Update 80 fails:

...

[INFO] Building: projects\perform\MRELEASE-459\pom.xml
[INFO] run post-build script verify.groovy
[INFO]   The post-build script did not succeed. assert matcher.find()
|   |
|   false
java.util.regex.Matcher[pattern=\Q[DEBUG] Additional arguments:  
\E(?:-Dhttps.protocols=TLSv1.2 )?-P(.+)\Q-DperformRelease=true -f  
pom.xml\E region=0,154745 lastmatch=]
[INFO]   projects\perform\MRELEASE-459\pom.xml   
FAILED (10.4 s)


...

IMHO it has something to do with TLSv1.2 not being backported to JDK 7  
Update 80.  But i may be wrong.


With JDK 8 Update 212 the tests run successfully.

My question is:  Should the IT still run with JDK 7?  I thought so since  
maven-release can still be build with it.  If some versions of JDKs are  
not capable of being used for IT, shouldn't the IT run fail fast (by  
enforcing the eligible versions)?


That was one question I have now redarding the ITs of maven-release.  I  
post my other questions in separate mails.


Regards,

Clemens

[1] https://github.com/apache/maven-release/pull/29



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Naming of ITs in maven-release

[Robert Scholte]

Hi Clemens,

since the codebase is already rather old, you'll see that naming  
convention has changed over the years.
Nowadays I prefer to to start with the JIRA id, followed by a very short  
statement of the IT.

In the end I'm more important that there is at least a test than the name.

Just keep in mind that in general things will succeed.
But what if one test breaks for a certain reason.
Having the JIRA id is very handy to identify if you're introducing  
regression or not.


thanks,
Robert

On Sun, 14 Jul 2019 12:06:31 +0200, Clemens Quoss  wrote:


Hello everyone,

one more question regarding the name of the ITs in maven-release (or  
maybe generally):


Seeing that the tests are named after the jira issues i am wondering if  
that would be the right thing to do.


Shouldn't they be named after the functionality they are testing?

I for my part, being new to the whole thing, have provided a PR for  
MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1].


Now i would like to see if there are IT for ScmTagPhase to help me in my  
orientation.


For goal prepare there seem to exist the following:

...

10.07.2019  08:16  completion-goals
17.02.2019  23:40  flat-multi-module
10.07.2019  08:16  forked-basic
10.07.2019  08:16  invoker-basic
10.07.2019  08:16   833 invoker.properties
10.07.2019  08:15  MRELEASE-128
10.07.2019  08:15  MRELEASE-156
10.07.2019  08:15  MRELEASE-161
10.07.2019  08:15 MRELEASE-161-dependencyManagement
10.07.2019  08:15  MRELEASE-420
10.07.2019  08:15  MRELEASE-483
10.07.2019  08:15  MRELEASE-533
10.07.2019  08:15  MRELEASE-571_M3
10.07.2019  08:16  MRELEASE-618
10.07.2019  08:16  MRELEASE-667
17.02.2019  23:40  MRELEASE-834
10.07.2019  08:16  MRELEASE-966
10.07.2019  08:16  MRELEASE-976
10.07.2019  08:16  regular-multi-module

...

Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe  
not.  I will have to look into everyone of them to decide.


Would there be a test or tests named 'scm-tag-phase' or  
'scm-tag-phase-MRELEASE-...' this would be of help, at least to me.


Or have I misunderstood some fundamental concept here?

Regards,

Clemens

[1] https://github.com/apache/maven-release/pull/29


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Robert Scholte]

Keep in mind there's another important situation that you can't control it like 
this.

According to the ASF the -sources.zip are the official release, not the git 
tag. This means that you should unpack the zip and be able to verify it on all 
OSes.
In this case you don't control the EOL, it is based on the OS of the release 
manager.
The only way to solve this is to generate files on the fly, or adjust them 
before testing.

You won't see this issue with the CI server, only after a release and when 
verified with different OSes.

thanks,
Robert

On 18-7-2019 14:49:02, Eric Lilja  wrote:
Ah, thanks Vladimir, that's even better. I was not 100% sure it would be
possible to retain complete control over resulting line endings for those
files, regardless of user git settings of stuff like autocrlf = true and
whatnot, but it seems there is, that's great news. Thanks!

- Eric L

On Thu, Jul 18, 2019 at 2:00 PM Vladimir Sitnikov <>
sitnikov.vladi...@gmail.com> wrote:

> Eric>In that case, we should generate the test files (to
> Eric>avoid git interfering), one with linux-style EOLs and one with
> Eric>Windows-style EOLs and test with both.
>
> You'd better have those files under Git control, and you could just specify
> .gitattributes so the LF file is always LF, and CRLF file is always CRLF.
>
> That is way simpler than generation of the file(s), and it is way easier to
> understand by humans
>
> Vladimir
>

JDK 13 enters Rampdown Phase Two

[Rory O'Donnell]

 Hi Robert ,

Any issues to report on JDK 13 , would like to hear the status as we are 
now in rampdown phase 2 ?


**OpenJDK builds *- JDK 13 Early Access build 30 **is now available **at 
: - jdk.java.net/13/*


 * Per the JDK 13 schedule [1], we are now in Rampdown Phase Two.
 o For more details , see Mark Reinhold's email to jdk-dev mailing
   list [2]
 o The overall feature set is frozen, no further JEPs will be
   targeted to this release.
 o Per the JDK Release Process [3] we now turn our focus to P1 and
   P2 bugs.

 * I want to draw your attention to some noteable changes in previous
   builds of JDK 13. These changes  are important for those that
   develop/maintain their own socket implementation
   (java.net.SocketImpl) or use the setSocketImplFactory or
   setSocketFactory APIs to change the system-wide socket implementation:

 o http://jdk.java.net/13/release-notes#JDK-8224477 - delivered in
   build 23
 o http://jdk.java.net/13/release-notes#JDK-8216978 - delivered in
   build 20
 o http://jdk.java.net/13/release-notes#JDK-8220493 - delivered in
   build 13

**OpenJDK builds *- JDK 14 Early Access build 6 is **now available **at 
: - jdk.java.net/14/*


 * These early-access, open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception .
 * Changes of interest since last email
 o 8225239: Refactor NetworkInterface lookups
 o 8226409: Enable argument profiling for sun.misc.Unsafe.put*/get*
 * JEP targeted to JDK 14:
 o JEP352: Non-Volatile Mapped
 * Bug fixes reported by Open Source Projects  :
 o JDK-8227080 - fixed in b5 -reported by Eclipse Jetty

The Java Crypto Roadmap 
 has been updated :


 * Released - 16-July-2019 - Release Affected JDK 7u231 - Disabled
   Kerberos DES encryption by default
 * Targeted Date - 2020 - Targeted Release - JDK 8 - Transport Layer
   Security (TLS) 1.3

Rgds,Rory

[1] http://openjdk.java.net/projects/jdk/13/#Schedule
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003170.html


--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland