Skip to content
Snippets Groups Projects
  • dpsutton's avatar
    3ad532b9
    License improvements (#23120) · 3ad532b9
    dpsutton authored
    * Switch from classpath to basis for license information
    
    Previously we were chopping the classpath up and starting from there so
    we just had a sequence of strings pointing at jars. Now using the basis
    so we use a _much_ nicer map like
    
    ```clojure
    {org.bouncycastle/bcprov-jdk15on
     {:mvn/version "1.70",
      :deps/manifest :mvn,
      :dependents
      [buddy/buddy-core
       org.bouncycastle/bcutil-jdk15on
       org.bouncycastle/bcpkix-jdk15on],
      :parents
      #{[buddy/buddy-sign buddy/buddy-core]
        [buddy/buddy-sign
         buddy/buddy-core
         org.bouncycastle/bcpkix-jdk15on
         org.bouncycastle/bcutil-jdk15on]
        [buddy/buddy-sign
         buddy/buddy-core
         org.bouncycastle/bcpkix-jdk15on]},
      :paths
      ["/Users/dan/.m2/repository/org/bouncycastle/bcprov-jdk15on/1.70/bcprov-jdk15on-1.70.jar"]}
     ...}
    
    ```
    
    So we now have a true name for the dependency, a path to it, and a
    version. No need to string munge on the classpath.
    
    * Read pom with `maven-model`
    
    rather than us trying to parse the xml, use a maven model on it. Note
    there is another level we can go to that would be aware of parent poms
    but we don't need the overkill here. That's far heavier than what we
    need to do in this instance.
    
    Note this also reorders the algo:
    previously
    - license in jar
    - backfill
    - license from pom
    
    Now:
    - license from jar
    - license from pom
    - backfill
    
    Possible we will want to actually just skip the license from pom bit
    since it only gives us a name and a url and not the full text. We could
    match on these and identify them with the resources used from the
    backfill if we like.
    
    Another important change is that this no longer throws if it cannot find
    a pom for a jar. This came up for the following lib:
    
    ```
    ;; deps.edn
    com.google.cloud.sql/postgres-socket-factory
    {:mvn/version "1.6.0"} ; Secure Google Cloud SQL postgres connections
    
    ;; override:
    "com.github.jnr"             {"jffi$native" {:resource "apache2_0.txt"}}
    ```
    Which was from a 3rd party PR.
    
    * Way to generate libs that need overrides
    
    * Remove unused fns, add tests, cleanup docstring
    
    * Don't leave tap> in
    
    Two poms blow up with BOM errors
    
    - jakarta.activation-1.2.1.pom
    - jakarta.activation-api-1.2.2.pom
    
    > UTF-8 BOM plus xml decl of iso-8859-1 is incompatible
    > (position: START_DOCUMENT seen <?xml version="1.0" encoding="iso-8859-1"... @1:41)
    
    It has a parent pom and not a license so we wouldn't find it anyways.
    License improvements (#23120)
    dpsutton authored
    * Switch from classpath to basis for license information
    
    Previously we were chopping the classpath up and starting from there so
    we just had a sequence of strings pointing at jars. Now using the basis
    so we use a _much_ nicer map like
    
    ```clojure
    {org.bouncycastle/bcprov-jdk15on
     {:mvn/version "1.70",
      :deps/manifest :mvn,
      :dependents
      [buddy/buddy-core
       org.bouncycastle/bcutil-jdk15on
       org.bouncycastle/bcpkix-jdk15on],
      :parents
      #{[buddy/buddy-sign buddy/buddy-core]
        [buddy/buddy-sign
         buddy/buddy-core
         org.bouncycastle/bcpkix-jdk15on
         org.bouncycastle/bcutil-jdk15on]
        [buddy/buddy-sign
         buddy/buddy-core
         org.bouncycastle/bcpkix-jdk15on]},
      :paths
      ["/Users/dan/.m2/repository/org/bouncycastle/bcprov-jdk15on/1.70/bcprov-jdk15on-1.70.jar"]}
     ...}
    
    ```
    
    So we now have a true name for the dependency, a path to it, and a
    version. No need to string munge on the classpath.
    
    * Read pom with `maven-model`
    
    rather than us trying to parse the xml, use a maven model on it. Note
    there is another level we can go to that would be aware of parent poms
    but we don't need the overkill here. That's far heavier than what we
    need to do in this instance.
    
    Note this also reorders the algo:
    previously
    - license in jar
    - backfill
    - license from pom
    
    Now:
    - license from jar
    - license from pom
    - backfill
    
    Possible we will want to actually just skip the license from pom bit
    since it only gives us a name and a url and not the full text. We could
    match on these and identify them with the resources used from the
    backfill if we like.
    
    Another important change is that this no longer throws if it cannot find
    a pom for a jar. This came up for the following lib:
    
    ```
    ;; deps.edn
    com.google.cloud.sql/postgres-socket-factory
    {:mvn/version "1.6.0"} ; Secure Google Cloud SQL postgres connections
    
    ;; override:
    "com.github.jnr"             {"jffi$native" {:resource "apache2_0.txt"}}
    ```
    Which was from a 3rd party PR.
    
    * Way to generate libs that need overrides
    
    * Remove unused fns, add tests, cleanup docstring
    
    * Don't leave tap> in
    
    Two poms blow up with BOM errors
    
    - jakarta.activation-1.2.1.pom
    - jakarta.activation-api-1.2.2.pom
    
    > UTF-8 BOM plus xml decl of iso-8859-1 is incompatible
    > (position: START_DOCUMENT seen <?xml version="1.0" encoding="iso-8859-1"... @1:41)
    
    It has a parent pom and not a license so we wouldn't find it anyways.
Code owners
Assign users and groups as approvers for specific file changes. Learn more.