Multiple optimizations :
- renderLevel() method use static constants instead of rebuilding the strings on each call
- replace + operator usage with more PrintStream.print() calls to reduce temporary strings creation
- reduce usage of MessageBuilder.a() method usage with more PrintStream.print() calls to reduce temporary strings creation
- replace the builder() method with a static import
- replace String.format with a simple string concat to reduce memory allocation (garbage)
- change static constants to class member in MavenSimpleLogger
- add a setLength(int) method in MessageBuilder to enable reuse
- Use the main StringBuilder to append string instead of using a separate one
- Use the StringBuilder.append() with index to avoid String.substring(), less temporary strings
- Reuse the FileSizeFormat object in the while loop avoiding multiple temporary instances creation
- Non-threadsafe FileSizeFormat instance can be make class instance since its formatProgress() method is only called in a synchronized block.
- add a test in a multi-threaded context
- Non-threadsafe StringBuilder instance 'buffer' can be make class instance since it is always called in synchronized methods
- remove synchronized block in transferProgressed() method, the method is synchronized and the block is not needed
- Remove the Collections.synchronizedMap since all methods that use the transfers map are synchronized
Even though this should not be supported, Maven 3.x is always using the 4.0.0 superpom. So if the version is not a supported model version, simply use 4.0.0. Any invalid value will be later verified by the model validator and eventually throw a meaninful exception.
It uses immutable list and while it suggests it allows this below, it actually fails on constructs like this (runtime ONLY):
{noformat}
new DefaultProfileSelector()
.addProfileActivator(new JdkVersionProfileActivator())
.addProfileActivator(new PropertyProfileActivator())
{noformat}
As default ctor creates immutable list, but API kinda suggests this is ok.
---
https://issues.apache.org/jira/browse/MNG-7910
The purpose of the BOM packaging is to more cleanly identity POM that will be consumed as BOM from POM that will be used as parents. The BOMs can be turned into a consumer POM, whereas parents can not loose any information.
The IT associated with this PR is using the Maven model to generate a hocon POM parser. This requires the maven-api-model module to attach the POM as an artifact, and the maven.yml change so that the model is present in the local repository.
Guillaume Nodet
sebastien-doyon
Slawomir Jaranowski
Tim te Beek
juulhobert
Tamas Cservenak
Vivian Kong