[
https://issues.apache.org/jira/browse/ACCUMULO-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13880527#comment-13880527
]
Christopher Tubbs commented on ACCUMULO-2229:
---------------------------------------------
I think it's useful to put them with the service they manage, but I think it's
overkill to create additional artifacts, and very much not necessary. They
should probably be put in src/scripts/init.d or src/scripts/systemd or
whatever, per module, to keep them with the service they manage. We can include
it in the RPM/DEB packages right there... no need to add dependencies from
siblings.
These init scripts are possibly also tightly coupled with the package (RPM for
RHEL6/CentOS6, RPM for Fedora/RHEL7/CentOS7, Ubuntu) in which they are
included, and it would get quite crazy if we created separate artifacts for
each variant. A generic SysVinit script is available today... but that may not
be the case in the future, as we may want to package upstart and systemd
scripts, and I'd hate to start a precedent of making each of these separate
artifacts... especially since they are likely to be 1-to-1 with the RPM/DEBs we
build.
I don't see a problem continuing to access the (currently very generic)
SysVinit scripts from the sibling module for the generic binary tarball. If we
end up making systemd-based RPMs in the future (RHEL7/CentOS7, for instance),
we might want to change the per-module scripts to systemd, but keep SysVinit
scripts in the assembly module itself for generic systems.
In short, what I'm saying is... keep the scripts local to the RPM/DEB
packaging, and reference them from the sibling module as long as they are
generic enough to work in the generic binary tarball... and if they aren't
generic enough for the tarball, put them in the assembly module.
> 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: Bug
> 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)
