Closed dima767 closed 8 years ago
+1 here on behalf of the University of Chicago
+1 here behalf of the University of Utah and the Internet2 NSTIC Grant.
+1
+1 from University of Minnesota.
Any updates?!
Well, it's becoming obvious that this will not happen. Closing for now.
This shouldn't be closed... This is still an issue.
@dima767 Please reopen the issue. We should continue the conversation. Could we get a response from the Duo folks please?
Not having artifacts in maven central also causes problems with update latency, because we'd have no way to determine if a new release is available that fixes a bug, other than checking the repo itself. It also forces us to keep building the code locally, and manage it locally, and go through the pain of upgrading it, if needed, locally. We don't need the source. All we need are the binary APIs. If they are available and ready for public to use because commits are pushed to the repo, please cut a release for the artifacts as well. It takes less than 20 minutes to do so and we are happy to provide instructions on how that might be done.
Hi everyone! We'll look into this! In the mean time, feel free to open a pull request with the requested changes :)
Hi @mschwager thanks for responding :)
Sadly, this is not a change that can be accommodated by a PR. The task at hand is to configure the project such that releases can be possible to Maven Central, and it needs to be done by someone who has commit access to the repo, and permission to sync the artifacts to central.
For example, here is what the Apereo CAS project uses for releases: http://central.sonatype.org/pages/ossrh-guide.html
There are many other tools available other than sonatype that would allow you to sync artifacts with maven central. Since your project is maven based, you basically need to execute:
mvn release:prepare
mvn release:perform
...provided the pom is prepped.
Also note that it would be ideal if you could find a way to publish not just Java/Groovy code, but also bundle all other web artifacts somehow.
Thanks for the information! We have other projects taking priority right now, but we'll definitely get this done shortly after (in the coming weeks).
Thanks for using Duo! And sorry that this took so long to get any attention.
Pleasure. We'll check with you in a couple of weeks then. Plenty of folks in Higher Ed are looking to adopt Duo and integrate it with either CAS or Shibboleth IdP, and this task would only increase the adoption of all platforms. Thanks again!
This would also be beneficial for enterprise deployments. We use the Duo API for reporting and it would be great to not have to worry about unexpected bugs or version drift.
Ping. Any status on this one?
Some of us in the security industry would like to see this, and the other languages' implementations, readily available in their respective platform package managers.
Ping. Any status on this one?
Thanks for all the feedback on this issue. I'm sorry to say that Duo has no current plans to publish this repository to Maven Central.
Going forward, I ask that you forward this request to support@duosecurity.com, in order for Duo to properly track the priority of the request.
Thanks for using Duo!
It is extremely painful to integrate Java support code for Duo into existing projects which forces folks to include the provided code into their projects themselves (which is not good by any good software engineering standards).
Instead, what would be highly desirable, that this code is packaged as a reusable jar library and published to Maven central, so standard build tools like Maven and Gradle could simply discover and include it as just a binary dependency (just like any other standard 3rd party library dependencies).