> > * The relational viewpoint concerns information about artefacts such as
> > dependencies - and here we start see language specifics. For example
> > a jar
> > file with structural dependencies. This leads to the necessity to
> include
> > a artefact descriptors. One example is the Mave
> My impression is that this is specific to the Maven POM model - which is
> for all intensive purposes meta-data for the purpose of artifact
> generation. When you are looking at runtime service deployment model
> there are bunch of things that the POM does not address (which is to be
> expected
Jason,
> There is absolutely nothing stopping you, with the structure of the
> current Maven repository, from keeping a directory of available
> components for use with, say, Merlin or Plexus. I believe the discussion
> of dynamic component deployment is beyond the scope of the discussion
> here.
> With repositories growing fast, it needs to be searched and there should
> be
> a keyword search that assists faster search ( speaking from the
> established
> UDDI Repository and Database point of view ).
Yes exactly. Coming from the directory side I see a massive synergy. By
enabling attribu
Thank you somebody for seeing these needs as well. I would like
to second Nick's response yet again.
> -Original Message-
> From: Nick Chalko [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 07, 2003 5:18 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Proposals
>
> Anou Manavalan wrote:
>
Noel,
So let me understand. You're saying that those interested in enabling a
repo with metadata and searches based on this metadata could wrap the
repository with a servlet. The URI could be used by the servlet to give a
different view of the repository based on parameters, search filters
embed
Hi,
> -Original Message-
> From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
> When we talk about distributed Maven repositories, ASF repositories etc
> that are related to "Java". I think we should consider that CPAN/CRAN
> etc are models of distributing such content that have been successf
> So really, who cares about CJAN. The spec that goes defacto is the one
> manifest in the mechanism used by the most people. Unless of course SUN
> steps in at some point and tries to propose a JSR which wouldn't
> surprise me at all.
It's such an undertaking that it might be good to have a JSR a