On Wed, Apr 2, 2008 at 5:30 PM, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> 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). I think I would try to follow maven 2 conventions, just for the ease of use for people coming from maven2, and because I think they are pretty good when followed. Obviously apache commons-* would be renamed since they don't follow the convention. For java projects, I think using the main package name of the main module in the project makes sense most of the time. *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! This sounds like a good approach. I was afraid you were just asking for the project to be done by itself. > > > 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. As I said earlier, if a community raise and develop this, it's more than welcome, and I'll be glad to participate if I find some spare time. > > > *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. This is a very nice way to handle metadata evolution, I already proposed this kind of metadata backward compatibility for public repository during discussions which happened at the beginning of Ivy's incubation. Better support for deprecated configurations (which are supported since very early versions of Ivy, but not used) would help in this area too. If we want to ensure real backward compatibility, it would be nice to have a tool to validate that the new metadata is actually backward compatible with the old one. > > *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. And they could build their metadata from what is provided online, so I clearly see as a very interesting design. > > > *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="..."/>). I really like this idea of leveraging maven repo when it makes sense, and doing more work only when necessary. > > > 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. Sounds nice. > *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. There's something very important missing in your list (but probably not in your head :-)) is the source of communication for the community. A mailing list is nice, especially if you have a good web front end for it (like with google groups). This list would allow people to discuss how they think a module should be added, what's the best name for a project's organization, and so on. To add or update data in the repository, I think there should be a tool, not just a svn ci of whatever you've down. The tool (or server) would be responsible for validating that what you do is correct: valid xml, valid metadata, all dependencies are available, BC on metadata update, ... I think this is the only way to get a community maintained repository clean, and as such is *very* important to have from the beginning. > > 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. That sounds nice and simple enough. Xavier > > > Thanks, > -Archie > > P.S. I apologize for the duplicate original email (got tricked by gmail > email aliasing problem) > > -- > Archie L. Cobbs > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
