[jira] [Commented] (ACCUMULO-25) Documentation instructs maven assembly:assembly, which has undesired behavior

["Eric Newton (Commented) (JIRA)" <ji...@apache.org>]

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

Eric Newton commented on ACCUMULO-25:
-------------------------------------

Posting some offline discussion that I think is a good idea, even if it wasn't mine:

[A colleague writes]

'mvn clean assembly:assembly' fails for me on Maven 2.2.1, but 'mvn
clean package assembly:assembly' succeeds. The 'assembly:assembly'
goal does something funky in the context of a multi-module build which
forces it to defer execution of the assembly goal until all other
goals are run for all modules.

That may be moot because as John points out assembly:assembly is deprecated.

I experimented 'mvn clean assembly:single'. There's a problem that
crops up with the when building from a clean sandbox. accumulo's
parent module gets built first along with its assembly. This means we
wind up with a tarfile that doesn't contain any of the jars (among
other things) because the rest of the modules haven't had the package
goal run on them yet.

'mvn clean package assembly:single' won't work for the same reason.
Each of the goals will be executed by each module in build order, e.g:
'clean assembly:single' on parent, 'clean assembly:single' on
cloudtrace, etc. We really need one pass where each module's 'package'
goal is executed followed by another pass where only the parent's
assembly:single goal is executed.

'mvn clean package && maven assembly:single' seems to work --
everything is put in place by the package, so the assembly:single
picks it up when maven is invoked a second time. This isn't exactly
the preferred maven way of doing things, but it works.

A different approach to this is described in
http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
-- In this approach where the final assembly is performed in a module
separate from the parent that depends upon all of the other project's
modules. This forces it to execute last. This would require some
significant changes to the existing poms. Essentially, after a change
like this, the parent simply defines the behaviour common to all
module (e.g in pluginManagement), but doesn't really do anything but
orchestrate the build. Most of the meat of the parent pom gets pushed
down to the distribution module. We wind up with a build order like:

accumulo
cloudtrace
accumulo-start
accumulo-core
accumulo-server
accumulo-examples
accumulo-distribution

I believe it may also solve problems related to getting the reports to
run correctly / the site to be generated properly within jenkins. The
one thing I need to be sensitive to here is the ability to run
accumulo from a developer's sandbox, without having to do a full
install

Also, FWIW, Separately, I spent some time working on getting the
reports generated under the site goal under 3.0, but no luck there
yet.

[end comments by colleague]

                
> Documentation instructs maven assembly:assembly, which has undesired behavior
> -----------------------------------------------------------------------------
>
>                 Key: ACCUMULO-25
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-25
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: docs
>    Affects Versions: 1.4.0, 1.3.5
>            Reporter: John Vines
>            Assignee: John Vines
>              Labels: documentation, maven
>             Fix For: 1.4.0, 1.3.5
>
>
> The current documentation instructs users to do a mvn assembly:assembly for building the project. assembly:assembly is deprecated in maven and ends up requiring other accumulo pieces to be installed in the local maven repo for it to work, or for mvn package to be run first. We either need to fix the pom file for assembly:assembly to work properly or, preferably, update the documentation to the prefered maven action, posibly mvn assembly:single

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira