geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Warner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (GERONIMO-2757) Enhance plugin schema to allow for multiple versions of a plugin
Date Wed, 24 Jan 2007 03:29:49 GMT

    [ https://issues.apache.org/jira/browse/GERONIMO-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466893
] 

Jason Warner commented on GERONIMO-2757:
----------------------------------------

When originally tackling this issue, my hope was to maintain backwards
compatibilty such that any existing xml files would not need to be modified
to work with this schema.  I have since determined that this is most likely
not possible.  To accomplish the goals of this jira, the current geronimo
version element will need to be changed from this:

<geronimo-version>"version"</geronimo-version>

to this:


<geronimo-version version="version">
       ....
       // version specific info
       ...
</geronimo-version>

This would require changing the plugin catalogs to function with the new
geronimo-version element.  This should not be a problem as they were going
to ideally be consolidated into one catalog after this change was finished.
My question is whether this change would has a negative effect on anyone
else?  If so, can someone think of a different way to do this that would
retain backwards compatibility?

Thanks,

Jason




> Enhance plugin schema to allow for multiple versions of a plugin
> ----------------------------------------------------------------
>
>                 Key: GERONIMO-2757
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-2757
>             Project: Geronimo
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: Plugins
>    Affects Versions: 2.0
>            Reporter: Paul McMahan
>         Assigned To: Jason Warner
>
> plugins-1.1.xsd currently allows for a single version of a plugin to be described from
within a <plugin> element.   For example, if there were a different version of plugin
for each version of geronimo then the plugin catalog would like something like:
> <plugin>
>     <module-id>org.apache.geronimo.configs/ca-helper-tomcat/1.1/car</module-id>
>     <geronimo-version>1.1</geronimo-version>
>     <source-repository>http://geronimo.apache.org/plugins/geronimo-1.1</source-repository>
>     [...]
> </plugin>
> <plugin>
>     <module-id>org.apache.geronimo.configs/ca-helper-tomcat/1.2/car</module-id>
>     <geronimo-version>1.2</geronimo-version>
>     <source-repository>http://geronimo.apache.org/plugins/geronimo-1.2</source-repository>
>     [...]
> </plugin>
> <plugin>
>     <module-id>org.apache.geronimo.configs/ca-helper-tomcat/2.0/car</module-id>
>     <geronimo-version>2.0</geronimo-version>
>     <source-repository>http://geronimo.apache.org/plugins/geronimo-2.0</source-repository>
>     [...]
> </plugin>
> <default-repository>http://geronimo.apache.org/plugins/geronimo-1.1</default-repository>
> <default-repository>http://geronimo.apache.org/plugins/geronimo-1.2</default-repository>
> <default-repository>http://geronimo.apache.org/plugins/geronimo-2.0</default-repository>
> Plugins are usually not compatible across versions of Geronimo for various reasons, probably
the most prominent of which is Geronimo's reliance on serialized java objects in CAR files.
 Browsing a catalog that contains a <plugin> element for each version of Geronimo's
plugins from the  admin console or from the CLI  would be confusing because of the many (seemingly
redundant) entries.  Therefore the collection of Geronimo plugins is distributed across a
set of catalogs, one per version of Geronimo, and each version of Geronimo points at a version
specific plugin catalog.
> Modifying the plugin schema so that a <plugin> element can allow the plugin's module-id
and source-repository to depend on the <geronimo-version> would allow there to be much
fewer entries in a consolidated plugin catalog.  A plugin catalog that is created using this
modified schema might look something like (this is just a sample) :
> <plugin>
>     <geronimo-version version="1.1">
>         <module-id>org.apache.geronimo.configs/ca-helper-tomcat/1.1/car</module-id>
>         <source-repository>http://geronimo.apache.org/plugins/geronimo-1.1</source-repository>
>     </geronimo-version>
>     <geronimo-version version="1.2">
>         <module-id>org.apache.geronimo.configs/ca-helper-tomcat/1.2/car</module-id>
>         <source-repository>http://geronimo.apache.org/plugins/geronimo-1.2</source-repository>
>     </geronimo-version>
>     <geronimo-version version="2.0">
>         <module-id>org.apache.geronimo.configs/ca-helper-tomcat/2.0/car</module-id>
>         <source-repository>http://geronimo.apache.org/plugins/geronimo-2.0</source-repository>
>     </geronimo-version>
>     [...]
> </plugin>
> Also, for this to work a customized list of <prerequisite> elements would probably
have to be supported inside the <geronimo-version> element as well, since those might
also be version specific.
> Once this improvement is in place it will be easier to maintain Geronimo's plugin collection
since each version of Geronimo won't require a separate catalog.  Also it will be easier for
end users and other external sources to refer to Geronimo's plugin catalog since the repository
URL will no longer be version specific.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message