On Wed, Apr 16, 2008 at 9:48 PM, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 16, 2008 at 1:45 AM, Xavier Hanin <[EMAIL PROTECTED]> > wrote: > > > On Wed, Apr 16, 2008 at 8:37 AM, Gilles Scokart <[EMAIL PROTECTED]> > > wrote: > > > Maven has naming conventions [1], [2]. > > > > > > The problem is that those conventions apeared with maven 2. maven 1 > > > didn't had this and the maven repository actully contains an export of > > > the maven 1 repository. That's why the naming convention didn't > > > seemed to be always followed. > > > > > > Note however, that they give advices to fix that [3]. > > > > The problem is that the repository is cluttered with old naming > > conventions, > > which make it sometimes difficult for users to find their way out: > > http://javarepo.xoocode.org/search?q=%23hibernate%3B > > http://javarepo.xoocode.org/search?q=%23commons-email%3B > > http://javarepo.xoocode.org/search?q=%23commons-transaction%3B > > http://javarepo.xoocode.org/search?q=%23commons-collections%3B > > > > > By the way, I've been thinking about this problem as well. > > Since Ivy RoundUp builds its repository using ant, it would be easy to add > "meta-data meta-data" that would handle things like backward-compatible > aliases for organisation names. > > E.g., if a Hibernate is officially known under org="org.hibernate" but > unofficially with org="hibernate" and org="net.sf.hibernate", then we > could > add a file in src/modules/org.hibernate/aliases.xml: > > <aliases> > <alias org="hibernate"/> > <alias org="net.sf.hibernate"/> > </aliases> > > Then the build would automatically create copies of the module under both > locations in the repo. IMHO, it's what should be avoided. For me the perfect repository has no duplication, each module can be found in only one place, and metadata is perfect :-) Obviously sometime you will have modules changing of organization in their lifetime, but it should reflect a real change, not a change in the way you write the metadata. That's why I think using the package name convention for the organization makes a lot of sense. We can even actually follow the package used in the library, so that there is no ambiguity. we could even add a tool checking that you can't add a module in an organization which doesn't actually reflect the package name used in the jar (for modules providing a jar only). Then the only remaining question is where to stop in the org name (I mean, at which dot in the package name), and which name to use with the module itself. BTW, I was also thinking about the repository quality and I think a good way to achieve a good quality is to check what you put in the repository. Automatic checks can perform some validation (like org name as I said earlier, metadata consistency, all dependencies available, ...), and community check others. To perform these checks, a staging area in the repo may be interesting: contributors commit new modules metadata in the staging area only, then these metadata are copied to the official repo when some checks have been performed. With a large enough community, you could have a vote system, as soon as the module gets 3 positive votes from a recognized set of people it goes to official repo. Xavier > > Actually, an even simpler way would be with a symlink checked into SVN... > > You could do similar things with the module name as well of course. > > In any case, the larger point is that the RoundUp project could provide > ways > to help these kinds of issues. > > -Archie > > -- > Archie L. Cobbs > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
