If I recall correctly the “testing” is really just to compare our own developed version vs the jdnssec version. As far as I am concerned we have proven it is more than adequate by running in production so those tests are no longer necessary. +1 on removing the now unnecessary dependency completely.
On Thu, Nov 15, 2018 at 15:39 Rivas, Jesse <[email protected]> wrote: > If consensus is to keep the jdnssec module for testing purposes, the > download step could be removed from the build_rpm.sh script and > documentation added on where to download the .jar and how to build with > maven. That way, the .jar isn't downloaded by default, won't cause the > build to fail, and it would be easier to maintain documentation on where to > get the .jar than maintain the build script if the location changes. > Alternatively, the URL for download could just be updated and continue to > download and build as it has in the past. > > If you feel strongly one way another on updating the download URL in the > build script, keeping the module in Traffic Router and removing the > download step from build_rpm.sh, or removing the module completely, please > share your viewpoint. > > -Jesse > > On 11/15/18, 12:39 PM, "Robert Butts" <[email protected]> wrote: > > Just FYI, it looks like it's on Github, by the original author: > https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it > looks > like it'd be trivial to fix and keep, if we wanted to. > > > On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan < > [email protected]> > wrote: > > > +1 on removing > > > > I'm not super familiar with Java/maven build systems, but I don't > see a > > problem with keeping it in the tests if that's possible - but code > that > > isn't used shouldn't be a dependency. > > ________________________________________ > > From: Chris Lemmons <[email protected]> > > Sent: Thursday, November 15, 2018 12:24 PM > > To: [email protected] > > Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic > Router > > > > I'm good with removing it entirely from any even optional use in the > > code as it could run in production. But testing frameworks against > one > > another is absolutely of value, and falls squarely into an adequate > > licensing exception for LGPL use. I'm -0 on removing it from the > > tests. If we can't find an easy place for automatic download, we > > should remove it, but if it's reasonable to swap out the source, or > > allow folks to build and provide their own, I think we'd gain by > > including it in our testing scheme. > > On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters < > [email protected]> > > wrote: > > > > > > +1 > > > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <[email protected]> > wrote: > > > > > > > > eliminate an unnecessary dependency? +1 (+1000 if I could...) . > > > > > > > > If it's kept around only for testing purposes, the tester > should deal > > > > with that separately: perhaps a documentation update is > warranted in > > that > > > > case. > > > > > > > > -dan > > > > > > > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse < > [email protected] > > > > > > > wrote: > > > > > > > > > Hi Traffic Controllers, > > > > > > > > > > Currently, the .pkg script is failing to build the Traffic > Router rpm > > > > > because the build_rpm.sh script for TR attempts to download > > > > > jdnssec-tools.jar from verisign ( > > > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases > ), > > which is > > > > > no longer available. Traffic Router used to leverage code from > the > > > > > jdnssec-tools.jar for zone signing, but it has since been > replaced > > with our > > > > > own implementation. All of the classes and subsequent tests > that use > > the > > > > > jdnssec package were previously moved from “core” to a separate > > module in > > > > > Traffic Router (called “jdnssec”) that is not included in the > maven > > build > > > > > by default, and was kept for legacy and testing purposes. I > would > > like to > > > > > propose removing the JDNSSEC dependency from Traffic Router > > altogether; > > > > > this would include removing the jdnssec module in Traffic > Router and > > > > > subsequent pom files, and removing the “installDnsSec” > function from > > the > > > > > build_rpm.sh script in Traffic Router that attempts to download > > > > > jdnssec-tools.jar and fails if it is unsuccessful. > > > > > > > > > > Please let me know if there is any opposition to removing the > > external > > > > > JDNSSEC dependency from Traffic Router, as it is no longer > used for > > zone > > > > > signing and is no longer available for download from verisign. > > > > > > > > > > -Jesse > > > > > > > > > >
