Thanks for all the comments so far regarding this idea. The first step was to get a discussion going and so far that's worked :-)
Some more thoughts... please let me know what you think makes sense and what doesn't... *Organizations.* Regarding choice of "organization" for each module: why not use the name of the project as the organization for all of the ivy modules? That is what we do internally in our "enterprise repository". This seems obvious to me, but maybe I'm misunderstanding what "organization" is supposed to be for. I've always thought of it as referring to the people that created the *module* (not the *artifacts*). If you don't do it that way, you eliminate the possibility of multiple packagers of the same stuff, which would be bad (e.g., think about how many different Linux distributions there are). *Volunteers. *Regarding finding volunteers: there is no problem here. Either there will be enough interest and volunteers and the project will succeed, or there won't and it will die. This is the way open source is supposed to work! Also: regarding the question of whether Ivy developers should be spending their time on this idea. Answer: what a flattering idea :-) This project would however be separate from Ivy. Ivy developers would of course be welcome and encouraged but there would hopefully be plenty of other "random" people involved (like me). The best would be if a developer of each java project was maintaining their own project's meta-data. *Configurations. *Regarding defining configurations: I think the general approach with each module should be to start simple, then refine over time, and plan an "additive" evolution. That is to say, it's much less disruptive for a module to add a new configuration than it is to change or remove an existing one. So the general evolution should be that new, more precise configurations are added over time as necessary/desired. Example: you have "production" and "test" and want to refine along the JDK14 vs JDK15 dimension. Then you leave "production" and "test" alone but add "production-jdk14", "test-jdk14", "production-jdk15", and "test-jdk15". This way things stay backward compatible. *Public vs. Internal.* While it's true that an internal private repository is always going to be safer and more secure than a public one, I think we can be smart here, and it doesn't have to be "all or none", i.e., you can choose where along the spectrum you want to live. First, the meta-data instructions that knows how to retrieve the archive from wherever would be required to confirm integrity via checksums. This eliminates one source of potential "poisoning". Secondly, this project would really be composed of two separate things: 1. Meta-data/instructions describing how to retrieve and/or build each module's ivy.xml file and artifacts (with integrity checksums for all external resources) 2. A new ivy resolver that knows how to use the meta-data in #1 to resolve ivy modules So for example there's no reason a paranoid enterprise couldn't use the resolver in #2 but replace #1 with their own meta-data, etc. *Name. *We'd need a name for this project. I suggest "Ivy Roundup". *SVN Repository.* The project would have its own SVN repository. This would contain meta-data (in whatever form) describing how, for each module, to retrieve and/or build the ivy.xml and artifacts in that module. This meta-data could be as simple as an ant build.xml, or perhaps an XML file in a simple domain-specific language (<extract url="http://.../foobar.zip"; file="dist/foobar.jar"/>) or whatever. If a source project includes its own ivy.xml file, it can be used directly (possibly with changes applied via XSLT). Otherwise the likely common case would be that the ivy.xml is just included directly in the meta-data. We would optimize for projects published via maven, where we can derive some or all of our meta-data from the maven meta-data (<maven-project url="..."/>). The SVN repository would also contain Java code that defines an ivy resolver that knows how to utilize the above meta-data to resolve Ivy modules (someday if there is great success this could be merged into ivy itself). This resolver would be configurable so that it could work with propely formed meta-data from any source, not just this project's version of it. *Website. *The project web site must provide an easy way to visually inspect the (styled HTML) meta-data for each module using a web browser (perhaps using direct SVN HTTP access). Also it should have a simple search capability. Now what is the end result of this project, i.e., the product produced by this project? What exactly do you download and how do you use it? One possibility is that the output of this project would be an ivy module, containing the meta-data and resolver. The project would also have its own public Ivy repository, but containing only one module: itself. To make use of this, users would then: 1. Add the project's ivy repository to their settings 2. Use ivy to download the project module normally 3. Update their ivy settings to use the project's resolver, configured to point at the project's website Of course steps #1 and #2 could be done manually as well. Thanks, -Archie P.S. I apologize for the duplicate original email (got tricked by gmail email aliasing problem) -- Archie L. Cobbs
