Adrian signaled ant builds have a nice autocompleter. What about Graddle?
One think I don't like (though it improved, and hopegully will continue to improve) is the autocompletion in Groovy scripts in Eclipse (I used Kepler,
I guess that's why people turn to IntelliJ), compared to Java
Le
With Moqui Framework I started using Ant and then migrated to Gradle. In doing
so there are some things to be aware of:
1. because of the convention over configuration goal (defaults can generally be
overridden, but it's a bit painful) it is a good idea to restructure things
like the src
Jacopo,
Sorry to react on your comment at the end of your post below.
May i ask you to study continuous deployment? Up to now the trunk was
always very stable. Once in a while some problems, but they never lasted
more than a couple of days.
At AntWebsystems we are supporting continuous
I have been a member of this community for 10 years, and I don't agree
that Up to now the trunk was always very stable. The trunk has always
been the bleeding edge of OFBiz development and design - and that is the
reason we have release branches.
Adrian Crum
Sandglass Software
What you describe is (I guess) essentially this:
https://www.atlassian.com/git/workflows#!workflow-gitflow
and I know it (we have projects following this pattern) and it works pretty
well; this is *not* the workflow that OFBiz community is currently
implementing. Theres is no right or wrong
Hi Jacopo,
One of the ideas we suggest is to introduce gradle alongside ant at the top
level directory (build.gradle next to build.xml) and replace some of the
scripts that currently exist under /tools with tasks and projects in gradle
(e.g. mergefromtrunk.sh). It is also quite trivial to design
Le 21/08/2014 07:41, Jacopo Cappellato a écrit :
On Aug 20, 2014, at 10:26 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
This is one reason which would refrain me to jump right now. With of course all
the burden and especially the inherent risks of permutation.
I think that
On Aug 21, 2014, at 12:40 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
I think you did not get me right. Like I have explained to Ron, branches are
not only to get stabilised releases. So my idea would be to have a new
feature branch where we can make the desired changes before
As a pro it should stated that migrating to gradle would - wait for it -
help in the migration to and/or from moqui.org, as it is one its many
advanced built-in tools. I appreciate the groovy-everywhere consistency of
moqui and believe that it would be a good direction for OFBiz to head.
On Thu,
Le 21/08/2014 15:17, Jacopo Cappellato a écrit :
On Aug 21, 2014, at 12:40 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
I think you did not get me right. Like I have explained to Ron, branches are
not only to get stabilised releases. So my idea would be to have a new feature
Le 21/08/2014 15:48, Al Byers a écrit :
As a pro it should stated that migrating to gradle would - wait for it -
help in the migration to and/or from moqui.org, as it is one its many
advanced built-in tools. I appreciate the groovy-everywhere consistency of
moqui and believe that it would be a
That is one person's opinion. The reason OFBiz got to where it is today
is because of innovation, and a certain fearlessness in trying new
things. But that fearlessness ended years ago.
Moqui exists because the OFBiz community turned its back on innovation.
I don't see Moqui ever making it
+1 having a new feature branch, and then merge after review AND
automated tests.
On 21/08/14 17:40, Jacques Le Roux wrote:
Le 21/08/2014 07:41, Jacopo Cappellato a écrit :
On Aug 20, 2014, at 10:26 PM, Jacques Le Roux
jacques.le.r...@les7arts.com wrote:
This is one reason which would
http://www.gradle.org
What do you think?
We could write more powerful and elegant build scripts, add also have a
dependency management system. It is licensed under ASL2.0.
Jacopo
I like the auto-complete that ant XML files provide.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 8/20/2014 1:51 PM, Jacopo Cappellato wrote:
http://www.gradle.org
What do you think?
We could write more powerful and elegant build scripts, add also have a
dependency management
Hi Jacopo,
We have worked with gradle for a few months now and find it very useful! It
has convention over configuration like maven but also full power under the
hood if needed. Ant is a first class citizen in gradle and you can build on
top of existing build scripts if needed. Also lately the
Jacopo,
What scripts do you have in mind that need to be enhanced or added? Can you
outline your thoughts for each?
Replacing current ant scripts or even encasing these in another convention
means that users (both system administrators and developers) need to update
their knowledge and skills.
Making the decision about whether to do it and in which release can be
kept as 2 separate decisions.
The discussion about benefits, skill sets, technical implications is one
issue.
How will the decision be made (criteria, etc.)?
Who will investigate? What tests need to be done to prove the
Le 20/08/2014 17:26, Ron Wheeler a écrit :
Making the decision about whether to do it and in which release can be kept as
2 separate decisions.
A branch is not necessarily created to be released. It can simply be merged later in trunk when everybody agree (lazy consensus:
Le 20/08/2014 15:13, Taher Alkhateeb a écrit :
Hi Jacopo,
We have worked with gradle for a few months now and find it very useful! It
has convention over configuration like maven but also full power under the
hood if needed. Ant is a first class citizen in gradle and you can build on
top of
On Aug 20, 2014, at 10:26 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
This is one reason which would refrain me to jump right now. With of course
all the burden and especially the inherent risks of permutation.
I think that Pierre's idea of a branch is a reasonable compromise
21 matches
Mail list logo
