Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Move rest of snippets in userguide folder to parent

    • -41
    • +0
    ./comonentMetadataRules.sample.conf
  1. … 3416 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

  1. … 21 more files in changeset.
Spike invalidating in-memory cache at the end of a build

  1. … 21 more files in changeset.
Spike invalidating in-memory cache at the end of a build

  1. … 20 more files in changeset.
Add "docs type" and "status" to the JVM describer

  1. … 2 more files in changeset.
Add "docs type" and "status" to the JVM describer

  1. … 2 more files in changeset.
Add "docs type" and "status" to the JVM describer

  1. … 2 more files in changeset.
Align the ambiguous selection error messages with no matching case

This commit polishes improved error messages in variant selection by

making the "ambiguous" case closer to what we have for the "no matching"

case.

    • -24
    • +14
    ./failRuntimeClasspathResolve.out
  1. … 20 more files in changeset.
Align the ambiguous selection error messages with no matching case

This commit polishes improved error messages in variant selection by

making the "ambiguous" case closer to what we have for the "no matching"

case.

    • -24
    • +14
    ./failRuntimeClasspathResolve.out
  1. … 20 more files in changeset.
Align the ambiguous selection error messages with no matching case

This commit polishes improved error messages in variant selection by

making the "ambiguous" case closer to what we have for the "no matching"

case.

    • -24
    • +14
    ./failRuntimeClasspathResolve.out
  1. … 20 more files in changeset.
Align the ambiguous selection error messages with no matching case

This commit polishes improved error messages in variant selection by

making the "ambiguous" case closer to what we have for the "no matching"

case.

    • -24
    • +14
    ./failRuntimeClasspathResolve.out
  1. … 19 more files in changeset.
Make assertions of sample snippet test more lenient

The selected 'commons-lang3' artifact can change over time as

we request 'latest.rc'. So we just check that resolution is successful

but not which artifact was selected.

Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -55
    • +16
    ./failRuntimeClasspathResolve.out
  1. … 38 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -55
    • +16
    ./failRuntimeClasspathResolve.out
  1. … 35 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -55
    • +16
    ./failRuntimeClasspathResolve.out
  1. … 38 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -55
    • +16
    ./failRuntimeClasspathResolve.out
  1. … 38 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -55
    • +16
    ./failRuntimeClasspathResolve.out
  1. … 38 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -55
    • +16
    ./failRuntimeClasspathResolve.out
  1. … 38 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -55
    • +16
    ./failRuntimeClasspathResolve.out
  1. … 33 more files in changeset.
Make it possible to use an ecosystem describer in more cases

Before this commit the describer would only be used if the same set of attributes

was found. This means that if the consumer added, or removed, one attribute, we

would lose the benefit of better user error messages. With this change, we try

to find the _best matching_ describer, if any.

    • -81
    • +80
    ./failRuntimeClasspathResolve.out
  1. … 20 more files in changeset.
Make it possible to use an ecosystem describer in more cases

Before this commit the describer would only be used if the same set of attributes

was found. This means that if the consumer added, or removed, one attribute, we

would lose the benefit of better user error messages. With this change, we try

to find the _best matching_ describer, if any.

    • -81
    • +80
    ./failRuntimeClasspathResolve.out
  1. … 20 more files in changeset.
Make it possible to use an ecosystem describer in more cases

Before this commit the describer would only be used if the same set of attributes

was found. This means that if the consumer added, or removed, one attribute, we

would lose the benefit of better user error messages. With this change, we try

to find the _best matching_ describer, if any.

    • -81
    • +80
    ./failRuntimeClasspathResolve.out
  1. … 20 more files in changeset.
Make it possible to use an ecosystem describer in more cases

Before this commit the describer would only be used if the same set of attributes

was found. This means that if the consumer added, or removed, one attribute, we

would lose the benefit of better user error messages. With this change, we try

to find the _best matching_ describer, if any.

    • -81
    • +80
    ./failRuntimeClasspathResolve.out
  1. … 19 more files in changeset.
Update to latest commons lang 3 release

This is a quick fix: the test should not check the dynamic version.

Improve error reporting for the Java ecosystem

This commit introduces improved error messages for the Java ecosystem

in case of variant matching errors.

    • -33
    • +33
    ./failRuntimeClasspathResolve.out
  1. … 26 more files in changeset.
Improve error reporting for the Java ecosystem

This commit introduces improved error messages for the Java ecosystem

in case of variant matching errors.

    • -33
    • +33
    ./failRuntimeClasspathResolve.out
  1. … 26 more files in changeset.
Improve error reporting for the Java ecosystem

This commit introduces improved error messages for the Java ecosystem

in case of variant matching errors.

    • -33
    • +33
    ./failRuntimeClasspathResolve.out
  1. … 26 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

  1. … 46 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

  1. … 46 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

  1. … 46 more files in changeset.