[
https://issues.apache.org/jira/browse/METRON-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901927#comment-15901927
]
ASF GitHub Bot commented on METRON-726:
---------------------------------------
Github user mattf-horton commented on the issue:
https://github.com/apache/incubator-metron/pull/459
@justinleet , +100 that you've added site-book and javadocs to the
automated build.
Having site-book in the base build is fine, it only takes seconds to build,
and it will keep new README.md files clean. Javadoc takes a little longer, I
think, but is also important to keep clean. Is there something like
"-DskipSite" that prevents all three (site, site-book, and javadocs) from being
built, if a developer wants to skip them?
Regarding the integration, what most projects do is, as part of their
Site's documentation area, there is one or more pull-down menus, or a landing
page, where you can choose the VERSION you want of:
* Documentation (site-book, in our case)
* Release Notes
* Javadocs
This implies that the Site needs a *cumulative* store of past release Doc
builds, and that part of the Release Manager's job is adding each new release
to that store. Since it keeps getting larger and larger, storing it in github
master (where Site lives) may not be the best thing. Rather, it could go under
https://dist.apache.org/repos/dist/release/incubator/metron/ (release -> dev,
during votes). The cost of this is a manual step instead of automated, for the
Release Manager.
The Site menu would then link into the many doc sets in the store. Given
the regular naming of the paths, we could actually have each release contain
its own doc set (only) at a standard place, which is consistent with it being
part of the build, and then the Site's menu would have a list of links that
differ only by a version number. The RM would make the one-line edit to add
each new doc set as it is released.
What do you think?
> Clean up mvn site generation
> ----------------------------
>
> Key: METRON-726
> URL: https://issues.apache.org/jira/browse/METRON-726
> Project: Metron
> Issue Type: Bug
> Reporter: Justin Leet
> Assignee: Justin Leet
> Priority: Minor
>
> Right now there's a couple issues with running mvn:site. The most obvious is
> that EMMA appears to not work at all, but in attempting to fix that, several
> other issues came to light.
> Error seen:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> metron-maas-common: failed to get report for
> org.codehaus.mojo:emma-maven-plugin: Failed to execute goal
> org.codehaus.mojo:emma-maven-plugin:1.0-alpha-3:instrument (report:emma) on
> project metron-maas-common: Execution report:emma of goal
> org.codehaus.mojo:emma-maven-plugin:1.0-alpha-3:instrument failed:
> CONSTANT_info: invalid tag value [18] -> [Help 1]
> {code}
> After commenting out everything EMMA, there are still some issues seen:
> {code}
> [WARNING] Unable to process class
> org/apache/metron/test/converters/BinaryConverters.class in JarAnalyzer File
> /Users/jleet/.m2/repository/org/apache/metron/metron-test-utilities/0.3.1/metron-test-utilities-0.3.1.jar
> org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant
> pool: 18
> {code}
> This seems to be a Java 8 issue, which means that EMMA likely is impossible
> to make work. I'm unsure that's the root cause, but given the age of EMMA
> plus (the outdated version of) BCEL thowing a very similar issue implies that
> the Java version is related. This also implies that our {{mvn site}} hasn't
> worked in a long time.
> Cleaning this up should include at least
> * Getting code coverage working again
> * Consolidating reporting in our poms. A lot of it is repeated everywhere we
> have Java.
> * Ensure we can actually generate and look through the site.
> * METRON-725 fixes Javadoc, so reporting will still have issues until that is
> taken care of.
> * Apparently checkstyle got dropped at some point. It's easy enough to add
> in, and can be taken care of here.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
