Brian Fox

Lighter jvm install at the cost of complexity everywhere else?

Actually we've been talking to the team since JavaOne but not making progress.

I think two comments here are worth responding to:

First the Gradle vote was clearly an accident. As you noted, I had already cleared my vote before your comment. Somehow I had clicked it when viewing the rising link list and I reset it when I noticed later that day. I never noticed before that you could vote directly in the rising link tab...which frankly seems pointless, why let you vote without first reading an article or at least the summary?

I don't vote down things simply because I don't like the technology, and voting down a blog about adding Gradle to support to Idea is completely pointless, since I don't use either of them. (though I'm flattered that you watch me enough to take screenshots of votes)

For the record, I have nothing against Gradle or IDEA and neither does Sonatype. Take a look at many of the talks Jason has done, even he says use what you want, we just care about interoperability at the repository layer...which btw was the overarching theme of this post.

Second, on copying your property support, I can't fault you for thinking this was a copy given the timing of releases, but we started RDF based indexing to support the metadata in July. Alin has been working on this type of technology for years and it was one of the first things he did when joining Sonatype. Unfortunately for us, the 1.4 release held up some of this work. You don't even have to take my word for it, see the history here and here. It looks like your property support was released on October 29th, far after we where done developing the plugin. I could point out plenty of examples in the opposite direction, but I don't see any point...

I think Paul Grahm would sum up your comment as a series of DH1 Ad Hominem attacks since you didn't really address any of the key technical facts that I pointed out.

It's also worth reading these other posts:

http://java.dzone.com/articles/tale-two-repository-managers

http://today.java.net/article/2010/01/04/maven-repository-managers-enterprise

Regarding the performance gained by eager fetching, we evaluated eager fetching of JARs in early Nexus versions but decided to rank it low on our priority list for a couple of reasons:

1) It only benefits the first user requesting a set of artifacts. Typically the bottleneck is the external bandwidth and thus if the first user needs to download 25mb of jars, the order of the requests would only marginally affect the overall download time. However, if you're copying from another system on a high speed LAN (as you would likely use for benchmarks to control variation in network congestion) then the network wouldn't be the bottleneck and things would in fact test out faster.

2) Maven makes requests for POMs during the resolution process that may ultimately be evicted from the graph. Fetching these jars is potentially wasteful and could result in build slowdown as valid requests have to contend with bandwidth from pre-fetched JARs which will not be used. Maybe that's not an issue if you process it as a background process, but if that's the case, I wonder how often the eager fetching is requesting JARs before Maven does.

3) Recent versions of Maven are able to make parallel requests for artifacts, and are pretty effective at saturating the available network when needed, I would imagine this would cause some interactions with pre-fetching.

In short, I'm sure certain benchmarks in a completely clean system proxying a lan may run faster, but I would expect real world performance to be "typically negligible." Therefore in our view, the risk of complexity for the reward of small gains didn't pan out, but hey that's where choice for the user is better, I think it's just important to have perspective on the gains in real scenarios.

Regarding the POM cleanup implementation, I also have pretty serious concerns about the implications of rewriting poms (not to mention the implied subtext of that blog title). I won't go into the details here but I would classify this also in the low upside, high downside category.

Regarding the importing and exporting of the repository configuration, this seems like a moot point when you have a full REST API. In Nexus, everything is done over REST, so that means you can import and export all the configuration, not just the repository config via wget if you feel like it.

In addition to the REST, Nexus supports the repository-metadata.xml standard used on Maven Central, where key information about a repository is available right inside the repo. This means that if so configured, anyone can discover the canonical urls for proxies, other known mirrors, what repos are contained by a group, and the release and snapshot type. This has been supported by Nexus since 1.3. Take a look here for a few examples of this metadata:

• http://repo1.maven.org/maven2/.meta/repository-metadata.xml;
• https://repository.apache.org/content/groups/snapshots-group/.meta/repository-metadata.xml

The ability to search remote indexes is one of the most used features of Nexus, I'm pretty surprised you've labeled this as a downside of Nexus. In fact, the Index is the most requested file on Central, we serve >12TB of that index alone every month.

The ivy/gradle comment has been answered already by users, but we have many user using ivy specifically and every one that I've asked if / what ivy support is needed, the answer is unanimously: they don't, it works fine as it is since all the tools fully support the Maven layouts. We've instead focused on higher level functionality that isn't supported anywhere else like bridging P2/ OBR / Eclipse Sites with Maven.

Nexus also does have the ability to include/exclude artifacts, it's been there since Proximity and is called routing rules. We take a different approach than Artifactory or Archiva. Instead of saying repo "A" can contain "foo" and repo "B" contains "bar", we instead make it possible to say "for foo, look only in a, for bar - it can't be in x". This is a more natural process that matches the concept that Maven is looking for an artifact, so guide it to where (or where not) to look. For example, it's one entry globally to say "com.mycompany" is only ever going to be in "Releases or Snapshots".

The Nexus security subsystem is much more fine grained and allows you to fully partition repositories by role. This is done via regular expressions, which is the only way to fully describe the kinds of security rules our corporate customers want. Sometimes for example they want to use a single repository to serve artifacts to the public, but they want the sources to be available only to internal employees. Implying that regexp is bad because it's complicated completely overlooks the power that it provides.

The Apache repository is a great example of the partitioning in action. We use only a single pair of release and snapshot repositories yet each project is only able to deploy the artifacts "owned" by their project. Fortunately this is pretty easy as it's based on groupId like org/apache/[project] most of the time. But we could just as easily control security like org/apache/bundles/[project]-xxx.jar if we needed to. Maintaining very large instances is much easier to deal with when you don't need to make a new repo for each group or team you have to secure.

The external realm integration also fully supports authentication as well as authorization in a way that doesn't require each user to be known ahead of time to Nexus. This is very important when you have more than a handfull of users in your corporate LDAP/AD system.

The bottom line is that Nexus' feature set is driven entirely by the users but with a focus on Corporate / Enterprise use. Differences like the security, searching and storage seem trivial at first glance, but become extremely important when things start to scale.

Hi Mitch,

Nexus Pro is comprised of open source Nexus core and additional plugins bundled together. Those plugins themselves are not all open source.

Thanks, Brian

Nearly finished I thought and went on to deploy Nexus. Deploying Nexus war in Tomcat went fine. Configuring Nexus went not. I wasn’t able to find a single line of documentation regarding using Nexus not run in standalone mode, even though it is available for download in war format.

The configuration of Nexus is 100% done via the UI, so there is no difference between the configuration once you have it running in Tomcat vs the Standalone mode. Was there something in particular you were looking for that you couldn't find?

Alexandro, Most of your comment is simply not correct.

The java.dev.net repository is not central, http://repo1.maven.org/maven2 is. No projects are allowed to deploy to central directly. Only Maven PMC members have access to this machine. All artifacts that get on Central are rsynced from various sources. If you want to get artifacts into Central, you need to setup your own repository and request that we rsync it, or use one provided for you.

At Sonatype, we have setup an instance of Nexus for projects who simply need a hosted Maven repository. You can read more about that here. We've also offered to help Kenai get an instance setup, I'll have to ping Nick again to see if they're ready to move forward. In the meantime, any oss project, Kenai hosted or not is welcome to use our oss instance.

--Brian Fox

Apache Maven PMC

If you're looking for a repository manager, be sure to also take a look at Nexus

Also, there's a new chapter 8 in the Maven: The definitive guide that follows up on chapter 7 to show some multi-module optimizations. This will be published in the book version alpha-3.