jarmoniuk/versions-maven-plugin

Versions Maven Plugin

versions-maven-plugin's Issues

Separate comparison from segment utilities in VersionComparator

VersionComparator should compare, and not do other things

AbstractVersionDetails.getLowerBound has the 1-off problem

segment appears to be 0-based

However, the method in the description appears to have the 1-off problem:

protected String getLowerBound( ArtifactVersion version, int segment )
    {
        if ( segment < 0 )
        {
            return null;
        }

        int segmentCount = getVersionComparator().getSegmentCount( version );
        if ( segment > segmentCount )
        {
            throw new InvalidSegmentException( segment, segmentCount,
                    version.toString() );
        }

Remove maven-compat

VersionsHelper should be a Plexus component

Use Maven Resolver

This is the ultimate stage of ditching the ArtifactMetadataSource from maven-compat

Create a common DependencyUpdatesRenderer API

Currently, DependencyUpdatesRenderer uses a completely different interface than DependencyUpdatesXmlRenderer. There's no common factory or a common interface to use the two and the user classes, need to create and handle the two different classes differently.

Here we should create a common API with probably a common abstract factory to instantiate the correct implementation of the renderer.

VersionComparators is a factory

VersionComparators should become VersionComparatorFactory.

The factory method to produce various VersionComparator implementations uses the following rule:

    public static VersionComparator getVersionComparator( String comparisonMethod )
    {
        if ( "numeric".equalsIgnoreCase( comparisonMethod ) )
        {
            return new NumericVersionComparator();
        }
        else if ( "mercury".equalsIgnoreCase( comparisonMethod ) )
        {
            return new MercuryVersionComparator();
        }
        return new MavenVersionComparator();
    }

The criterion (i.e. comparisonMethod) should be moved to the implementation, the factory should simply iterate over registered implementation and choose one fitting the rule.

DisplayPluginUpdates: superPom is exactly the same for all projects

DisplayPluginUpdates parses the superpom with every execution, for every project while it's exactly the same. I think it could be included in the plugin resources.

Migrate to JSR330

https://github.com/eclipse/sisu.plexus/wiki/Plexus-to-JSR330

Check if imported dependency management sections are handled

mojohaus#134 has a fix for UseReleasesMojo. Check if this problem occurs in other mojos and try to fix it there.

DisplayParentUpdates doesn't consider module parents

I've noticed a potential bug in DisplayParentUpdatesMojo. If we have an aggregator project with modules having foreign parents (not the root project), the mojo won't report the updates of the parents.

Migrate to JSR330

Migrate to JSR330 annotations.

Caches should be limited

While reading an email on including maven deamon in maven distribution, realised that maven daemon keeps plugin classes in memory. This means that the caches that we have will only grow with time with such setup.

This ultimately leads to pods getting restarted, but this should probably be controlled and restricted.

Todo: Introduce a limit to those caches.

Create a ticket in maven for #673

mojohaus#673: Fixing NPE in UseDepVersionMojo caused by PatternIncludesArtifactFilter expecting a non-null classifier when using wildcards mojohaus#675

Versions maven plugin doesn't handle password protected entries in servers.xml

UpdatePropertiesMojo causes Maven to parse every pom twice

Currently, UpdatePropertiesMojoBase concrete classes only update the currently Maven-processed file as they are non-aggregate plugins. As such, they rely on Maven recursing into every project of the reactor and then do their job. Maven parses the POM before executing the plugin and it also resolves the properties available in the active profiles.

In order to be able to create property associations, the plugin will then build a tree starting from the child to the parent and parse the untreated POMs of the parents to find the properties. As such, we are actually parsing the POMs for the second time, and what's worse, we're doing that again for every child and also every sibling of the current project in the reactor. That's a lot of wasted work.

At the same time, we are still unable to change the properties which are defined somewhere above in the reactor tree but still within the reactor. See mojohaus#997

The goal of this exercise is to create a new implementation for the mojo(s), and most likely enable/disable it using a feature switch.

Try to disable consulting remote repositories by AbstractMojoTestCase

I notice that the lookup methods take considerable time, it might be related to consulting remote repos, which is not really necessary here. Try to disable that.

Allow passing the RuleSet via @parameter

Currently it's only possible to pass it via the rules.xml file. Allow passing it via parameters in as many mojos as possible.

• (done) allow passing the rules directly via a @parameter
• (done) add another parameter to only pass ignored versions
• (done) should both be present, ignored versions should be added to the ignored versions within the RuleSet object
• (done) at this stage, don't allow passing both the file and the other options
• create tests
• update the manual

allowMajorUpdates, allowMinorUpdates, and allowIncrementalUpdates are not independent

Having three independent options like this makes no sense: allowMajorUpdates implies that the others are allowed, allowMinorUpdates implies that allowMajorUpdates is false and allowIncrementalUpdates is true; allowIncrementalUpdates implies that all others are false.

Either an enum or a counter-based index indicating the unchanged segment would make much more sense.

Remove unnecessary synchronisation in AbstractVersionDetails.set/getCurrentVersion

Usages of PomHelper.getRawModel parse the file twice

Most usages of PomHelper.getRawModel parse the file once again after the rawModel has been provided.

display-plugin-updates goal hang #354 investigation

1. Stack traces are from maven-compat, not from maven-core
2. An old version of DisplayPluginUpdatesMojo specifically used the maven-compat interface:

PR mojohaus#538 switch to non-deprecated ModelInterpolator changed that.

The old model interpolator implements recursion using its own stack (interpolationTarget):

while ( !interpolationTargets.isEmpty() )
{
    Object obj = interpolationTargets.removeFirst();

    traverseObjectWithParents( obj.getClass(), obj );
}

The above code removes the currently processed element from interpolationTarget, just like a function call would do, but then places newly found elements to be processed into that collection.

This risks an infinite recursion loop if the analysed model contains cycles. So, it's possible that the function is fed a model with cycles in it.

UseLatestVersions ignores include- and exclude-fitlers

I've noticed that the inclusion and exclusion of the include- and exclude-filters in UseLatestVersions. To be verified if it's really not effective and fixed.

If verified -- an issue to be created in the upstream project.

Also, I've noticed that UseLatestVersions is an almost exact copy of UseLatestReleases. There's unnecessary code duplication -- to be abstracted or delegated.

Ideally, the two items could be combined into one since there's almost no difference between the two mojos.