Moving ZIP and TAR.GZ "formats" into an explicit profile

[Andre <an...@fucs.org>]

devs,

Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a
directory containing the same code. This leads to wasted disk space and a
lot of wasted disk writes (something that a lot of folks using SSDs prefer
to avoid).

Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into a
"release" profile (or whatever name we agree to). This way we could
maintain the directory "format" (which I suspect most of us use during
development), while still providing a convenient way of creating the ZIP
and TAR.GZ packages.


Depending on the feedback I will be happy to raise the JIRA and work on it.

Cheers

Re: Moving ZIP and TAR.GZ "formats" into an explicit profile

[Joe Witt <jo...@gmail.com>]

Andre - thanks for this.  I just used it.  Much happiness.  I cannot
wait until we get some of this registry work advanced further.
Breaking apart NiFi builds to get extensions and core framework
aspects separated will result in much happiness for travis-ci and all
of us.

Thanks
joe

On Wed, Feb 15, 2017 at 5:12 PM, Andre <an...@fucs.org> wrote:
> All,
>
> This is a reminder that the dir-only profile has been merged to the master
> branch. So for those trying to save SSD writes or simply skip a few CPU
> cycles archiving the nifi assembly during development, you can now use mvn
> -Pdir-only to skip the pain.
>
> I also would like to point out that since
> commit 7e97946c359bfcb62ef39a2ce37083554501f1b0, parallel test runs now
> seem to be far more stable. If things continue stable, we may later on
> re-introduce parallel test runs to travis.
>
> Cheers
>
>
>
> On Fri, Feb 3, 2017 at 11:04 PM, Andre <an...@fucs.org> wrote:
>
>> devs,
>>
>> Thank you for the comments.
>>
>> NIFI-3434 has been raised and submitted as PR#1472. The commit introduces
>> generateArchives (default and [hopefully] mimicking current behavior) and
>> dir-only (skipping the archive generation).
>>
>> Once again thank you for your comments.
>>
>> On Fri, Feb 3, 2017 at 10:34 AM, Andy LoPresto <al...@apache.org>
>> wrote:
>>
>>> +1 to Russell’s point and thanks Andre for bringing up the topic. I’d
>>> hesitate to change the default now because people probably are depending on
>>> the default, but I wouldn’t object to a shift in the default at a major
>>> release.
>>>
>>> Andy LoPresto
>>> alopresto@apache.org
>>> *alopresto.apache@gmail.com <al...@gmail.com>*
>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>
>>> On Feb 2, 2017, at 8:27 AM, Russell Bateman <ru...@windofkeltia.com>
>>> wrote:
>>>
>>> Maven profiles could be used to sort this out, one for just the zip,
>>> another for just the tarball and a third, maybe the default, to continue
>>> working the way it has been working.
>>>
>>> On 02/02/2017 09:09 AM, Aldrin Piri wrote:
>>>
>>> I think this could be useful.  Only caveat is that I'm sure there are
>>> folks
>>> in the community that have automated processes that make use of these
>>> binaries.
>>>
>>> From the dev standpoint, I could see a profile that disables the assembly
>>> from happening such that the build occurs as it does now unless folks
>>> explicitly want to avoid it.  Regardless of implementation, can see why it
>>> would be helpful.
>>>
>>> On Thu, Feb 2, 2017 at 9:29 AM, Andre <an...@fucs.org> wrote:
>>>
>>> devs,
>>>
>>> Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a
>>> directory containing the same code. This leads to wasted disk space and a
>>> lot of wasted disk writes (something that a lot of folks using SSDs prefer
>>> to avoid).
>>>
>>> Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into
>>> a
>>> "release" profile (or whatever name we agree to). This way we could
>>> maintain the directory "format" (which I suspect most of us use during
>>> development), while still providing a convenient way of creating the ZIP
>>> and TAR.GZ packages.
>>>
>>>
>>> Depending on the feedback I will be happy to raise the JIRA and work on
>>> it.
>>>
>>> Cheers
>>>
>>>
>>>
>>>
>>

Re: Moving ZIP and TAR.GZ "formats" into an explicit profile

[Andre <an...@fucs.org>]

All,

This is a reminder that the dir-only profile has been merged to the master
branch. So for those trying to save SSD writes or simply skip a few CPU
cycles archiving the nifi assembly during development, you can now use mvn
-Pdir-only to skip the pain.

