Sonatype - Latest Comments

Re: Evaluating OSS logistics solutions? Consider these 9 tips.

Augastin — Fri, 11 Mar 2016 04:42:08 -0000

Developing software tools will be reducing the risk of internet provider components is the best choice.

Re: Please Containerize Your Excitement: Nexus 3 Milestone 5 Release

Brian Fox — Wed, 30 Sep 2015 19:01:54 -0000

Hi Davi, sorry about that. Ping me at brianf :at: Sonatype :dot: com and I can get you in touch with the right people.

Re: Please Containerize Your Excitement: Nexus 3 Milestone 5 Release

Davi Santos — Wed, 30 Sep 2015 16:11:29 -0000

How can I get in touch you guys?!
Nobody picked up the phone!

Re: Chevy and DevOps: What the Wi-Fi?

Derek E. Weeks — Tue, 21 Jul 2015 11:23:42 -0000

To better understand other implications of wi-fi being available to the auto industry, have a look at this July 2015 article in WIRED: http://www.wired.com/2015/0...

Then consider how your organization might learn to react and shorten mean time to remediate flaws in software.

Re: Continuous Delivery and Nexus

PVK — Tue, 21 Jul 2015 03:19:18 -0000

Hi,
I am working Jenkins job which uses SBT to build the Scala project and generates some artifacts. I want to publish these artifacts on Nexus server throught Jenkins CI server only. I have not yet come across any Jenkins plugin for that. Could you please help me out for this ?

Re: Simplified Releases to the Central Repository with Nexus

sonatype — Thu, 02 Apr 2015 15:45:28 -0000

Rishi,

Depending on the build tool used the configuration is different. The best way to see different ones is by checking out the overview about your artifact in the Central Repository search site. E.g for yours it would be http://search.maven.org/#ar...

Re: Simplified Releases to the Central Repository with Nexus

Rishi — Sat, 28 Mar 2015 01:11:01 -0000

Hi manfred,

Nice explanation. I released my project for serial port communication http://www.embeddedunveiled... on maven central. The group id is com.embeddedunveiled and artifact is scm. Please guide me which is the link that I should give to other developers so that they can integrate my artifact in their project.

Re: Book Update: Repository Management with Nexus

sonatype — Sun, 01 Mar 2015 01:00:38 -0000

The latest version is available online. It only receives minor maintenance. There are no plans for a 2nd edition at this stage.

Re: Use Maven to Find Security Vulnerabilities and Viral Licenses in Applications

Frank Abay — Fri, 06 Feb 2015 04:15:44 -0000

getting satisfies training Security Guard.

Re: Chevy and DevOps: What the Wi-Fi?

Derek E. Weeks — Thu, 05 Feb 2015 11:19:12 -0000

Kevin,

Great point. I, too, would not want to open my car to the potential of an even bigger security flaw. That is something that the automakers and any IoT device manufacturer will have to consider as part of the overall quality of their offering. Anything connected to the internet has the possibility of being breaches at some point, given the right circumstances. I am sure that the automakers and and IoT devices makers are taking security concerns very seriously (and for those that are not, they will have to start making it a priority).

That said, think of all of the benefits here. In the blog above, I reference 2.3M people that have to make an appointment with their car dealers, where they then have to go into their dealers for a few hours for a free-of-cost software update.

While it is important that all above mentioned do just that, I am glad that I am not one of those people. I don't want to take a couple of hours out of my Saturday morning to go and visit my car dealer for a software update. Just like I would not like to drive to Home Depot for a software update to a Nest thermostat or drive to a hospital to get a critical security update in an internet connected insulin device. From a customer experience perspective, these kinds of trips would degrade my overall experience with a product.

Moving forward, there will be many more discussions about overall quality experiences in our connected worlds. Those experiences will hopefully make us happier, save us time, bring us new capabilities, and keep us safe.

Thanks again for weighing in on this topic and for reading my blog. Have a great day!

Re: Learning the Nexus REST API: Read the Docs or Fire Up a Browser

Tim O'Brien — Thu, 05 Feb 2015 10:12:15 -0000

It is frustrating that the documentation isn't posted anywhere but through that really difficult to access link. I'm unable to read the documentation for the Nexus REST API because I don't have access to our servers as an Administrator.

Also, the original author of this post is an idiot. ;-)

Re: Chevy and DevOps: What the Wi-Fi?

Kevin Jordan — Thu, 05 Feb 2015 09:49:48 -0000

I'm not sure I'd like remote updates to be able to be pushed to the car since if you can reprogram the car remotely, what's to stop that from becoming an even bigger security flaw than BMW's door flaw?

