On 20 Dec 07, at 2:58 PM 20 Dec 07, Don Brown wrote:
On Dec 21, 2007 8:38 AM, Mark Struberg <[EMAIL PROTECTED]> wrote:
This must obviously be a guy who never had a build with more than
one single module. So he never
learned that it is NOT a good idea to keep all dependencies in
every single module ;)
causing lots of user complaints. Anytime you have your build depend
on external resources, you introduce a point of failure that is
particularly dangerous when you try to support old releases that may
be many years old.
Bingo. This is where some research into how you are using your tools
pays off. I refrained from responding to the blog because it's really
pretty embarrassing if that's how you have your system setup and
you're making your developers suffer by "downloading the internet".
No enterprise in their right mind uses Maven's central repository
directly. The central repository is a great convenience not a
requirement. Tools like maven-proxy and Proximity have been around for
years, or people have managed their own repositories and that's worked
swimmingly well.
Would you stick your sources in an unreliable mechanism? No. Then why
do you have your system setup to get your dependencies from one?
Should we lock it down further? Maybe. Should we be more strict giving
out rsync rights? Probably.
Maven is not inextricably bound to Ibiblio (which is not the central
repository anymore), or Maven central (hosted by Contegix). We have
been a little too free in giving access and it's actually OSS groups
that generally hose all the users. It's not us, or that Maven does it.
We cannot control, for example, if the people from the Tomcat and Axis
projects don't understand what they are doing: they have done releases
based against ephemeral repositories, put those repositories in their
POMs, and then removed the repositories. Or, groups like Groovy
release different artifacts with the same version wreaking havoc.
Maybe we should guard the system more, but we cannot control all its
users who contribute to central.
Yes, there are ways to mitigate that problem and
yes, Atlassian uses Archiva to have more control over resources, but I
believe Charles' point is it is still broken by design, despite the
bandaids you stick on it.
I beg to differ and might suggest your team leads research the tools
they use a little better. There's nothing in Maven stopping you from
using entirely your own repositories and nothing but. You manage them,
you know what's there. If you want to use a repository manager, then
you do builds with proxy repositories check the build and then you're
fine. The last option is the wild west which is not a good idea.
The central repository by design is add-only, it always has been.
People who rsync against us don't always adhere to that policy. If
you're allowing your enterprise to depend directly on Maven central
with no mitigating repository manager (or at least a proxy which has
been available for a long time) then don't blame. We don't control the
internet, but you can control your own local area network. With a
repository manager caching the results of a successful build you
should only encounter problems due to recent changes, not the rug
getting pulled out from under you.
Honestly, the number of times we have switch the underlying
infrastructure has been twice. The first time in the transition from
Ibiblio to Contegix and there were some hiccups. The second transition
to put in a hot failover no one even noticed.
I grant you that transitive dependency problem are hard to track down.
The rest of the blog is complete nonsense.
If I had written a blog entry for every time JIRA or Confluence bagged
out on me without having and gone to do research (I was an early
adopter and support of both) I would have a lot of them. Most of the
time it was misconfiguration, my server setup wrong or something else
I was doing wrong.
Don
-- yes, I work for Atlassian (of whom I don't speak for) but my
love/mostly hate affair with Maven extends back many years with
Struts...just ask Wendy :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
