In order to give the project the best basis for reaching a sound decision
(pro-con comparison between the three suggested angles - ant+ivy, gradle,
maven), we could just as easily create also dev branches for the other two
options and have proponents work on that so that these can also be
evaluated by all.

I am willing to work on the ant+ivy angle.

Best regards,



Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Apr 22, 2015 at 11:13 AM, Pierre Smits <[email protected]>
wrote:

> I already establised a working solution for better dependency management
> based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the
> checkout at that time (35 MBs). And it seems with less effort/less
> complexity than is now is being shown in the OFBIZ-6172 branch...
>
> I suggested a dev branch back then (
> https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could
> evaluate. Unfortunately it didn't gather momentum at the time.
>
> Does that mean that it is a worse fit? I dare say: not!
>
>
>
>
>
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler <
> [email protected]> wrote:
>
>> Perhaps it would be a good idea for some of the key people to take a
>> close look at what has been done.
>>
>> This is potentially a big step forward in modernizing the product.
>>
>> Having a working solution takes a lot of the FUD out of the discussion
>> and allows the approach to be tested by the people who are building OFBiz
>> every day.
>>
>> Even if it actually does everything that Adam claims and the consensus of
>> the committers is to move to Maven, it will still be a good idea to support
>> the 2 build methods until everyone important is ready to commit to Maven.
>> It may take a while to get the Maven approach sold to everyone even if they
>> know that at some point they will be forced to move. Some will be early
>> adopters and some will be late but if you don't have to force everyone to
>> move at once, it does make the transition easier.
>>
>> If it is the consensus that the Ant build is still better, the Maven
>> stuff is easy to remove without damaging the Ant build.
>>
>> I suggest leaving it in until everyone who needs to test it before the
>> decision is made, has a chance to test it.
>> It is unreasonable to expect each of the committers to make their own
>> Maven build to test the idea.
>>
>> Adam has saved us a lot of speculation about what it means to move to
>> Maven.
>>
>> Give the supporters and skeptics some time to test before removing it.
>>
>> Ron
>>
>>
>> On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:
>>
>>> On Apr 21, 2015, at 10:37 PM, Adam Heath <[email protected]> wrote:
>>>
>>>  My commit is not breaking anything.  Why remove something that is
>>>> harmless?
>>>>
>>> Hi Adam,
>>>
>>> The fact that a commit is harmless is not enough for its approval.
>>> I know that your commit doesn't cause any side effects and I appreciate
>>> that you are now doing your work in a feature branch.
>>> I am asking you to revert that commit to trunk not because its quality
>>> is bad or I see potential issues but only because the decision about the
>>> official build tool for the project must be taken by the community and we
>>> are not planning to maintain more than one alternative options in the
>>> official repository.
>>> Just to make it super clear, I restate my request: please revert 1674216
>>> (it is the only commit to trunk) then let's continue the work about Maven
>>> in the release branch you have created.
>>> In the meantime the discussion about "ant vs ant+ivy vs maven vs gradle
>>> vs ..." will go on and its outcome will determine the final decision; since
>>> there are clearly different points of view for the different tools we all
>>> have to be open to consider other's opinions: crystallized positions will
>>> not help much in this context.
>>> The branch you have created is valuable because it provides a reference
>>> implementation for the discussion, but it is important that you appreciate
>>> that it may not be merged into the project (based on the outcome of the
>>> ongoing discussion).
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [email protected]
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>

Reply via email to