Christian outline the ideas below, I just want to add that imho, the point point is that mvn urls actually abstract the real location. Thus, you can change policies without having to modify the content of the repositories. One additional thing that Christian did not mention is the fact that all maven artifacts are cached to the disk. That's possible, because the real urls are abstracted. If we were to use plain http urls, even if the xml repository would contain resource with relative urls (which is not permitted by the spec), we'd loose lots of those benefits, and you'd still need a "repository" to hold both the xml repository and the bundles. In any case, you don't have to use maven to leverage the benefits of mvn urls, and you don't have to use mvn urls if you don't want...
Guillaume 2015-11-30 13:30 GMT+01:00 Christian Schneider <ch...@die-schneider.net>: > Honestly while working with karaf we always had a maven centric world so > we are bit biased I guess. > For me the core of maven is the maven repository. > > Before maven there were thousands of places to get jars from. As there was > no reliable place to get dependencies from most projects put their > dependencies into a zip/or tar.gz file that formed the distro. > > 1. Maven keeps your source repository free from binaries > So the first good thing in maven is that each jar has a (kind of) world > wide unique id. So instead of putting a dependency into your source control > system you only refer to it using this id. > > 2. Maven central the place where you can get almost any jar available as > open source > > 3. Companies can transparently mirror external repositories like maven > central. So your project still has the same maven id for the artifact but > you can route all through your company repository. There you can > do the mirroring, caching, security checks, license checks > > 4. In the karaf case the maven repository is a nice place to load > artifacts from. Again the maven id is the same and you can route through > your company repository. > > 5. Every code your teams produce goes to the company maven repository. So > the repository is the way your teams can hand over snapshots and releases. > > 6. Maven has a nice snapshot handling. So open source projects as well as > company teams can have their CI build push to a maven snapshot repo for any > other to retrieve the newest versions from. This significantly shortens > development cycles as you have the chance to find bugs before the release > is done. We use this extensively for the projects karaf integrates. > > So as you see it is not the build system. I would be interested how you do > all the things above without the maven repo. > > Christian > > > > > On 30.11.2015 13:17, David Leangen wrote: > >> Hi, >> >> I think the maven repository is also a really nice hand over point >>> between the developer and deployer roles you defined. The developer builds >>> the bundles as well as the >>> index into the maven repository and the deployer installs from there. >>> >> >> Perhaps you could explain to me why, other than for backwards >> compatibility and perhaps because of wide adoption, working with maven is >> such a good thing? For those reasons, I agree that maven is necessary to >> maintain; but to chain people to maven, I am not so sure. >> >> It seems to me that the OSGi model (OBR) is enough, and is the “OSGi >> Way”. Maven is a different world. Since I have been maven-free, it has been >> quite liberating. I see OSGi in a different (IMO nicer) way now. :-) >> >> Just my 2yen. >> >> Cheers, >> =David >> >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
