Chapter 11 - Public Maven Repos?

[johnament]

Like most enterprise developers, I have a global maven repo available at work which we mount all of our dependencies on. This includes the EAP binaries and the repo that is provided (which is just uploaded as a zip to our Artifactory instance). So easy a caveman could do it.

With public tools like bintray from jfrog, would it be useful to talk about how to use those to manage your repositories? It seems like overkill needing to configure Jenkins on your cloudbees instance to point to this directory. Plus this sets some bad precendence that you should manually upload the repo to your build machine. Most cases it should be uploaded to your corporate repo host for use. Plus you now have two copies of the binaries floating around. If any of them need to be updated, you now need to update two locations.

[ALRubinger]

Another interesting and valid approach, thank you.

The two aren't mutually-exclusive, and each have their own benefits and
drawbacks. For instance, I haven't seen evidence supporting the assertion
that "most" enterprise developers have access to their own private
repository manager, so that's a bit of a barrier to entry. And without
this element, users have no choice but to upload the repo to the build
server.

Nonetheless, I agree that yours is the preferable approach if a private
repo manager is available, so I'll add some description and notes to that
effect in the chapter. Thank you again!

(You earned yourself an Arquillian T-Shirt)

[aslakknutsen]

I can back up that claim.

Not uncommon that central is even blocked in firewalls.

[johnament]

Yep, I've heard of people blocking the external repos from developer's workstations. Depends on how well the company understands maven and decides to block it. Right now, we're not blocking access to the repos (simply because searching in that repo is easier than searching through the corp one). We do have a forced override in our maven settings that forces all traffic in to our artifactory instance, and created a special "public repository" that aggregates all the good stuff together (filters things out like beta's and external snapshots).

When implemented properly, the two are mutually exclusive. No one, not even the build server, would have access to that extra repository if mirrorOf is populated (which it typically is). I see many instances where developers are using the repository, and may not even be aware of it. I definitely wouldn't remove what you have in there, but a note makes the most sense.

(can one win one t-shirt per issue? I want to be able to outfit myself for a week in arquillian)

[ALRubinger]

My mutually-exclusive comment was in reference to the necessity for both
approaches to be covered, as a private Maven repo is not an option which is
available to everyone (and certainly isn't the out-of-the-box Maven
experience). :)

[johnament]

I see, you were playing loose and fast with mutually exclusive.

If I had to guess, 50% of developers will simply take the EAP maven repo and unzip it into ~/.m2/repository for prototyping. 40% of developers will ignore it and use the default maven artifacts (since the EAP bundle isn't publicly available and carries with it an LGPL v2.1 license; and you may not want to be tied to a redhat branded JAR file)

[ALRubinger]

Oh no, a large majority absolutely don't install the EAP repo at all,
they'll just use the EAP binary.

Fast and loose? Surely we've determined that both approaches require
coverage, so one does not recuse the other. :)
On Jun 30, 2013 11:37 AM, "John Ament" [email protected] wrote:

I see, you were playing loose and fast with mutually exclusive.

If I had to guess, 50% of developers will simply take the EAP maven repo
and unzip it into ~/.m2/repository for prototyping. 40% of developers will
ignore it and use the default maven artifacts (since the EAP bundle isn't
publicly available and carries with it an LGPL v2.1 license; and you may
not want to be tied to a redhat branded JAR file)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/62#issuecomment-20252897
.