search

arquillian / continuous-enterprise-development

Testable Solutions for Modern Applications
http://continuousdev.org/
116 stars 150 forks source link

Chapter 11 - Public Maven Repos? #62

Open johnament opened 11 years ago

johnament commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

I can back up that claim.

Not uncommon that central is even blocked in firewalls.

johnament commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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" notifications@github.com 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/arquillian/continuous-enterprise-development/issues/62#issuecomment-20252897 .