Some of the build files are really ugly at the moment and difficult to read:
see the macros.xml, src-extra-set etc...
The ability to write real code snippets may greatly simplify them.
Jacopo
On Apr 20, 2015, at 7:00 PM, David E. Jones <d...@me.com> wrote:
>
> That gets back to the question of why change in the first place... build
> files may be smaller and easier to maintain, but there may not be a good
> reason!
>
> -David
>
>
>> On 20 Apr 2015, at 09:37, Pierre Smits <pierre.sm...@gmail.com> wrote:
>>
>> David,
>>
>> Thanks for sharing your insights. You talk about 'pretty much anything
>> can be done with'. What, in your experience, can't be done -at the
>> moment- in relation to OFBiz?
>>
>> Best regards,
>>
>> Pierre
>>
>> Op maandag 20 april 2015 heeft David E. Jones <d...@me.com> het volgende
>> geschreven:
>>
>>>
>>> Not to muddy the waters... but Gradle might be a good alternative. There
>>> is a lot more in it than Ant that "just works" without needing to be
>>> explicit, especially when you follow Maven conventions for layout of src
>>> directories.
>>>
>>> One big upside of Gradle is that all build files are Groovy scripts and
>>> you can do pretty much anything in them. One downside is the learning
>>> curve... there is an extensive DSL with pretty good documentation, but some
>>> things that would seem simple are non-obvious (to put it generously). On
>>> the other hand, there is fairly wide use so I still have yet to run
>>> anything where I couldn't find a solution quickly with a google search.
>>>
>>> -David
>>>
>>>
>>>> On 19 Apr 2015, at 22:51, Hans Bakker <mailingl...@antwebsystems.com
>>> <javascript:;>> wrote:
>>>>
>>>> We should seriously consider the comments from Adam and move to maven.
>>>>
>>>> Regards,
>>>> Hans
>>>> antwebsystems.com
>>>>
>>>>
>>>> On 18/04/15 00:41, Adam Heath wrote:
>>>>>
>>>>> On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
>>>>>> Thanks for your detailed heads-up Martin, notably your last point!
>>>>>>
>>>>>> I mostly agree, and indeed I also think Maven might not be so bad when
>>> you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 17/04/2015 16:27, Martin Becker a écrit :
>>>>>>> +1 for lack of benefit (and for fear ;-))
>>>>>
>>>>> The commit I did last night took me 45 minutes. Full stop. I started
>>> at 12:03am. And I did it while drinking a second beer. Maven was that
>>> simple. I had resisted for years. Years! But when I actually sat down to
>>> do it, I realized that I did *not* have to change what I was doing. Maven
>>> could be configured to work with the existing design.
>>>>>
>>>>> The benefits are:
>>>>>
>>>>> * not having to write our own build system; ant is not a build system.
>>>>>
>>>>> * full external dependency management. This can be done very
>>> incrementally. I just got framework/base to compile, by reusing the
>>> previously downloaded jars in framework/base/lib. Then, when all
>>> dependencies are *properly* listed, we can switch to the download
>>> mechanism, and suddenly, the checkout becomes smaller.
>>>>>
>>>>> * full internal dependency support. As part of framework/base now
>>> having a working pom.xml, it has a dep on framework/start. This can allow
>>> for end-users wanting to just install applications/party, and having just
>>> what is required get downloaded.
>>>>>
>>>>> * Each ofbiz component could be moved to separate repos, and
>>> development can progress on its own. All that specialpurpose/* stuff no
>>> longer needs to be carried along with the rest of the codebase.
>>>>>
>>>>> * continuous integration becomes so much simpler; the standard "mvn
>>> package" call does command-line unit tests, *by default*.
>>>>>
>>>>> * these poms do not break anything. Nothing calls them. Everyone can
>>> continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.
>>> So, having them in trunk won't cause issue for anyone else. This is the
>>> way linux-kernel functions. Completely new, isolated features, that affect
>>> no one else, are added to master/linux-next, so that they can get pushed
>>> out to more users, for more testing. If something is done in a separate
>>> branch, they have discovered it doesn't recieve enough widespread testing.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My first thoughts:
>>>>>>>
>>>>>>> => If a change is desired, than Gradle would surely be a good choice
>>> as it is the next generation build tool witch tries to combine the
>>> advantages from tools like ant, maven and others…
>>>>>
>>>>> Sure, why not?
>>>>>
>>>>>
>>>>> Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
>>> common.xml, but really, lets not go there.
>>>>>
>>>>>>>
>>>>>>> => I think the stability of Gradle is not a question as it is used by
>>> projects like Spring, Hibernate, Grails, Groovy and others…
>>>>>>>
>>>>>>> => With the ability to use ant tasks and whole ant build scripts
>>> within Gradle, a smooth migration could be an option
>>>>>>>
>>>>>
>>>>> Maven can call ant. I'm even doing so in the 2 poms that I added.
>>>>>
>>>>>>> => Maven rely on it’s convention over configuration pattern, so it is
>>> never a good idea to NOT follow it’s conventions by configuring it for a
>>> different project structure for example. So there may be the need for
>>> massive changes to the OFBiz project structure and so on.
>>>>>>>
>>>>>
>>>>> I just got framework/base to compile with maven. This includes *NO*
>>> changes to ofbiz layout. framework/base/lib still exists. Nothing is being
>>> downloaded(except maven plugins, of course).
>>>>>
>>>>>>> => Also the ability to only produce one artifact per project in maven
>>> would perhaps end up in configuring sub projects for each application and
>>> module in OFBiz with a frustrating handling of multi module configurations
>>> with version-/release-tags, dependency handling and so on...
>>>>>>>
>>>>>
>>>>> This is wrong. You can produce multiple artifacts. I've seen it done
>>> in other projects.
>>>>>
>>>>>>> => I used maven in multi module project setups before and it has it’s
>>> nice features, although it is sometimes hard to understand details and
>>> effects of the build lifecycle or single plugins. But the main fact is,
>>> that this were green-field projects, so things in terms of convention over
>>> configuration are much easier to adopt than in legacy projects like an
>>> OFBiz…
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> => The change of the build tool for OFBiz would be a fundamental
>>> change, particularly for upgrading existing installations. So a change to
>>> the project structure could be a deathblow to OFBiz vendor imports in
>>> customer projects. I think it could be a good starting point to look at
>>> Gradle and see if there is a wise way to use the strength and new features
>>> of a modern build tool without the need to turn things inside out in OFBiz.
>>>>>>>
>>>>>
>>>>> I'm not just some noob in ofbiz. I've been around for quite a bit.
>>> I've been around when ofbiz was still using CVS. I was the first to start
>>> using git locally for ofbiz development, and for our own ofbiz
>>> extensions/fixes/client work. I've also been invovled with Debian in years
>>> past, being involved in several migrations. I also added generics(and
>>> enhanced for loops, etc), to *all* of framework, to spearhead that
>>> project. But seriously, moving on.
>>>>>
>>>>> But, what structure changes have I propsed? None. I've got it working
>>> with the exsting layout. Nothing has turned inside out.
>>>>>
>>>>>>>
>>>>>>> Martin Becker
>>>>>>> ecomify GmbH
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Am 17.04.2015 um 13:56 schrieb Jacques Le Roux <
>>> jacques.le.r...@les7arts.com <javascript:;>>:
>>>>>>>>
>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>> slidingfilame...@gmail.com <javascript:;>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Thank you for your work but I thought we are more inclined to move
>>> to gradle based build systems given its many advantages as a full
>>> programming language build system based on groovy.
>>>>>>>>>>
>>>>>>>>>> Taher Alkhateeb
>>>>>>>>> I agree: we could explore the switch to Gradle and also review the
>>> way our source files (Java, Groovy and Minilang/xml) are organized (we
>>> could actually follow the layout that is considered the default for Maven
>>> and Gradle and possibly other tools).
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>> I don't know if Gradle is stable now, but I'd surely be for instead
>>> of Maven. If ever we really desire to move from Ant, I don't clearly see
>>> the necessity at this stage...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> --
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>
