You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2016/07/22 01:32:09 UTC

[DISCUSS] Proposal to remove docs/assemble profiles

We have some build profiles which aren't active by default, and I'm not
sure they're needed any more. We can simplify builds a bit by simply always
executing these tasks.

The ones I'm thinking of in particular are:

-P docs
-P assemble

Respectively, these build the asciidocs, and the binary tarball.

The docs profile used to be important, because LaTeX wasn't always
available on a user's system, and could take a long time. These aren't an
issue any more with the asciidoc plugin.

The binary tarball profile used to be important because before we moved
everything into the /target directories, our dev environment could be
dirty, and the tarball could pick up extra files... (and *maybe* it took a
long time? but I can't imagine it would've been significant).

I think we can remove these profiles and just always build the docs and
binary tarball.
If somebody really wants to skip these, they can use:

-Dasciidoctor.skip
and
-Dassembly.skipAssembly (though, this one would also affect the
accumulo-native.tar.gz assembly)

The end result of always building these by default means we can simplify
the README slightly so we can provide less maven options for users to
understand to get started.

Honestly, I can't see a downside, except adding a few seconds to the build
at the most.

Re: [DISCUSS] Proposal to remove docs/assemble profiles

Posted by Josh Elser <jo...@gmail.com>.
+1

Sean Busbey wrote:
> +1 sounds great to me.
>
> On Thu, Jul 21, 2016 at 8:32 PM, Christopher<ct...@apache.org>  wrote:
>> We have some build profiles which aren't active by default, and I'm not
>> sure they're needed any more. We can simplify builds a bit by simply always
>> executing these tasks.
>>
>> The ones I'm thinking of in particular are:
>>
>> -P docs
>> -P assemble
>>
>> Respectively, these build the asciidocs, and the binary tarball.
>>
>> The docs profile used to be important, because LaTeX wasn't always
>> available on a user's system, and could take a long time. These aren't an
>> issue any more with the asciidoc plugin.
>>
>> The binary tarball profile used to be important because before we moved
>> everything into the /target directories, our dev environment could be
>> dirty, and the tarball could pick up extra files... (and *maybe* it took a
>> long time? but I can't imagine it would've been significant).
>>
>> I think we can remove these profiles and just always build the docs and
>> binary tarball.
>> If somebody really wants to skip these, they can use:
>>
>> -Dasciidoctor.skip
>> and
>> -Dassembly.skipAssembly (though, this one would also affect the
>> accumulo-native.tar.gz assembly)
>>
>> The end result of always building these by default means we can simplify
>> the README slightly so we can provide less maven options for users to
>> understand to get started.
>>
>> Honestly, I can't see a downside, except adding a few seconds to the build
>> at the most.
>
>
>

Re: [DISCUSS] Proposal to remove docs/assemble profiles

Posted by Sean Busbey <bu...@cloudera.com>.
+1 sounds great to me.

On Thu, Jul 21, 2016 at 8:32 PM, Christopher <ct...@apache.org> wrote:
> We have some build profiles which aren't active by default, and I'm not
> sure they're needed any more. We can simplify builds a bit by simply always
> executing these tasks.
>
> The ones I'm thinking of in particular are:
>
> -P docs
> -P assemble
>
> Respectively, these build the asciidocs, and the binary tarball.
>
> The docs profile used to be important, because LaTeX wasn't always
> available on a user's system, and could take a long time. These aren't an
> issue any more with the asciidoc plugin.
>
> The binary tarball profile used to be important because before we moved
> everything into the /target directories, our dev environment could be
> dirty, and the tarball could pick up extra files... (and *maybe* it took a
> long time? but I can't imagine it would've been significant).
>
> I think we can remove these profiles and just always build the docs and
> binary tarball.
> If somebody really wants to skip these, they can use:
>
> -Dasciidoctor.skip
> and
> -Dassembly.skipAssembly (though, this one would also affect the
> accumulo-native.tar.gz assembly)
>
> The end result of always building these by default means we can simplify
> the README slightly so we can provide less maven options for users to
> understand to get started.
>
> Honestly, I can't see a downside, except adding a few seconds to the build
> at the most.



-- 
busbey

Re: [DISCUSS] Proposal to remove docs/assemble profiles

Posted by Keith Turner <ke...@deenlo.com>.
+1

On Thu, Jul 21, 2016 at 9:32 PM, Christopher <ct...@apache.org> wrote:

> We have some build profiles which aren't active by default, and I'm not
> sure they're needed any more. We can simplify builds a bit by simply always
> executing these tasks.
>
> The ones I'm thinking of in particular are:
>
> -P docs
> -P assemble
>
> Respectively, these build the asciidocs, and the binary tarball.
>
> The docs profile used to be important, because LaTeX wasn't always
> available on a user's system, and could take a long time. These aren't an
> issue any more with the asciidoc plugin.
>
> The binary tarball profile used to be important because before we moved
> everything into the /target directories, our dev environment could be
> dirty, and the tarball could pick up extra files... (and *maybe* it took a
> long time? but I can't imagine it would've been significant).
>
> I think we can remove these profiles and just always build the docs and
> binary tarball.
> If somebody really wants to skip these, they can use:
>
> -Dasciidoctor.skip
> and
> -Dassembly.skipAssembly (though, this one would also affect the
> accumulo-native.tar.gz assembly)
>
> The end result of always building these by default means we can simplify
> the README slightly so we can provide less maven options for users to
> understand to get started.
>
> Honestly, I can't see a downside, except adding a few seconds to the build
> at the most.
>