syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <>
Subject Re: [DISCUSS] Enabling Apache Maven wrapper
Date Thu, 26 Sep 2019 11:41:11 GMT
On 25/09/19 18:27, Misagh Moayyed wrote:
> This is fair; no problem. Based on your list, I certainly agree that #3 and #4 are complications
best not dealt with :) 

Sorry for this: as a community, we cut our teeth in the ASF Incubator, striving to define
a release process fully compliant with ASF legal requirements and practical enough for devs.

If you are interested, there is something to read at:



Will you close the PR #122 at this point?

> ----- Original Message -----
>> From: "Francesco Chicchiriccò" <>
>> To: "dev" <>
>> Sent: Wednesday, September 25, 2019 1:50:24 PM
>> Subject: Re: [DISCUSS] Enabling Apache Maven wrapper
>> On 25/09/19 10:05, Misagh Moayyed wrote:
>>> Hello all,
>>> I have proposed a pull request [1] to enable the maven wrapper plugin for
>>> Syncope. This is a plugin that allows one to build and run Syncope from source
>>> without having to install Maven locally. It's able to download and configure
>>> the appropriate maven version automatically, and then proceeds as if it was
>>> locally installed and available.
>>> There are a number of advantages to using the wrapper:
>>> - Contributors to Syncope do not have to have Maven downloaded/installed
>>> locally, though nothing would prevent them from doing so.
>>> - This should also prevent conflicts by allowing usage a specific install of
>>> maven for Syncope, in case one might need different maven versions on their
>>> system for different projects, etc.
>>> - The wrapper makes sure the correct version of maven is downloaded and
>>> installed, removing potential confusing around "If I do install maven locally,
>>> what version of Maven do I need?"
>>> - The maven version is controlled by the project for CI tests, and not by the
>>> system itself, which is useful in case CI decides to change/update versions or
>>> goes outdated for any reason.
>>> - The maintenance and overhead of the change is very minimal where future
>>> changes to the maven version are controlled with a simple properties file.
>>> How do others feel about this change?
>> Hi Misagh,
>> thanks for bringing this to discussion.
>> Honestly, I don't see much value added by this:
>> 1. Syncope does not simply require "a specific Maven version"; rather, we run
>> the maven-enforcer-plugin as part of the build, which checks Maven version is
>>> = 3.50 and JDK version
>> 2. We've never had troubles with CIs due to Maven version
>> 3. Apache RAT analysis has failed on your PR [3], and I suspect this is because
>> of non-compliant [4] or missing [5] license headers - I am wondering whether
>> these can be changed, or we are not allowed simply because we are importing
>> source files from a different entity than ASF
>> 4. We would be adding binary files [6] to our source tree; this would imply
>> changing our root LICENSE / NOTICE files + adjusting the source package
>> management during release process
>> 5. I haven't made an extensive search, but I could not find any usage of Maven
>> wrapper in any of the ASF projects I am involved in
>> 6. <hyperbolic_mode>Why limit to Maven? Why not bundling JDK? Or operating
>> system?</hyperbolic_mode>
>> Summarizing: I don't find enough reasons to be -1 against such proposed change,
>> but I would rather avoid the amount of troubles it brings (especially for
>> releases), as I see the trade-off with benefits extremely low.
>> Regards.
>>> [1]
>> [2]
>> [3]
>> [4]
>> [5]
>> [6]

Francesco Chicchiriccò

Tirasa - Open Source Excellence

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail

View raw message