Re: Rubyists Rejoice – Nexus Supports RubyGem Repositories

Michael Arlt — Thu, 29 Jan 2015 08:22:25 -0000

What is the recommended way(s) to provide (successful tested) rubygems from the first proxy-repository to the next group of servers (next repository?)? Is this done with deactivating repos (offline), copying and reindexing or can the staging-features be used?
It would be nice, if you can explain it in detail.
Many thanks!

Re: Does Nexus Pro Support Ant + Ivy Builds? Yes it does.

sonatype — Thu, 18 Sep 2014 12:10:41 -0000

No. Ivy repositories are not supported by Nexus OSS or Pro at this time. However in most cases Maven repositories are the preferred choice mostly for interoperability with other build tools like Maven, SBT and others. More detail can be found in http://books.sonatype.com/n...

Re: Does Nexus Pro Support Ant + Ivy Builds? Yes it does.

Bryan — Thu, 18 Sep 2014 06:52:24 -0000

Does Nexus OSS support Ivy repos?

Re: Time for Full Open Source Disclosure

Brian Fox — Fri, 12 Sep 2014 10:24:36 -0000

You're absolutely right. Proper component management practices apply pretty equally to Open Source, Commercial and even internally developed components. People tend to start thinking about this problem because they have a fear of 3rd party components, but it's just as important to track and be able to deprecate your own shared components that have issues... or to track entitlements of sensitive components like ones that contain proprietary need-to-know type of algorithms. We approach these different component types the same way because they all have the same fundamental attributes regardless of who actually developed it.

Re: Time for Full Open Source Disclosure

Loïc — Fri, 12 Sep 2014 10:02:10 -0000

If you want to have even more fun, replace "open" with "closed", and think again about every single component, library and software in your systems over which your control goes as far as your software licences liability limits. That's no troll, just plain truth.

Re: Part 3 – [ ________ ] is the Best Policy

Karen Gardner — Tue, 19 Aug 2014 11:03:50 -0000

Great post David - 'People' are well placed at the top of the list. Well aligned with the latest research from Mark Driver at Gartner - esp related to developer involvement. "Open-source software (OSS) governance efforts that do not include developers as critical members of the decision generally result in a decision-making process that doesn't work."

Re: SSL Connectivity for all Central Repository users Underway

Gary Trakhman — Mon, 18 Aug 2014 19:36:23 -0000

Yes, this is not immediately obvious even as a relatively experienced maven user..

Re: SSL Connectivity for all Central Repository users Underway

Brian Fox — Mon, 11 Aug 2014 09:09:41 -0000

Not all the tools may work properly with ssl and many companies have port locked access and forcing everything to ssl will break all those builds. Most of the tools automatically using Central have moved to SSL in the latest versions and once this hits critical mass of the users, then we could consider forcing the remaining stragglers after a period of notification.

Re: SSL Connectivity for all Central Repository users Underway

Scott Contini — Sun, 10 Aug 2014 23:59:57 -0000

You say: "We will continue to participate in the public debate about how to make a
more secure software supply chain available for everyone."

In that regard, I would point you to this discussion on stack overflow:
http://stackoverflow.com/qu...
Particularly note the comment: "Because I am a greedy security engineer, I
wish Sonatype would require that people publish their public keys on
their website. This would make verification of original source much
easier for those who are trying to vet the software."

Re: SSL Connectivity for all Central Repository users Underway

Tim Boudreau — Fri, 08 Aug 2014 06:09:13 -0000

Why not just redirect from http to https?

Re: SSL Connectivity for all Central Repository users Underway

Petr Siroky — Thu, 31 Jul 2014 08:24:13 -0000

Hello, could you elaborate more on this? What are the most important advantages of having own repository manager on the laptop? Thanks.

Re: SSL Connectivity for all Central Repository users Underway

Richard Vowles — Thu, 31 Jul 2014 02:55:52 -0000

All of our developers run their own Nexus on their own machines. I run a Nexus on the laptop I am using. You should never, ever, run without a repository manager.

Re: SSL Connectivity for all Central Repository users Underway

technomancy — Thu, 31 Jul 2014 00:58:17 -0000

Great news; thanks for making this happen.

One question though; the above post makes it sound as if the SSL access offered in the past has been directly available to users of Maven and other tools who don't use repository managers. From what I can tell this was not the case--I could only find documentation for how to use the auth token from a repository manager, meaning that freelance OSS developers and small companies would not be able to benefit from it immediately without setting up additional infrastructure. Is this true, or was I misreading the docs?

I'm really glad for this news, I just think this one point could be clearer.