Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <808558862.1233770520907.JavaMail.jira@brutus>
Date: Wed, 4 Feb 2009 10:02:00 -0800 (PST)
From: "Jarek Gawor (JIRA)" <jira@apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Updated: (GERONIMO-2288) Abstract/Maven repositories install
 modules incorrectly
In-Reply-To: <25707249.1154962633998.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/GERONIMO-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jarek Gawor updated GERONIMO-2288:
----------------------------------

    Fix Version/s:     (was: 2.0.4)
                   2.0.3

> Abstract/Maven repositories install modules incorrectly
> -------------------------------------------------------
>
>                 Key: GERONIMO-2288
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-2288
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: kernel, Plugins
>    Affects Versions: 1.1, 1.1.1, 1.2, 2.0-M6
>            Reporter: Aaron Mulder
>            Assignee: Aaron Mulder
>             Fix For: 2.0.3
>
>
> The repository unpacks a JAR when it installs it only if the Artifact type is "car".  That is incorrect -- it should unpack any module with META-INF/config.ser (which is the logic that we use in other places, such as RepositoryConfigurationStore).  This breaks plugins that don't have the type "car" (such as copying a database pool from server to server).
> The currently handling attempts to be generic by associating a behavior with each file type, though in practice this is only used for type=car.  In the 1.1 branch, I am going to put in a workaround to look up the "car" handler any time we find a META-INF/config.ser (a pretty minimal workaround).
> In trunk, I think we should remove the behavior/type association and instead have a boolean for whether configurations should be unpacked, or an "ArtifactTypeHandler" property specifically for configurations and another one for non-configurations.  I don't see any reason to distinguish based on module type.  Input would be appreciated for the 1.2 resolution.

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