Return-Path: 
 <notifications-return-15575-apmail-accumulo-notifications-archive=accumulo.apache.org@accumulo.apache.org>
X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org
Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 403A2103DF
	for <apmail-accumulo-notifications-archive@minotaur.apache.org>;
 Fri, 24 Jan 2014 00:21:42 +0000 (UTC)
Received: (qmail 74897 invoked by uid 500); 24 Jan 2014 00:21:39 -0000
Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org
Received: (qmail 74735 invoked by uid 500); 24 Jan 2014 00:21:38 -0000
Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:notifications-help@accumulo.apache.org>
List-Unsubscribe: <mailto:notifications-unsubscribe@accumulo.apache.org>
List-Post: <mailto:notifications@accumulo.apache.org>
List-Id: <notifications.accumulo.apache.org>
Reply-To: jira@apache.org
Delivered-To: mailing list notifications@accumulo.apache.org
Received: (qmail 74709 invoked by uid 99); 24 Jan 2014 00:21:38 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Jan 2014 00:21:38 +0000
Date: Fri, 24 Jan 2014 00:21:38 +0000 (UTC)
From: "Michael Berman (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12689940.1390274602513.4117.1390522898374@arcas>
In-Reply-To: <JIRA.12689940.1390274602513@arcas>
References: <JIRA.12689940.1390274602513@arcas>
Subject: [jira] [Commented] (ACCUMULO-2229) Make init.d scripts get into the
 assembly in a more maveny way
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/ACCUMULO-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13880540#comment-13880540 ] 

Michael Berman commented on ACCUMULO-2229:
------------------------------------------

I don't understand your suggestion.  You're saying, keep them in the modules for their components, but they can be included in the output package right there?  We don't produce separate packaged artifacts for each component, do we?

The particular thing I'm suggesting is unmaveny is stuff like this in assemble/src/main/assemblies/component.xml: {{<directory>../server/tserver/src/main/packaging/etc/init.d</directory>}}.  How are you proposing we resolve that?  

Or are you just saying that you think the cost of attaching it as an artifact outweighs the risk of having inter-sibling, filesystem path-based implied dependencies?

> Make init.d scripts get into the assembly in a more maveny way
> --------------------------------------------------------------
>
>                 Key: ACCUMULO-2229
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2229
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: build
>    Affects Versions: 1.6.0
>            Reporter: Michael Berman
>            Priority: Minor
>
> (forked from ACCUMULO-1983)
> For 1.6 the init.d scripts were moved into the module for the corresponding service rather than all being piled into the assemble module.  To get them into the assembly, the scripts are just copied by path out of assemble's siblings.  This is simple and it's easy to see what's going on when looking at the pom, but it definitely violates maven best practices (don't reference "..").  I think if we want to keep the init.d scripts with their corresponding modules, the maveny way to do it would be to declare the init.d script as an artifact of each module (of type "init.d" or something), and then declare them as dependencies of the packager, which could then use the copy-dependencies goal to get them into the assembly. It's more lines of pom and possibly more opaque as far as figuring out where each file is coming from, but it would be more portable and less sensitive to module rearrangements in the future.
> Is this a good idea?  Is it pom overkill?



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)