accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: mvn install stuck
Date Thu, 11 Apr 2013 18:05:30 GMT
Fair enough. Okay, so, I'll make a ticket to only run the rat check on
the build server and the release profile, for now.

Christopher L Tubbs II

On Thu, Apr 11, 2013 at 2:01 PM, Keith Turner <> wrote:
> On Thu, Apr 11, 2013 at 12:44 PM, Christopher <> wrote:
>> I can disable it by default... but it's just as easy to simply add
>> -DskipLicenseCheck or to disable it for all your builds by adding the
>> following to your settings.xml file:
>>  <profiles>
>>     <profile>
>>       <id>deactivate-license-checks</id>
>>       <properties>
>>         <skipLicenseCheck>true</skipLicenseCheck>
>>       </properties>
>>     </profile>
>>   </profiles>
>>   <activeProfiles>
>>     <activeProfile>deactivate-license-checks</activeProfile>
>>   </activeProfiles>
>> I understand the argument that it's configured by default for future
>> changes, but it's not exactly true. It's configured by default to be
>> pedantic, because current practices are a bit passive when it comes to
>> these sorts of checks. This is useful for clean checkouts for
>> releases, Jenkins builds, and for developers who don't run out of
>> their workspace (they assemble first). I think the default should be
>> pedantic, and it should take a minimal amount of effort to skip
>> important checks, and that's something that we can immediately start
>> benefiting from.
> I agree that finding issue early is good.   If all developers  run out
> of their workspace, wouldn't it be more convenient for everyone if it
> were disabled by default in the pom?  I think the best counterargument
> you have made for this is that it would be nice if the build server
> would always do this check.   So is their an easy way to disable this
> by default and have the build server pass in an option to turn it on?
> This particular change does not really bother me. Its more the
> precedent of changing the current build process to align with needed
> improvements that will be made in the future.
>> I'm still willing to make the change... if it is that much of a
>> nuisance, but I emphatically argue against it for the above reasons.
>> --
>> Christopher L Tubbs II
>> On Thu, Apr 11, 2013 at 10:38 AM, Keith Turner <> wrote:
>>> On Wed, Apr 10, 2013 at 2:09 PM, Christopher <> wrote:
>>>> Both of those are addressed with the profile that is activated with
>>>> -DskipLicenseCheck, so a dirty workspace will pass the check. The
>>>> focus was on being pedantic for the clean checkout situation.
>>>> We can add exceptions for those things that make a workspace dirty,
>>>> but aren't packaged, for 1.5. However, in the future (>=1.6), I'd like
>>>> to help make it easier to move away from the practice of dirtying the
>>>> source directories to run Accumulo out of one's workspace.
>>>> There is so much to maintain with all the svn:ignore properties set,
>>>> the exceptions in the custom assembly descriptors and RPM/DEB
>>>> profiles... it'd be better to allow running out of the target
>>>> directory (which is already ignored by almost all Maven plugins), and
>>>> use the default settings for packaging plugins wherever possible, than
>>>> to worry about maintaining all these exceptions.
>>>> Running out of the workspace can still be possible (out of the target
>>>> directories, or a dedicated top-level workspace directory whose tree
>>>> we ignore entirely), without all these exceptions to the rule.
>>>> So, with that in mind, I only added exceptions to the apache-rat
>>>> plugin configuration for things whose licenses are described elsewhere
>>>> (js libs), or for things where it misinterprets the file as text
>>>> instead of binary (splits, for testing), so that anything that was
>>>> dirtying the workspace would explicitly be caught. As I said, it can
>>>> be more lenient for 1.5 if you wish, but I think deactivating the
>>>> check with the -DskipLicenseCheck should be sufficient for your needs.
>>> It sounds like the rat check is configured now for changes you plan to
>>> make in the future.   IMO the poms should be configured for the way
>>> developers work now.  The changes you mention sound great, when they
>>> are made the rat check can be reconfigured.  Maybe that means
>>> skipLicenseCheck is enabled by default for now, and has to be
>>> explicitly disabled?  We do not want to put to much time into putting
>>> bandaids on something that may fundamentally change, whats the
>>> quickest solution to make it work?
>>>> I'm still curious, however, why things would have gotten stuck for
>>>> you... getting stuck is very different than failing due to license
>>>> checks.
>>>> --
>>>> Christopher L Tubbs II
>>>> On Wed, Apr 10, 2013 at 1:23 PM, John Vines <> wrote:
>>>>> Hmm, fresh checkout everything went fine. However, for sanity's sake
I went
>>>>> ahead and I dropped my configurations into conf and stripped out all
of the
>>>>> apache headers and I got a rat failure, too many unapproved licenses.It
>>>>> shouldn't be checking those files since they aren't packaged.
>>>>> It also appears to be checking my log directory, so that needs to be
>>>>> addressed too.
>>>>> On Tue, Apr 9, 2013 at 8:05 PM, John Vines <> wrote:
>>>>>> I had taken out the rat plugin in order to get it to build successfully.
>>>>>> will try your tips tomorrow.
>>>>>> Sent from my phone, please pardon the typos and brevity.
>>>>>> On Apr 9, 2013 6:34 PM, "Christopher" <>
>>>>>>> That message is the from the apache-rat plugin, but the apache-rat
>>>>>>> plugin would fail the build at verify phase if there was a problem.
>>>>>>> wouldn't hang. You're going to have to provide more info, as
it works
>>>>>>> for me. Have you tried with a clean checkout? Does it work with
>>>>>>> -DskipLicenseCheck? Does mvn package or mvn verify work?
>>>>>>> --
>>>>>>> Christopher L Tubbs II
>>>>>>> On Tue, Apr 9, 2013 at 5:44 PM, John Vines <>
>>>>>>> > Attempting to do a mvn install of 1.5 and it just hangs
with the message
>>>>>>> > [INFO] No excludes
>>>>>>> >
>>>>>>> > This has something to do with rat, but I don't know what.

View raw message