Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> Artifact id for HBase - trunk


+
ramkrishna vasudevan 2013-02-25, 11:17
+
Nicolas Liochon 2013-02-25, 11:25
+
ramkrishna vasudevan 2013-02-25, 12:51
+
Nicolas Liochon 2013-02-25, 13:37
+
Jesse Yates 2013-02-25, 16:13
+
ramkrishna vasudevan 2013-02-25, 16:24
+
Jesse Yates 2013-02-25, 16:48
+
ramkrishna vasudevan 2013-02-25, 16:52
+
ramkrishna vasudevan 2013-02-25, 17:26
Copy link to this message
-
Re: Artifact id for HBase - trunk
No worries Ram!

In this case, yes the artifactID is indeed 'hbase', but because it is a
parent module it doesn't make an actual artifact. From the sonatype maven
book:

The parent project doesn’t create a JAR or a WAR like our previous
> projects; instead, it is simply a POM that refers to other Maven projects.
> The appropriate packaging for a project like simple-parent that simply
> provides a Project Object Model is pom.

           -
http://www.sonatype.com/books/mvnex-book/reference/multimodule-sect-simple-parent.html

So another project could reference it, but it really wouldn't do anything
for that project because there is no code content in that dependency.

-Jesse

-------------------
Jesse Yates
@jesse_yates
jyates.github.com
On Mon, Feb 25, 2013 at 9:26 AM, ramkrishna vasudevan <
[EMAIL PROTECTED]> wrote:

> Had more doubt
> In the hbase-server-0.95-SNAPSHOT.pom we specify
>
>   <parent>
>     <artifactId>hbase</artifactId>
>     <groupId>org.apache.hbase</groupId>
>     <version>0.95-SNAPSHOT</version>
>
> So here also the artificat id is hbase.  Is this right?  Some one will try
> to use the pom attached with that module right and try writing his
> project's pom.
> Just asking these questions to learn.  I may be wrong here.
>
> Regards
> Ram
>
> On Mon, Feb 25, 2013 at 10:22 PM, ramkrishna vasudevan <
> [EMAIL PROTECTED]> wrote:
>
> > Fine, i understand now.  Thanks for your time Jesse.
> >
> > Regards
> > Ram
> >
> >
> > On Mon, Feb 25, 2013 at 10:18 PM, Jesse Yates <[EMAIL PROTECTED]
> >wrote:
> >
> >> Yeah, if you want to use trunk (or 0.95), you need to modify your pom to
> >> add all the hbase modules (-server, -commons, etc). You would have to
> >> modify the pom anyways to bump the version number, so adding a few more
> >> lines for each module shouldnt break the workflow :)
> >>
> >> And yeah, this will affect other projects based on trunk, but they
> should
> >> have had to make this changes months ago, when we did the modularization
> >> (if they were on trunk then).
> >>
> >>
> >> - Jesse Yates
> >>
> >> Sent from my iPhone.
> >>
> >> On Feb 25, 2013, at 8:24 AM, ramkrishna vasudevan <
> >> [EMAIL PROTECTED]> wrote:
> >>
> >> > Okie Jesse..
> >> > So suppose i have an external project that already has a dependency
> >> added
> >> > to hbase and the artificat id is 'hbase'.
> >> >
> >> > But i have a need to use the trunk version.  So in the external
> project
> >> i
> >> > need to modify the pom as an work around right.  That will do.  I
> >> thought
> >> > this will affect other projects depending on hbase trunk na.
> >> >
> >> > Regards
> >> > Ram
> >> >
> >> > On Mon, Feb 25, 2013 at 9:43 PM, Jesse Yates <[EMAIL PROTECTED]
> >> >wrote:
> >> >
> >> >> I don't think you need a patch (not sure what Nicholas was commenting
> >> on
> >> >> WRT to Elliots work here) - that's the way mutli-module maven
> projects
> >> work
> >> >> AFAIK. Hopefully, when Elliot does finish the client module though,
> >> pulling
> >> >> in just hbase-client and hbase-common (for client side stuff) will be
> >> >> natural (as opposed to the current where you need all the modules for
> >> the
> >> >> client, including hbase-server).
> >> >>
> >> >> It might be nice though to have a meta artifact that's just
> >> >> hbase-<VERSION>. I did something similar for Phoenix where you
> >> basically
> >> >> can build a single jar with all the dependent, compiled sources
> rolled
> >> into
> >> >> the jar (as opposed to a jar of jars), so we could consider something
> >> like
> >> >> that too.
> >> >>
> >> >> -Jesse
> >> >> -------------------
> >> >> Jesse Yates
> >> >> @jesse_yates
> >> >> jyates.github.com
> >> >>
> >> >>
> >> >> On Mon, Feb 25, 2013 at 5:37 AM, Nicolas Liochon <[EMAIL PROTECTED]>
> >> >> wrote:
> >> >>
> >> >>> I understood that Elliot is working on this subject, but I don't
> know
> >> >>> exactly what he's targeting. Just that it will be ready very soon...
+
Elliott Clark 2013-02-25, 17:36
+
Jesse Yates 2013-02-25, 17:39
+
Andrew Purtell 2013-02-25, 17:49
+
Stack 2013-02-25, 20:04
+
Andrew Purtell 2013-02-25, 23:29
+
ramkrishna vasudevan 2013-02-26, 02:49
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB