You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flume.apache.org by "Hari Shreedharan (JIRA)" <ji...@apache.org> on 2014/05/23 18:18:04 UTC

[jira] [Updated] (FLUME-2199) Flume builds with new version require mvn install before site can be generated

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

Hari Shreedharan updated FLUME-2199:
------------------------------------

    Fix Version/s:     (was: v1.5.0)
                   v1.6.0

> Flume builds with new version require mvn install before site can be generated
> ------------------------------------------------------------------------------
>
>                 Key: FLUME-2199
>                 URL: https://issues.apache.org/jira/browse/FLUME-2199
>             Project: Flume
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: v1.4.0
>            Reporter: Andrew Bayer
>            Assignee: Andrew Bayer
>             Fix For: v1.6.0
>
>         Attachments: FLUME-2199.patch
>
>
> At this point, if you change the version for Flume, you need to run a mvn install before you can run with -Psite (or, for that matter, javadoc:javadoc) enabled. This is because the top-level POM in flume.git/pom.xml is both the parent POM and the root of the reactor - since it's the parent, it's got to run before any of the children that inherit from it, but site generation should be running *after* all the children, so that it probably pulls in the reactor's build of each child module, rather than having to pull in one already installed/deployed before the build starts.
> There are a bunch of other reasons to split parent POM and top-level POM, but that's the biggest one right there. 
> Also, the javadoc jar generation is a bit messed up - every module's javadoc jar contains not only its own javadocs but the javadocs for every Flume module it depends on. That, again, may make sense in a site context for the top-level, but not for the individual modules. This results in unnecessary bloat in the javadoc jars, and unnecessary time spent downloading the "*-javadoc-resources.jar" for every dependency each module has, due to how the javadoc plugin works. Also the whole site generation per-module thing, which I am not a fan of in most cases. I don't think it's needed here. Tweaking the site plugin not to run anywhere but the top-level and the javadoc plugin to not do the dependency aggregation anywhere but the top-level should make a big difference on build speed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)