www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@apache.org>
Subject Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
Date Wed, 04 May 2005 16:09:28 GMT
Brett Porter wrote:

>On 5/5/05, Dion Gillard <dion.gillard@gmail.com> 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
>
>  
>


Mime
View raw message