[
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 them.
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 links).
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
