Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of
 SRS0=lt5NwM=FW=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.85 as permitted sender)
Message-ID: <4AC4FDF8.1040009@wonderly.org>
Date: Thu, 01 Oct 2009 14:07:36 -0500
From: Gregg Wonderly <gregg@wonderly.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release
References: <1014271612.1254145216266.JavaMail.jira@brutus>
	 <4AC2FF2F.5060409@zeus.net.au>
	 <64efa1ba0909292351i7200f661k211143a9571c8765@mail.gmail.com>
	 <4AC30557.7060906@zeus.net.au> <1254347537.4813.48.camel@localhost>
 <4AC3DD3A.7070600@wonderly.org>
 <B2CDFF18-1DE1-4C3B-BCFF-AB412B628686@gmail.com>
In-Reply-To: <B2CDFF18-1DE1-4C3B-BCFF-AB412B628686@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregg Wonderly <gregg@wonderly.org>

Dennis Reedy wrote:
> Hi Gregg,
> 
> To a certain extent I think having an archive would make sense, but as 
> it relates to Maven created service artifacts I am not so sure.

I am not trying to focus this issue on solving anything related to maven. 
Instead, I am trying to discover what people think about creating an archive 
structure that could then be used for service deployment into various 
environments.  Clearly, we could provide an archive assembler that used maven 
for managing the content of what was placed in the archive.

The generation of the archive is one issue.  But, on the other end is the 
consumption, and that's where I'd like to initially focus the discussion.  I 
think that if we feel like it is something that the containers and deployment 
environments could use, and benefit from, than we can talk about providing such 
archives as a maven component from the river build.

I'd like to discuss deployment issues regarding packaging, managing various 
pieces of a service deployment in particular environments, and solutions people 
have put together to see if there really is a place for such a thing, or if I'm 
just barking up the wrong tree.

Gregg Wonderly