Comments on: Remote repositories and reproductability http://www.bearaway.org/wp/2006/07/16/remote-repositories-and-reproductability/ Just another rant Sat, 22 May 2010 15:41:26 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Konstantin http://www.bearaway.org/wp/2006/07/16/remote-repositories-and-reproductability/comment-page-1/#comment-2974 Konstantin Wed, 09 Aug 2006 19:45:55 +0000 http://www.bearaway.org/wp/?p=509#comment-2974 The piece of advice regarding public repositories is true. But it does not have to be this way, public repositories can be trusted and should be. Gentoo, Ubuntoo and many others do rely on public repositories heavily and successfully. CPAN is very well utilized by Perl folks, Ruby Gems by rubyites. In Java all the necessary ingredients are available; it is a matter of getting to agree on few very simple principles: - all the artifacts have to be signed with trusted certificates like it is outlined in http://www.apache.org/dev/release-signing.html If that was the case then it would not matter from where a particular jar has been downloaded; - no ranges: dependencies has to be specified explicitly. Dependency manager should allow users to override dependency declarations by supplying parameters or in a predefined configuration file; - dependency declarations should have separate versioning from versioning of artifacts (Ivy implements that actually). I mean that if artifact a-1.0 depends on b-2.1 then there should be dependency declaration a-dd-1.0 that will point to a-1.0 and b-2.1, then when b-2.2 gets released and it is compatible with a-1.0 then dependency declaration a-dd-1.1 needs to be released that will point to a-1.0 and b-2.2. The piece of advice regarding public repositories is true.
But it does not have to be this way, public repositories can be trusted and should be.
Gentoo, Ubuntoo and many others do rely on public repositories heavily and successfully.
CPAN is very well utilized by Perl folks, Ruby Gems by rubyites.

In Java all the necessary ingredients are available; it is a matter of getting to agree on few very simple principles:
- all the artifacts have to be signed with trusted certificates like it is outlined in http://www.apache.org/dev/release-signing.html If that was the case then it would not matter from where a particular jar has been downloaded;
- no ranges: dependencies has to be specified explicitly. Dependency manager should allow users to override dependency declarations by supplying parameters or in a predefined configuration file;
- dependency declarations should have separate versioning from versioning of artifacts (Ivy implements that actually). I mean that if artifact a-1.0 depends on b-2.1 then there should be dependency declaration a-dd-1.0 that will point to a-1.0 and b-2.1, then when b-2.2 gets released and it is compatible with a-1.0 then dependency declaration a-dd-1.1 needs to be released that will point to a-1.0 and b-2.2.

]]> By: Henri Yandell http://www.bearaway.org/wp/2006/07/16/remote-repositories-and-reproductability/comment-page-1/#comment-1893 Henri Yandell Tue, 18 Jul 2006 03:58:16 +0000 http://www.bearaway.org/wp/?p=509#comment-1893 Lesson being - store your maven repository under version control and don't use the public maven repositories. Instead build your own internal company one. I've not used Ant in anger since the ability to include (or something like that) was added, it used to be I chose Maven because Ant meant having lots and lots of duplicated build.xml's between unrelated projects. I've been using Ant more recently (building open source projects at work, we use the lowest common delimiter which is Ant) and it's starting to warm on me again. Lesson being – store your maven repository under version control and don’t use the public maven repositories. Instead build your own internal company one.

I’ve not used Ant in anger since the ability to include (or something like that) was added, it used to be I chose Maven because Ant meant having lots and lots of duplicated build.xml’s between unrelated projects. I’ve been using Ant more recently (building open source projects at work, we use the lowest common delimiter which is Ant) and it’s starting to warm on me again.

]]>