> From: Nick Chalko [mailto:[EMAIL PROTECTED]
> Tim Anderson wrote:
> >Can you clarify the licensing issues further? I'm having trouble
> >seeing what the problems are.
> >
> >Suppose ASF has the following link in the repository:
> >  http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar
> >
> >This is a virtual artifact, not hosted at ASF.
> >
> >  
> >
> I think what you describe was fine. 
> I was looking the otherway. 
> The ability to host a jar and ensure that a user "accepts" a license 
> first. 
> So what would we need  for a virutal artifact.
> A "entry-url"  and the rest is up to the user/tool?

There are a few approaches. The following assumptions
are made:
. virtual artifacts which require processing redirect
  to a descriptor hosted within the repository which
  describes how to get the real artifact.
. the descriptor refers either to the real artifact,
  or an artifact (call it target) containing the real

Possible approaches:

1. descriptor includes URL of target artifact.
   The limitation of this approach is that the tool
   has to be aware of the licensing and distribution of
   the target artifact.

2. descriptor includes code to get the target artifact
   For java, this could be a scripting mechanism based on BSF, 
   ant or jelly.
   This may not be portable between tools:
   . tool requires a dependency on the scripting mechanism
   . tool may not be able to specify where the artifact
     is downloaded to

3. descriptor refers to code which can get the artifact
   For java, this would include the main class and URL classpath
   of the code to get the artifact. This code could be hosted
   in the repository.   
   For portability between tools, an API would need to be specified
   to give tools control over how the target artifact is processed 
   subsequent to its download.


Reply via email to