I also would like to point out that since
commit 7e97946c359bfcb62ef39a2ce37083554501f1b0, parallel test runs now
seem to be far more stable. If things continue stable, we may later on
re-introduce parallel test runs to travis.

Cheers



On Fri, Feb 3, 2017 at 11:04 PM, Andre <an...@fucs.org> wrote:

> devs,
>
> Thank you for the comments.
>
> NIFI-3434 has been raised and submitted as PR#1472. The commit introduces
> generateArchives (default and [hopefully] mimicking current behavior) and
> dir-only (skipping the archive generation).
>
> Once again thank you for your comments.
>
> On Fri, Feb 3, 2017 at 10:34 AM, Andy LoPresto <al...@apache.org>
> wrote:
>
>> +1 to Russell’s point and thanks Andre for bringing up the topic. I’d
>> hesitate to change the default now because people probably are depending on
>> the default, but I wouldn’t object to a shift in the default at a major
>> release.
>>
>> Andy LoPresto
>> alopresto@apache.org
>> *alopresto.apache@gmail.com <al...@gmail.com>*
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>
>> On Feb 2, 2017, at 8:27 AM, Russell Bateman <ru...@windofkeltia.com>
>> wrote:
>>
>> Maven profiles could be used to sort this out, one for just the zip,
>> another for just the tarball and a third, maybe the default, to continue
>> working the way it has been working.
>>
>> On 02/02/2017 09:09 AM, Aldrin Piri wrote:
>>
>> I think this could be useful.  Only caveat is that I'm sure there are
>> folks
>> in the community that have automated processes that make use of these
>> binaries.
>>
>> From the dev standpoint, I could see a profile that disables the assembly
>> from happening such that the build occurs as it does now unless folks
>> explicitly want to avoid it.  Regardless of implementation, can see why it
>> would be helpful.
>>
>> On Thu, Feb 2, 2017 at 9:29 AM, Andre <an...@fucs.org> wrote:
>>
>> devs,
>>
>> Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a
>> directory containing the same code. This leads to wasted disk space and a
>> lot of wasted disk writes (something that a lot of folks using SSDs prefer
>> to avoid).
>>
>> Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into
>> a
>> "release" profile (or whatever name we agree to). This way we could
>> maintain the directory "format" (which I suspect most of us use during
>> development), while still providing a convenient way of creating the ZIP
>> and TAR.GZ packages.
>>
>>
>> Depending on the feedback I will be happy to raise the JIRA and work on
>> it.
>>
>> Cheers
>>
>>
>>
>>
>

Re: Moving ZIP and TAR.GZ "formats" into an explicit profile

[Andre <an...@fucs.org>]

devs,

Thank you for the comments.

NIFI-3434 has been raised and submitted as PR#1472. The commit introduces
generateArchives (default and [hopefully] mimicking current behavior) and
dir-only (skipping the archive generation).

Once again thank you for your comments.

On Fri, Feb 3, 2017 at 10:34 AM, Andy LoPresto <al...@apache.org> wrote:

> +1 to Russell’s point and thanks Andre for bringing up the topic. I’d
> hesitate to change the default now because people probably are depending on
> the default, but I wouldn’t object to a shift in the default at a major
> release.
>
> Andy LoPresto
> alopresto@apache.org
> *alopresto.apache@gmail.com <al...@gmail.com>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Feb 2, 2017, at 8:27 AM, Russell Bateman <ru...@windofkeltia.com> wrote:
>
> Maven profiles could be used to sort this out, one for just the zip,
> another for just the tarball and a third, maybe the default, to continue
> working the way it has been working.
>
> On 02/02/2017 09:09 AM, Aldrin Piri wrote:
>
> I think this could be useful.  Only caveat is that I'm sure there are folks
> in the community that have automated processes that make use of these
> binaries.
>
> From the dev standpoint, I could see a profile that disables the assembly
> from happening such that the build occurs as it does now unless folks
> explicitly want to avoid it.  Regardless of implementation, can see why it
> would be helpful.
>
> On Thu, Feb 2, 2017 at 9:29 AM, Andre <an...@fucs.org> wrote:
>
> devs,
>
> Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a
> directory containing the same code. This leads to wasted disk space and a
> lot of wasted disk writes (something that a lot of folks using SSDs prefer
> to avoid).
>
> Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into a
> "release" profile (or whatever name we agree to). This way we could
> maintain the directory "format" (which I suspect most of us use during
> development), while still providing a convenient way of creating the ZIP
> and TAR.GZ packages.
>
>
> Depending on the feedback I will be happy to raise the JIRA and work on it.
>
> Cheers
>
>
>
>

