hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6145) Fix site target post modularization
Date Sat, 02 Jun 2012 23:28:23 GMT

    [ https://issues.apache.org/jira/browse/HBASE-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288037#comment-13288037

stack commented on HBASE-6145:

On avro, its deprecated.  I moved it out of top-level into module where its used as a). encouraging
its deprecation, and b). to get rid of some of the noise avro was generating each time mvn
dipped into a module.

How did you get that Unknown macro message?  I don't see it when I run local?  W/ the -X flag?
 I see a version when avro does its stuff.

I moved avro back up to top-level, at least the pluginManagement section for now.

I did pretty print on all the poms to fix indent issues: xmllint --format.

On hbase-common/pom.xml and surefire '...can/should stay in the pluginManagement section',
I don't think our modules should have a pluginManagement section.  It makes sense in top level
or in a module IF this module had submodules but otherwise a pluginManagement doesn't make
sense (as I understand it).  I tried removing them from modules.

On site goal and the following '...but is any actual work done?'

There is.  A site dir is made w/ css and images in it.  I just checked.  Seems like the site
dir is made anyways, in spite of these flags saying don't generate a site.  I just removed

On hbase/pom.xml, assembly:assembly is not deprecated.  A distinction is made between assembly:single
and assembly:assembly.  The former is for attaching to the packaging or pre-package phase
somewhere.  The latter requires explicit invocation on the command-line.  In my comment above
at 01/Jun/12 23:24, I talk of how I looked at taking both routes and decided against the direction
the sonatype manual was encouraging because a). its an ugly hack (even the manual allows so)
and b). their technique attaches itself to package phase which means a user who wants to do
a basic jar build has to wait on maven copying around fat dependencies and gzipping up packages
all the while spewing their console though all they want to do is check their jar builds.
 A third reason to avoid hbase-assembly is that hbase-assembly would force an hbase-site too
since hbase-assembly would want to depend on hbase-site if the tarball was to include documentation
(the javadoc and jxr aggregations work fine up in parent, wasn't sure how well they'd work
in a submodule and it seemed wrong doing aggregations in a submodule anyways).  I think it
better that we require you explicitly ask for tarball packaging by adding the assembly:assembly
to your command line (I was afraid it would not work, that the dependency facility figuring
which jars to include would be broken but it seems fine).

Regards 'In src/assembly/all.xml, this comment is no longer applicable.'  I think it is. 
At least, w/o that section, I can't get the test jar to build in (which is why you added that
comment in first place I guess?).

bq. Also, it would be awesome to move file set matching to a more general regex, rather than
tying it to the maven property (which is defined in the main pom).

I suppose.  I don't trust mvn to do anything right.  Therefore my tendency is to keep it dumb.

bq. General nit: I prefer having the properties above the build, since the properties are
used in the build section, but that's just style.

Yeah.  I kept looking for them above ... but this is not my change.  This is how it was. 
We can change it in another issue?

bq. ...when building the site? Also, can't you just pass in -DskipJavadoc?

You mean instead of -DskipJavadoc=true?

I just tried it, and yes, seems to work.  Let me change the comment.

Again, how do you get those Unknown macro outputs?  I tried w/ -X and it doesn't show.

I don't know what NO-MVN-MAN-VER does (google'd it but no explaination after clicking ~10

Escape string is not new.  Copied from what currently exists.

On docbkx, they are built into target/docbkx, and then on site build, copied under site dir.
 Similar to javadoc.  Keeping it a little independent of site in case someone is working w/
docbkx only, and not interested in site (This is how it used work).

For docbkx configuration, this is how it was.  I tried your suggestion of moving common config
above the executions and that seems to work.  Good.  Fixed.

bq. With the aggregate goal, you can just have all the javadocs copied into the right directory
in this module when you build them; at least that is what is was doing before.

This is a change you made, that javadoc was aggregated into site/apidocs.  Previous to this,
pre-modularization, javadocs were made into target/apidocs and then copied into site when
we ran site goal.  We could go that way but seemed strange building into site if not interested
in 'site': i.e. you are just making javadocs to check them out, etc.

The xmllint --format should take care of indents and tabs.

On fixing eclipse, can we do that in another issue.  Making site and assembly work and with
a patch of 1.5M, this issue is broad enough I'd say.

Thanks for the great review.  Sounds like no fundamental objection so I'll go ahead and commit.
 I'll open new issues to address the good stuff you raise above not addressed by this patch.

> Fix site target post modularization
> -----------------------------------
>                 Key: HBASE-6145
>                 URL: https://issues.apache.org/jira/browse/HBASE-6145
>             Project: HBase
>          Issue Type: Task
>            Reporter: stack
>            Assignee: stack
>         Attachments: site.txt, site2.txt, sitev3.txt

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


View raw message