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
