> 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 artifact. 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. -Tim