Set maven-assembly-plugin version 3.1.1 explicitly for each POM module
Background: There are CI tests failing because the version is not taken
from the parent POM, even if set in the 'pluginManagement' section.
Instead, it is resolved via the Maven Super POM, e.g. 2.2-beta-5, see:
https://maven.apache.org/ref/3.6.3/maven-model-builder/super-pom.html
That assembly plugin version in turn requires plexus-archiver
1.0-alpha-12. The latter cannot be downloaded from Maven Central,
leading to the problems seen during builds.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Replace path separators ';' by ',' in XML test specs
The goal is for them to be canonicalised to platform standard during
test execution. I am not sure if that will fix any tests, but at least I
hope it will not break any.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Replace directory separator '/' and surrogate path separator ',' by
platform-specific separators File.separatorChar and
File.pathSeparatorChar, respectively. Also make sure that replacement
occurs during write access, not read access. This was handled
differently in both sibling classes.
I am not sure if that helps to fix any Linux CI tests, but it is worth a
try.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Try to fix MultiProjectIncrementalTests.testAspectPath_pr265693
Check if path vs. package name discrepancy makes test fail on Linux. On
Windows it passes. So let's find out if file p/Asp.java vs. pkg.Asp
causes the problems.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
This made ModuleTests.testBuildModuleAndApplyAspectsFromAspectPath fail
because a file delete job for a module JAR failed after a previous
compile job had called FileUtil.isZipFile(File) in which the opened zip
file was never closed. A try with resources fixes that.
Maybe the corresponding test worked on Linux before, I did not try. I
just know that Linux is more forgiving about deleting open files while
on Windows they are being locked, which makes Windows the better system
to search for open file leaks.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
AjBuildManager: use try with resources in 2 places
I was debugging something in ModuleTests, trying to find out if there
are resource leaks. They were not in this class but in FileUtil - see
next commit. However, the little refactoring here does not hurt either.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Support Windows 10 and Windows Server 2016/2019 in installer
Those versions were not detected until now, which lead to bogus Windows
batch files forwarding only 9 Ajc parameters to the Java process via
"%1 %2 %3 %4 %5 %6 %7 %8 %9" instead of "%*".
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Lars Grefer [Sat, 15 Aug 2020 14:33:00 +0000 (16:33 +0200)]
Redundant Collection.addAll() call
Reports Collection.addAll() and Map.putAll() calls after instantiation of a collection using a constructor call without arguments. Such constructs can be replaced with a single call to a parametrized constructor which simplifies code. Also for some collections the replacement might be more performant.
Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>
Lars Grefer [Sat, 15 Aug 2020 14:30:09 +0000 (16:30 +0200)]
Collection.toArray() call style
There are two styles to convert a collection to an array: either using a pre-sized array (like c.toArray(new String[c.size()])) or using an empty array (like c.toArray(new String[0]).
In older Java versions using pre-sized array was recommended, as the reflection call which is necessary to create an array of proper size was quite slow. However since late updates of OpenJDK 6 this call was intrinsified, making the performance of the empty array version the same and sometimes even better, compared to the pre-sized version. Also passing pre-sized array is dangerous for a concurrent or synchronized collection as a data race is possible between the size and toArray call which may result in extra nulls at the end of the array, if the collection was concurrently shrunk during the operation.
Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>
Lars Grefer [Sat, 15 Aug 2020 14:25:42 +0000 (16:25 +0200)]
Single Map method can be used
Reports common usage patterns of java.util.Map that could be replaced with Java 8 methods: getOrDefault(), computeIfAbsent(), putIfAbsent(), merge(), or replaceAll().
Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>
Lars Grefer [Sat, 15 Aug 2020 14:06:32 +0000 (16:06 +0200)]
Manual array to collection copy
Reports the copying of array contents to a collection where each element is added individually using a for loop. Such constructs may be replaced by a call to Collection.addAll(Arrays.asList()) or Collections.addAll().
Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>
Lars Grefer [Sat, 8 Aug 2020 01:14:13 +0000 (03:14 +0200)]
Unnecessary boxing
Reports explicit boxing, i.e. wrapping of primitive values in objects. Explicit manual boxing is unnecessary under Java 5 and newer, and can be safely removed.
Signed-off-by: Lars Grefer <eclipse@larsgrefer.de>