On Mon, 2003-03-03 at 10:38, Stanley,Michael P. wrote:
> >
> > 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.
> 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.
> 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?
> 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: [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]
