hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Smith (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2099) Move build to Maven
Date Sun, 07 Feb 2010 02:28:27 GMT

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

Paul Smith commented on HBASE-2099:
-----------------------------------

bq. But - when we publish an artifact , we can always add sources and javadocs as separate
artifacts (for the same version) - right ?? So - binary would just have .class / .jar files
as a library to link against, by other apps as needed ?

ok, I see where we may be on different wave lengths here, my apologize.  the short answer,
is maven will absolutely definitely have a -sources and -javadoc artifacts produced naturally
and pushed to a Maven repo as part of the 'deploy' phase.  That's done automatically without
any configuration.

However that common automatic case generally covers purely artifact pushing to, say, Maven
central (or more formally a spot which is automatically ingested into central).  Most projects
like to have a large tar ball with a collection of artifacts put together for the end user
(who is perhaps either looking to learn Hbase, or doesn't use Maven/Ivy).  This latter case
is what the 'tar ball' I've produced via the Maven assembly plugin does. The former case is
done automatically during the 'deploy' phase.

By default, the -sources and -javadoc are not generated during 'package' phase, but it is
easily configured to do so if that's what we wish, in  fact I've already configured -sources.jar
to always be produced during 'package' because I need that as part of the assembly in the
end so that it can appear in the tar ball.

In the maven world, the binary, the sources, and the javadoc are all separate artifacts sharing
the same groupId:artifactId:version co-ordinates.  the latter 2 just get given a 'classifier'
(with the main jar given a 'blank' classifier, implying the main artifact).

All of this becomes second nature after a while with Maven, and I forget sometimes! sorry!



> Move build to Maven
> -------------------
>
>                 Key: HBASE-2099
>                 URL: https://issues.apache.org/jira/browse/HBASE-2099
>             Project: Hadoop HBase
>          Issue Type: Task
>            Reporter: stack
>         Attachments: findbugs.html, findbugs.html, HBase Move Script.txt, HBASE-2099.9.patch,
test-reports.zip
>
>
> This issue is for discussing pros and cons of moving hbase build to Apache Maven.
> Maven, if you take on its paradigm, does a lot for you.  There are also a bunch of nice
plugins that do nice reports on state of project; findbugs, that nice plugin where you can
give out urls that will resolve to lines in source code (a doxygen-like thing ... I've forgotten
its name).  Other examples are a docbook plugin that would do the build inline with doc build.
 We could start up the hbase book using docbook format and the hbase book would ride along
with versions.
> As I see it -- and its a while since I've done this stuff so things may have since changed
-- in the way of an easy move to maven is our src/contrib content.  Maven would have these
as distinct projects pulling in their hbase dependency or, if you wanted to take on the maven
subproject notion, then, hbase would be at same level in build as the contribs -- it would
be a subproject too just built before the others.
> Anyone interested in working on this issue?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message