Let me suggest another idea: Can ibiblio staff be asked to support ivy as well for existing projects? The result would be an ivy.xml file and pom file together side by side.
This can solve the problem of not quality enough pom files from ivy's point of view. Maven and Ivy metadata files would simply sit side by side and everyone would be able to use ibiblio repositories. There is still namespace issue (e.g. commons-collections/commons-collections vs. apache/common-collections) but maybe some symbolic links could solve the problem (again, ibiblio staff may help). On 3/20/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
On 3/19/07, Scott Goldstein <[EMAIL PROTECTED]> wrote: > > Xavier, > > Your logic does make sense to me and I realize that this is not an easy > decision, as you pointed out in a later e-mail. > > My solution currently is to use IvyRep as the first repository and > Ibiblio as the second in a repository chain. This allows me to get > ivy.xml files whenever they're available. Though, I wasn't aware of the > IvyRep Sandbox, so that may be another repository that i would throw in the > chain. > > I realize that this is a complicated setup, but maybe something like > this makes sense as the default? I don't think so, because the sandbox is really just a sandbox, and I don't recommend using it directly. Well, I do not recommend using ibiblio repo in an enterprise build system either, but I think we need to go toward a better unification of metadata with maven2. I think we need to face it, creating metadata for all Java libraries is a huge task, so why not reuse the work done by maven aficionados, and only write metadata with Ivy files when maven poms are not flexible enough. But this is only my point of view of the moment, any input from the community is welcome. My thought here is that if you have the Ivy defaults set to use Ibiblio > exclusively, you run the risk of the Ivy community not having enough reason > to grow IvyRep or change Ibiblio to contain ivy.xml files. This would > make Ibiblio and pom the long term solution, which doesn't seem appropriate. If there is no reason to write an ivy file, why write it? I prefer reusing existing metadata when it's good enough, and write only those which are necessary. But once again, this will only change the default way of using Ivy, and I think improve out of the box user experience thanks to the huge set of existing metadata in maven 2 repo. Regarding your notion of distributed repositories, I can see that > working. The only concern is that every time you add a dependency, you most > likely have to add another include in your ivyconf. This is a little more > work than just having one central repository. Though, the idea of every > project owning their own repository sounds much more robust and "cleaner" > than one central repository containing every module in existence. The idea would be to provide an online ivy settings file pointing to the distributed ivysettings, so that you don't even have to modify your settings, you just include the online one if you want. - Xavier Scott > >
