directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [directory-server] kwart commented on a change in pull request #40: DIRSERVER-2326 Use Bouncy Castle to generate certificates
Date Sat, 12 Sep 2020 21:27:20 GMT

kwart commented on a change in pull request #40:
URL: https://github.com/apache/directory-server/pull/40#discussion_r487009598



##########
File path: all/pom.xml
##########
@@ -163,11 +163,11 @@
               <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
               <filters>
                 <filter>
-                  <artifact>org.bouncycastle:bcprov-jdk15on</artifact>
+                  <artifact>*:*</artifact>

Review comment:
       We can keep the smaller scope, but I think we never want to include the signature files.
So upgrade of a library which suddenly starts to sign its JARs wouldn't require the filter
change.
   
   @coheigea So do you think we should have the smaller scope and filter the libraries with
signed classes if a need comes?

##########
File path: all/pom.xml
##########
@@ -163,11 +163,11 @@
               <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
               <filters>
                 <filter>
-                  <artifact>org.bouncycastle:bcprov-jdk15on</artifact>
+                  <artifact>*:*</artifact>

Review comment:
       We can keep the smaller scope, but I think we never want to include the signature files.
So upgrade of a library which suddenly starts to sign its JARs wouldn't require the filter
change.
   
   @coheigea So do you think we should have the smaller scope and filter the libraries with
signed classes if a need comes?

##########
File path: all/pom.xml
##########
@@ -163,11 +163,11 @@
               <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
               <filters>
                 <filter>
-                  <artifact>org.bouncycastle:bcprov-jdk15on</artifact>
+                  <artifact>*:*</artifact>

Review comment:
       We can keep the smaller scope, but I think we never want to include the signature files.
So upgrade of a library which suddenly starts to sign its JARs wouldn't require the filter
change.
   
   @coheigea So do you think we should have the smaller scope and filter the libraries with
signed classes if a need comes?

##########
File path: all/pom.xml
##########
@@ -163,11 +163,11 @@
               <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
               <filters>
                 <filter>
-                  <artifact>org.bouncycastle:bcprov-jdk15on</artifact>
+                  <artifact>*:*</artifact>

Review comment:
       We can keep the smaller scope, but I think we never want to include the signature files.
So upgrade of a library which suddenly starts to sign its JARs wouldn't require the filter
change.
   
   @coheigea So do you think we should have the smaller scope and filter the libraries with
signed classes if a need comes?

##########
File path: all/pom.xml
##########
@@ -163,11 +163,11 @@
               <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
               <filters>
                 <filter>
-                  <artifact>org.bouncycastle:bcprov-jdk15on</artifact>
+                  <artifact>*:*</artifact>

Review comment:
       We can keep the smaller scope, but I think we never want to include the signature files.
So upgrade of a library which suddenly starts to sign its JARs wouldn't require the filter
change.
   
   @coheigea So do you think we should have the smaller scope and filter the libraries with
signed classes if a need comes?

##########
File path: all/pom.xml
##########
@@ -163,11 +163,11 @@
               <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
               <filters>
                 <filter>
-                  <artifact>org.bouncycastle:bcprov-jdk15on</artifact>
+                  <artifact>*:*</artifact>

Review comment:
       We can keep the smaller scope, but I think we never want to include the signature files.
So upgrade of a library which suddenly starts to sign its JARs wouldn't require the filter
change.
   
   @coheigea So do you think we should have the smaller scope and filter the libraries with
signed classes if a need comes?

##########
File path: all/pom.xml
##########
@@ -163,11 +163,11 @@
               <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
               <filters>
                 <filter>
-                  <artifact>org.bouncycastle:bcprov-jdk15on</artifact>
+                  <artifact>*:*</artifact>

Review comment:
       We can keep the smaller scope, but I think we never want to include the signature files.
So upgrade of a library which suddenly starts to sign its JARs wouldn't require the filter
change.
   
   @coheigea So do you think we should have the smaller scope and filter the libraries with
signed classes if a need comes?

##########
File path: all/pom.xml
##########
@@ -163,11 +163,11 @@
               <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
               <filters>
                 <filter>
-                  <artifact>org.bouncycastle:bcprov-jdk15on</artifact>
+                  <artifact>*:*</artifact>

Review comment:
       We can keep the smaller scope, but I think we never want to include the signature files.
So upgrade of a library which suddenly starts to sign its JARs wouldn't require the filter
change.
   
   @coheigea So do you think we should have the smaller scope and filter the libraries with
signed classes if a need comes?




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org


Mime
View raw message