[ 
https://issues.apache.org/jira/browse/MRESOLVER-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623597#comment-17623597
 ] 

ASF GitHub Bot commented on MRESOLVER-279:
------------------------------------------

cstamas commented on code in PR #203:
URL: https://github.com/apache/maven-resolver/pull/203#discussion_r1004082829


##########
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/checksum/FileTrustedChecksumsSourceSupport.java:
##########
@@ -151,29 +138,40 @@ protected String configPropKey( String name )
     }
 
     /**
-     * Returns {@code true} if session configuration contains "originAware" 
property set to {@code true}.
+     * Returns {@code true} if session configuration marks this instance as 
enabled.
+     * <p>
+     * Default value is {@code false}.
+     */
+    protected boolean isEnabled( RepositorySystemSession session )
+    {
+        return ConfigUtils.getBoolean( session, false, CONFIG_PROP_PREFIX + 
this.name );
+    }
+
+    /**
+     * Returns {@code true} if session configuration marks this instance as 
origin aware.
+     * <p>
+     * Default value is {@code true}.
      */
     protected boolean isOriginAware( RepositorySystemSession session )
     {
-        return ConfigUtils.getBoolean( session, false, configPropKey( 
CONF_NAME_ORIGIN_AWARE ) );
+        return ConfigUtils.getBoolean( session, true, configPropKey( 
CONF_NAME_ORIGIN_AWARE ) );

Review Comment:
   This has nothing to do with LRM and are they split or not. This way you just 
say "junit 4.13.2 from central has sha-1 
8ac9e16d933b6fb43bc7f576336b8f4d7eb5ba12" and turn on "fail if missing" and you 
are done. Or in other words, this makes possible to maintain lists of checksums 
"by origin" that is IMHO simper than "in bulk", where list would be project 
specific, while this way, those lists are reusable across projects. 
   
   Again, this is just a default, and while I do see valid points for both 
(per-origin and in-bulk), it can be easily overriden,





> Simplify and improve trusted checksum sources
> ---------------------------------------------
>
>                 Key: MRESOLVER-279
>                 URL: https://issues.apache.org/jira/browse/MRESOLVER-279
>             Project: Maven Resolver
>          Issue Type: Task
>          Components: Resolver
>            Reporter: Tamas Cservenak
>            Assignee: Tamas Cservenak
>            Priority: Major
>             Fix For: 1.9.0
>
>
> High level changes:
>  * support class should meddle way less, it is here to provide some utils and 
> protect from future API changes
>  * sparse source: use `FileProcessor` both both, checksum read and write 
> (instead to mix in `Files.write`)
>  * summary source: heavily enhanced, on save it truncate or merges with 
> existing summary file, added change detection (prevents save when no change 
> to save), summary file is written out atomically, and finally file format is 
> made GNU Coreutils formatted, hence is usable with GNU sha1sum and alike OS 
> tools
>  * introduce FileUtils, Java NIO2 based file writing utility
> For both checksum sources the semantics of concurrent lookup/write is cleared 
> up and documented (and fixed in summary). For both purposes (lookup or 
> write), the source must be explicitly enabled.
> Tests redone as well, and should work with any writable trusted checksum 
> source.
> ----



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to