Re: Moving ZIP and TAR.GZ "formats" into an explicit profile

[Andy LoPresto <al...@apache.org>]

+1 to Russell’s point and thanks Andre for bringing up the topic. I’d hesitate to change the default now because people probably are depending on the default, but I wouldn’t object to a shift in the default at a major release.

Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Feb 2, 2017, at 8:27 AM, Russell Bateman <ru...@windofkeltia.com> wrote:
> 
> Maven profiles could be used to sort this out, one for just the zip, another for just the tarball and a third, maybe the default, to continue working the way it has been working.
> 
> On 02/02/2017 09:09 AM, Aldrin Piri wrote:
>> I think this could be useful.  Only caveat is that I'm sure there are folks
>> in the community that have automated processes that make use of these
>> binaries.
>> 
>> From the dev standpoint, I could see a profile that disables the assembly
>> from happening such that the build occurs as it does now unless folks
>> explicitly want to avoid it.  Regardless of implementation, can see why it
>> would be helpful.
>> 
>> On Thu, Feb 2, 2017 at 9:29 AM, Andre <an...@fucs.org> wrote:
>> 
>>> devs,
>>> 
>>> Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a
>>> directory containing the same code. This leads to wasted disk space and a
>>> lot of wasted disk writes (something that a lot of folks using SSDs prefer
>>> to avoid).
>>> 
>>> Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into a
>>> "release" profile (or whatever name we agree to). This way we could
>>> maintain the directory "format" (which I suspect most of us use during
>>> development), while still providing a convenient way of creating the ZIP
>>> and TAR.GZ packages.
>>> 
>>> 
>>> Depending on the feedback I will be happy to raise the JIRA and work on it.
>>> 
>>> Cheers
> 

Re: Moving ZIP and TAR.GZ "formats" into an explicit profile

[Russell Bateman <ru...@windofkeltia.com>]

Maven profiles could be used to sort this out, one for just the zip, 
another for just the tarball and a third, maybe the default, to continue 
working the way it has been working.

On 02/02/2017 09:09 AM, Aldrin Piri wrote:
> I think this could be useful.  Only caveat is that I'm sure there are folks
> in the community that have automated processes that make use of these
> binaries.
>
>  From the dev standpoint, I could see a profile that disables the assembly
> from happening such that the build occurs as it does now unless folks
> explicitly want to avoid it.  Regardless of implementation, can see why it
> would be helpful.
>
> On Thu, Feb 2, 2017 at 9:29 AM, Andre <an...@fucs.org> wrote:
>
>> devs,
>>
>> Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a
>> directory containing the same code. This leads to wasted disk space and a
>> lot of wasted disk writes (something that a lot of folks using SSDs prefer
>> to avoid).
>>
>> Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into a
>> "release" profile (or whatever name we agree to). This way we could
>> maintain the directory "format" (which I suspect most of us use during
>> development), while still providing a convenient way of creating the ZIP
>> and TAR.GZ packages.
>>
>>
>> Depending on the feedback I will be happy to raise the JIRA and work on it.
>>
>> Cheers

Re: Moving ZIP and TAR.GZ "formats" into an explicit profile

[Aldrin Piri <al...@gmail.com>]

I think this could be useful.  Only caveat is that I'm sure there are folks
in the community that have automated processes that make use of these
binaries.

From the dev standpoint, I could see a profile that disables the assembly
from happening such that the build occurs as it does now unless folks
explicitly want to avoid it.  Regardless of implementation, can see why it
would be helpful.

On Thu, Feb 2, 2017 at 9:29 AM, Andre <an...@fucs.org> wrote:

> devs,
>
> Currently calling 'mvn clean install' creates a ZIP, a TAR.GZ and a
> directory containing the same code. This leads to wasted disk space and a
> lot of wasted disk writes (something that a lot of folks using SSDs prefer
> to avoid).
>
> Would anyone oppose the idea of moving the ZIP and TAR.GZ assemblies into a
> "release" profile (or whatever name we agree to). This way we could
> maintain the directory "format" (which I suspect most of us use during
> development), while still providing a convenient way of creating the ZIP
> and TAR.GZ packages.
>
>
> Depending on the feedback I will be happy to raise the JIRA and work on it.
>
> Cheers
>