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 > > > > >
