Brett Porter wrote:

On 5/5/05, Dion Gillard <[EMAIL PROTECTED]> wrote:


Where do you see the Eclipse version number (not the artifact version)
fitting in?



I was under the impression this would be captured within the archive itself.

But should it need to be part of the path, it is probably sensible to
make it part of the artifactId/versioning of the file:

mylib-1.0-eclipse.jar
mylib-1.0-eclipse2.jar

Very rough, obviously. I wasn't really thinking of the specifics at
this point, however I think it is reasonable to assume that we can or
should map it to the repository in some way to leverage that. If it
needs to be able to do more, then we can look at that too.



I believe this naming scheme is critical for Eclipse, so attempting to redefine like you have above it is a problem. We might even find that the "plugins" directory is unchangeable. So, I'm suggesting that to publish a site in the repository, its going to have to look like this: When Eclipse packages the archive, its not the "Eclipse" version thats Identified, but the plugin version. so for instance, an Eclipse update site for Axis would contain the following:

.../plugins/org.apache.axis_1.0.0.jar
.../plugins/org.apache.axis_2.0.0.jar
.../site.xml

The site.xml contains references to the above files. When the jar is installed using the updater it gets expanded under the path in Eclipse:

eclipse/plugins/org.apache.axis_2.0.0/...



/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_1.0.0.jar
/java-repository/axis/eclipse-distributions/plugins/site.xml

I'm going to also suggest that The updater will be responsible for determining dependencies, this means that the closest packaging gets to a dependency on a specif c "release" of Eclipse is really about the plugin having different dependencies on the core eclipse runtime. This means that say we had several versions of axis out where the differences the dependencies are on a specific runtime plugin.

/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_1.0.0.jar >= org.eclipse.runtime_2.1
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_1.0.1.jar >= org.eclipse.runtime_2.1
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_1.0.2.jar >= org.eclipse.runtime_2.1


/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_2.0.0.jar >= org.eclipse.runtime_3.0
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_2.0.1.jar >= org.eclipse.runtime_3.0
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_2.0.2.jar >= org.eclipse.runtime_3.0


/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_3.0.0.jar >= org.eclipse.runtime_3.1
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_3.0.1.jar >= org.eclipse.runtime_3.1
/java-repository/axis/eclipse-distributions/plugins/org.apache.axis_3.0.2.jar >= org.eclipse.runtime_3.1


The dependencies would be determined by the Eclipse update manager via the site.xml, not by the structure of the repository. By reading the plugins dependencies, Eclipse determines which is the best fit for the install.

-Mark

And what of eclipse features which are a bundling of related plugins
and resources?



Again, I thought they were all described in the same way and its internal structure decided that.

Cheers,
Brett






Reply via email to