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
--
