> > > > > > The group id is used widely and is the preferred approach in fact. > > > > Then I must have missed something. I presumed that the groupId, in > > general, would be more closely related to the domain name like java > > packages. > > There's no hard and fast rule. Domain names would definitely provide a > level of uniqueness. It's arbitrary and undefined insofar as what's > best. Alexei suggested FQDNs and that's probably the wisest so you could > have things like: > > org.apache > org.apache.ant > org.apache.avalon > org.apache.avalon.excalibur > org.apache.avalon.excalibur.fortress > > You get the idea. But that sort of nesting isn't supported yet but it's > on my internal list as necessary for real-life usage.
+1 - Exactly what I'm getting at. > > I.E. Jakarta Commons would *all* be apart of the groupId > > org.apache.commons. A superior solution would be a Unique ID created > > using project name and domain name -> > > [EMAIL PROTECTED] > > Right. Any sort of arbitrary nesting will be supported. Great. > > This is related to the DNS SRV, and the more I think about it, I am > > proposing a messaging based repository. > > > > Unique IDs can be <groupID>.<projectID>@<repository domain> > > > > Implementation of the DNS SRV, provides infrastructure for a distributed > > repository with dynamic lookups. Default servers like the one hosted at > > Ibiblio are still very useful and provide a fallback (or default host, > > where the dynamic search is the fallback). > > > > More information on the DNS SRV protocol can be found here > > http://www.ietf.org/rfc/rfc2782.txt > > Cool, I'll take a look. > > > This setup can provide immediate availability of dependencies. For > > example, say I create a reusable component 'coolWidget'. Currently I > > would need to request that the coolWidget be added to the central > > repository. > > Well, for long. It will get better quickly. Very quickly. > > > However, if I had a maven repository service set up on my > > own domain 'org.mikestanley', a Maven project can now add the dependency > > -> org.mikestanley.coolWidget@ mikestanley.org > > > > My coolWidget is immediately available to Maven projects. In addition, > > once the best fit repository is located, communication can be set up > > between client and host to negotiate available versions, permissions, > > etc. > > Cool, I'm not familiar with DNS SRV but sounds like something worth > investigating. We would need a java implementation :-) Is there one? Not sure. I'll look into it. Thanks for hearing me out :-) - Mike > > The DNS SRV provides dynamic resolution to the service > > _maven_tcp.mikestanley.org. This can be a single server, cluster, > > whatever. This allows repository administrators to "use several servers > > for a single domain, to move services from host to host with little > > fuss, and to designate some hosts as primary servers for a service and > > others as backups." > > > > > > I think this is also crucial and should be > > > > enforced. As the repository grows, namespaces become extremely > > > > important. Unique Project ID's just isn't good enough. Also, even > > now > > > > the repository is very large. Breaking things into sub directories > > > > would clean it up a bit and allow for better scalability. > > > > > > Arbitrarily nested groups are coming as a means to allow projects to > > > organize as they please. This will take a bit of work. > > > > Can you elaborate? I assume you mean the subdirectories of a group will > > be able to have additional groups other than jar & distributions. This > > doesn't help the conflicts at the top level. Are 100% confident that > > Jakarta is the only developer community to have a project named > > "commons-email"? And are you confident that as Maven becomes widely > > adopted there will be no conflicts? Most of the projects I've built > > with Maven don't even mention groupID in their dependency list. > > > > > > > > > In the future - how about a repository search algorithm based on the > > > > convention that group id can equal the domain name. It would then > > be > > > > possible to implement a repository service lookup utilizing the DNS > > > > service protocol. Similar to how Jabber handles s2s communication. > > > > > > > > Thoughts? > > > > > > I'm not really sure what that buys us. Can you explain in more detail? > > > > See above. > > > > - Mike > > > > > > > > > > - Mike > > > > > > > > > -----Original Message----- > > > > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > > > > Sent: Monday, March 03, 2003 2:07 AM > > > > > To: Turbine Maven Developers List > > > > > Subject: Update > > > > > > > > > > Hi, > > > > > > > > > > I'm at the point now where I'm debugging the isolated classloaders > > per > > > > > plugin. I have completely faked out the AntClassLoader with a > > > > > replacement that simply delegates to ClassWorlds. Many goals can > > run > > > > and > > > > > each plugin has a classloader so I'm just sorting out attaching > > the > > > > > right classloader to the right context. Made lots of progress this > > > > > weekend but it will take me a couple more days to finish the > > > > ClassWorlds > > > > > conversion. > > > > > > > > > > jvz. > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: turbine-maven-dev- > > > [EMAIL PROTECTED] > > > -- > > > jvz. > > > > > > Jason van Zyl > > > [EMAIL PROTECTED] > > > http://tambora.zenplex.org > > > > > > In short, man creates for himself a new religion of a rational > > > and technical order to justify his work and to be justified in it. > > > > > > -- Jacques Ellul, The Technological Society > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: turbine-maven-dev- > [EMAIL PROTECTED] > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://tambora.zenplex.org > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
