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 Threaded View
Accumulo >> mail # user >> [VOTE] 1.5.0-RC2


Copy link to this message
-
Re: [VOTE] 1.5.0-RC2
+1

On Sunday, May 12, 2013, Christopher wrote:

> Okay, so, personally, my favorite combination of options is:
>
> Drop the assemble portion if possible, keep "source-release" and
> "binary-release" as the classifiers for maven, and rename the
> filenames to "-src.tar.gz" and "-bin.tar.gz" when mirroring and
> publishing on the website (doesn't even require re-signing). This
> keeps maven artifacts explicit, and follows conventions for download
> links from the mirrors/website. While maven has a convention for
> filenames, we don't have to be constrained by maven's filename
> conventions when we publish on the website/mirrors.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Sun, May 12, 2013 at 10:08 PM, Drew Farris <[EMAIL PROTECTED]<javascript:;>>
> wrote:
> >
> >
> > On Sun, May 12, 2013 at 12:54 PM, Christopher <[EMAIL PROTECTED]<javascript:;>>
> wrote:
> >>
> >>
> >> I don't want to change the source-release tarball name, because I
> >> don't want to override the parent pom conventions for the *official*
> >> source release. However, there may be more to be done with the
> >> binary-release tarball... I'm just not sure what is the best option,
> >> keeping in mind the factors of 1) consistency with prior releases, 2)
> >> maven standards and conventions, 3) consistency between what is
> >> published in Maven and what is published in the mirrors, and 4) not
> >> holding up the release.
> >
> >
> > Christopher, thanks for the detailed explanation.
> >
> > I believe I understand your goals regarding conventions (sticking to
> them),
> > but something seems a little strange about the 'source-release' tarball
> name
> > considering the Apache Maven project itself does not follow that
> convention
> > for their artifacts (see: http://maven.apache.org/download.cgi) --
> neither
> > do Hadoop, Lucene or HTTPd.
> >
> > That said, there appear to be a number of projects that >do< use
> > source-release (https://www.google.com/search?q=source-release.tar.gz),
> so
> > if it source-release.tar.gz is generally what's preferred over
> src.tar.gz,
> > let's go with it.
> >
> > Point taken about dist vs. bin -- I'd seen dist used in previous versons
> of
> > accumulo, but bin makes much more sense and seems to be a common
> convention.
> > The second most common convention seems to be leaving the type off the
> > tar.gz entirely, e.g: accumulo-1.5.0.tar.gz - according to google,
> > binary-release.tar.gz seems to be used absolutely nowhere, so accumulo
> would
> > be certainly a trailblazer in this territory if we followed that naming
> > convention.
> >
> > Both of these facts aside, the oddest thing to me is the inclusion of
> > 'assemble' in the artifact name. I understand why it is there and why it
> is
> > necessary to assemble everything in a separate maven submodule, but
> changing
> > this should be as simple as changing the finalName parameter in the
> assembly
> > plugin configuration, shouldn't it? If we really must include something
> in
> > the artifact name, consider the more meaningful term 'distribution'
> instead
> > of 'assemble'? Then we wind up with something like:
> > accumulo-distribution-1.5.0-source-release.tar.gz (which is pretty
> > long-winded, isn't it?)
> >
> > So, preferring the terse, I'd vote for accumulo-1.5.0-src.tar.gz and
> > accumulo-1.5.0.tar.gz or accumulo-1.5.0-bin.tar.gz
> >
> >
> >
>
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