ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taher Alkhateeb <slidingfilame...@gmail.com>
Subject Re: Important Changes to Trunk and Use of Ant & Gradle
Date Wed, 22 Jun 2016 08:46:47 GMT
Hi Jacques,

How about we actually download all JDBC drivers automatically regardless of
the selected database. Their size is very small and it is worth making the
build script smaller no? And also anyway some people use different versions
of the database and have to change the driver version, in this case it
would be a much cleaner solution for them to go to the build script and
change the version (simple string) than to actually download the jar file
or modify the logic for the download tasks.

With that being said, thank you all for your input, I will draft the first
patch based on your feedback very soon. I will try to consolidate your
opinions as much as possible but may differ. So please take it lightly as
everything can be changed upon your request, I'm just trying to balance all
opinions and come up with something nice and clean.

Again, I really appreciate the support! I will update you soon.

On Wed, Jun 22, 2016 at 11:38 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Le 22/06/2016 à 10:05, Julien NICOLAS a écrit :
>
>>
>>
>> On 22/06/2016 09:53, Julien NICOLAS wrote:
>>
>>>
>>>
>>> On 21/06/2016 22:09, Taher Alkhateeb wrote:
>>>
>>>> - download-PG-JDBC
>>>>
>>> If it's possible, keep this one :)
>>>
>> Ok, I don't see the information of Michael that with Graddle, we don't
>> need a task for that because of the Graddle dependency functionality. So my
>> mistake, forgot it :)
>>
>
> I think you are right about this one and I believe we should keep all Ant
> JDBC driver download targets. Except if Gradle is able to infer that it
> would be possible in certain circumstances an user could need one of those
> drivers.
> This would need to parse entityengine.xml and I highly doubt this can be
> done w/o some human intervention. On the other hand if similar Gradle
> tasks  are introduced, then of course I'd not see any reasons to not drop
> them. Same for all Ant targets actually.
>
> Hope I'm clear enough :)
>
> Jacques
>
>
>>>> Second Question
>>>> -----------------------
>>>>
>>>> it seems many of the load tasks are too specific. So I suggest to only
>>>> implement loadDemo and the rest are executed manually by users, for
>>>> example: ./gradlew 'ofbiz --load-data reader=seed, seed-initial, ext'
>>>> instead of load-extseed.
>>>>
>>> I think load-seed is important as well, so if you can keep the load-seed
>>> task, it could be fine.
>>>
>>> Thanks!
>>>
>>> Julien.
>>>
>>>>
>>>> If you would like to add the other load data tasks, please specify which
>>>> ones.
>>>>
>>>> Appreciate your early responses.
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Tue, Jun 21, 2016 at 1:02 PM, Taher Alkhateeb <
>>>> slidingfilaments@gmail.com
>>>>
>>>>> wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> Thank you all for your support and kinds words. This is truly a
>>>>> wonderful
>>>>> atmosphere and I am lucky, honoured, and privileged to work with you
>>>>> all on
>>>>> this project.
>>>>>
>>>>> My patch is almost done, but definitely there is a lot of work to be
>>>>> done
>>>>> which includes the following:
>>>>> - I have one failing test out of 889 that I need to dig through, maybe
>>>>> you
>>>>> guy can help
>>>>> - I want to change / delete / add some tasks
>>>>> - Documentation needs to be updated in multiple areas
>>>>> - Testing, testing, testing, testing, testing, testing, testing,
>>>>> testing,
>>>>> testing
>>>>>
>>>>> So the plan of action is as follows:
>>>>> - I will continue the discussion on this thread for a few questions
>>>>> that I
>>>>> need an answer for.
>>>>> - I will issue a JIRA to hold the patch and everything else
>>>>>
>>>>> Please consider helping, this is something that definitely needs a
>>>>> team,
>>>>> more than one brain! If you are working on something not urgent, please
>>>>> consider dropping it for a while and jump along for help.
>>>>>
>>>>> I will post another email soon with the JIRA details and list of
>>>>> questions
>>>>> I need answer for.
>>>>>
>>>>> Again, thank you, you guys rock, I love OFBiz and this community!
>>>>>
>>>>> Regards,
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 21, 2016 at 12:49 PM, Nicolas Malin <
>>>>> nicolas.malin@nereide.fr>
>>>>> wrote:
>>>>>
>>>>> I'm in over for these technical aspects but the motivation and
>>>>>> enthusiasm
>>>>>> for many PMC and commiter tells me that seems a good way.
>>>>>>
>>>>>> So now I will learn gradle ;) and I'm in favor to realize this change
>>>>>> directly on trunk
>>>>>>
>>>>>> Thks Taher to your engine energy on this subject !
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 21/06/2016 10:43, Jacques Le Roux a écrit :
>>>>>>
>>>>>> As Gavin mentioned, Gradle can run Ant so no worries using only Gradle
>>>>>>>
>>>>>>> https://docs.gradle.org/current/userguide/ant.html
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 21/06/2016 à 09:59, Michael Brohl a écrit :
>>>>>>>
>>>>>>> I have no strong opinion for/against Gradle (I simply have no
>>>>>>>> experience with it) but I agree that it should be either
Ant or
>>>>>>>> Gradle.
>>>>>>>> Running two build tools in parallel would make it too complex
an
>>>>>>>> gain
>>>>>>>> nothing.
>>>>>>>>
>>>>>>>> I'm in favor for learning new things so Gradle sounds fine
for me
>>>>>>>> :-)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 21.06.16 um 08:11 schrieb Taher Alkhateeb:
>>>>>>>>
>>>>>>>> Hi Deepak,
>>>>>>>>>
>>>>>>>>> Ant would be removed completely for the following reasons:
>>>>>>>>>
>>>>>>>>> - First to resolve the ASF issue about the libraries
mentioned by
>>>>>>>>> Sharan
>>>>>>>>> below without expending effort on both build systems.
>>>>>>>>> - Ant is an obstacle to refactoring the framework. If
we keep both
>>>>>>>>> systems
>>>>>>>>> side by side we gain nothing, actually we lose value
because the
>>>>>>>>> builds
>>>>>>>>> become more complex. For example, we will not be able
to intrduce
>>>>>>>>> the
>>>>>>>>> unit
>>>>>>>>> tests, and we will have two build outputs, and we will
have two
>>>>>>>>> ways of
>>>>>>>>> running the framework (java -jar ofbiz.jar and gradlew
ofbiz) and
>>>>>>>>> we
>>>>>>>>> will
>>>>>>>>> have other incompatibility issues.
>>>>>>>>>
>>>>>>>>> With that being said, we will not make the switch before
a
>>>>>>>>> thorough and
>>>>>>>>> full testing. That is why we ask everyone who is willing
to please
>>>>>>>>> help us
>>>>>>>>> out to make this transition smooth by testing and providing
>>>>>>>>> feedback
>>>>>>>>> and
>>>>>>>>> comments.
>>>>>>>>>
>>>>>>>>> Taher Alkhateeb
>>>>>>>>>
>>>>>>>>> On Tuesday, 21 June 2016, Deepak Dixit <
>>>>>>>>> deepak.dixit@hotwaxsystems.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> +1 for Gradle.
>>>>>>>>>
>>>>>>>>>> Are we going to remove ant from framework completely
or planning
>>>>>>>>>> to
>>>>>>>>>> keep
>>>>>>>>>> both ant and gradle?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards
>>>>>>>>>> --
>>>>>>>>>> Deepak Dixit
>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>
>>>>>>>>>> On Mon, Jun 20, 2016 at 6:20 PM, Sharan Foga <
>>>>>>>>>> sharan.foga@gmail.com
>>>>>>>>>> <javascript:;>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Everyone
>>>>>>>>>>
>>>>>>>>>>> This is the second of two emails to inform the
community about
>>>>>>>>>>> what
>>>>>>>>>>> has
>>>>>>>>>>> been happening around how we are planning to
handle external
>>>>>>>>>>> dependencies
>>>>>>>>>>> in the trunk. Two weeks ago the community discussed
and agreed to
>>>>>>>>>>> the use
>>>>>>>>>>> of Gradle to help us put together a unit test
framework. While
>>>>>>>>>>> trying to
>>>>>>>>>>> get this set up while Ant remained as our build
tool became very
>>>>>>>>>>>
>>>>>>>>>>> difficult.
>>>>>>>>>>
>>>>>>>>>> This was because our Ant scripts:
>>>>>>>>>>>
>>>>>>>>>>>      - are massive and contain a lot of code
>>>>>>>>>>>      - are complex
>>>>>>>>>>>      - are very brittle and make it very hard
to change things
>>>>>>>>>>>      - have no dependency management
>>>>>>>>>>>      - need everything to be declared
>>>>>>>>>>>
>>>>>>>>>>> We realised very quickly that the re-factoring
issues and
>>>>>>>>>>> limitations we
>>>>>>>>>>> are facing are because of our build tool –
Ant.
>>>>>>>>>>>
>>>>>>>>>>> Ant is verbose so it needs everything to be declared.
We did a
>>>>>>>>>>> brief
>>>>>>>>>>> assessment of Maven and found it better than
Ant but not a good
>>>>>>>>>>> fit
>>>>>>>>>>> for
>>>>>>>>>>> OFBiz because it has strict requirements for
the
>>>>>>>>>>> convention-over-configuration rules to work.
Instead we decided
>>>>>>>>>>> to
>>>>>>>>>>> take a
>>>>>>>>>>> closer look at Gradle.
>>>>>>>>>>>
>>>>>>>>>>> So why Gradle?
>>>>>>>>>>> As Taher was already looking at Gradle for unit
testing, we
>>>>>>>>>>> decided
>>>>>>>>>>> to
>>>>>>>>>>> look at what we would need to do to totally replace
Ant with
>>>>>>>>>>> Gradle.
>>>>>>>>>>> We
>>>>>>>>>>> received some great support and feedback from
David, who is
>>>>>>>>>>> already
>>>>>>>>>>> using
>>>>>>>>>>> Gradle with Moqui.
>>>>>>>>>>>
>>>>>>>>>>> After some preliminary tests we found that Gradle
has some very
>>>>>>>>>>> good
>>>>>>>>>>> features such as:
>>>>>>>>>>>
>>>>>>>>>>>      - a much shorter code base (e.g. one single
file of around
>>>>>>>>>>> 250
>>>>>>>>>>> lines
>>>>>>>>>>>
>>>>>>>>>>> of
>>>>>>>>>>
>>>>>>>>>> code replaces all the build.xml files and thousands
of lines of
>>>>>>>>>>> code)
>>>>>>>>>>>      -  Programming is DSL based and links in
well with Groovy
>>>>>>>>>>> (e.g.
>>>>>>>>>>> the
>>>>>>>>>>> script is short because despite heavy custom
requirements for
>>>>>>>>>>> OFBiz,
>>>>>>>>>>> two
>>>>>>>>>>> small functions took care of the complex directory
structure)
>>>>>>>>>>>      - It handles all the external jar files
by downloading any
>>>>>>>>>>>
>>>>>>>>>>> dependencies
>>>>>>>>>>
>>>>>>>>>> directly via internet
>>>>>>>>>>>      - Jars can be upgraded by simply changing
a string
>>>>>>>>>>>      - It has matured a lot and has a high level
of support in
>>>>>>>>>>> tools,IDEs,
>>>>>>>>>>> books, documentation
>>>>>>>>>>>      - It also has a lot of plugins which means
that it works
>>>>>>>>>>> with
>>>>>>>>>>> pretty
>>>>>>>>>>> much all build systems, supports multiple programming
languages,
>>>>>>>>>>> and
>>>>>>>>>>> many
>>>>>>>>>>> other features (e.g. OSGi)
>>>>>>>>>>>
>>>>>>>>>>> We understand that it can help us make OFBiz
more modular and
>>>>>>>>>>> also
>>>>>>>>>>>
>>>>>>>>>>> setting
>>>>>>>>>>
>>>>>>>>>> up a framework for managing addons would be a lot
easier.
>>>>>>>>>>>
>>>>>>>>>>> So what's been done?
>>>>>>>>>>> Taher has been working very hard on a patch for
the trunk that
>>>>>>>>>>> completely
>>>>>>>>>>> replaces Ant with Gradle.  (Huge thanks to David
for providing
>>>>>>>>>>> some
>>>>>>>>>>>
>>>>>>>>>>> example
>>>>>>>>>>
>>>>>>>>>> scripts to help us get started!) The patch is now
ready to be
>>>>>>>>>>> applied to
>>>>>>>>>>> the trunk and includes the following:
>>>>>>>>>>>
>>>>>>>>>>>       - java -jar ofbiz.jar is now replaced with
-> gradlew
>>>>>>>>>>> 'ofbiz
>>>>>>>>>>> --whatever-options-here'
>>>>>>>>>>>       - In addition to gradlew 'ofbiz' we also
have gradlew
>>>>>>>>>>> 'ofbizDebug
>>>>>>>>>>> --whatever'. What does that mean? It means we
can run debug on
>>>>>>>>>>> ALL
>>>>>>>>>>> ofbiz
>>>>>>>>>>> commands, not just start
>>>>>>>>>>>       - If we decide to change the source directory
structure in
>>>>>>>>>>> components
>>>>>>>>>>> say from /src to /src/main, it would literally
be a change of 5
>>>>>>>>>>>
>>>>>>>>>>> characters
>>>>>>>>>>
>>>>>>>>>> in the build script
>>>>>>>>>>>       - We can immediately move all jar files
if we want to a
>>>>>>>>>>> unified
>>>>>>>>>>> location in /lib for example
>>>>>>>>>>>       - We can delete most of the jars and declare
them as
>>>>>>>>>>> dependencies
>>>>>>>>>>> saving space and resources
>>>>>>>>>>>       - We can automate the creation of the .classpath
file so
>>>>>>>>>>> when we
>>>>>>>>>>> update libraries no need to do this manually
(under development)
>>>>>>>>>>>       - We can ignore components that are not
define in the xml
>>>>>>>>>>> files
>>>>>>>>>>> for
>>>>>>>>>>> loading (under development)
>>>>>>>>>>>       - We can introduce unit tests with about
10 minutes of work
>>>>>>>>>>>
>>>>>>>>>>> We are finding that the flexibility and control
we are getting
>>>>>>>>>>> with
>>>>>>>>>>>
>>>>>>>>>>> Gradle
>>>>>>>>>>
>>>>>>>>>> is truly amazing. We know that Gradle will be a major
change to
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>> project
>>>>>>>>>>
>>>>>>>>>> but we think that it will significantly improve the
project by
>>>>>>>>>>> removing a
>>>>>>>>>>> lot of build complexity and take care of that
essential
>>>>>>>>>>> dependency
>>>>>>>>>>> management that we need to comply with.
>>>>>>>>>>>
>>>>>>>>>>> Our next steps will be to apply the patch to
the trunk and then
>>>>>>>>>>> continue
>>>>>>>>>>> the re-factoring work. We will need to organise
some knowledge
>>>>>>>>>>> transfer
>>>>>>>>>>>
>>>>>>>>>>> so
>>>>>>>>>>
>>>>>>>>>> that all our committers understand what the changes
are and how
>>>>>>>>>>> they
>>>>>>>>>>>
>>>>>>>>>>> would
>>>>>>>>>>
>>>>>>>>>> need to work in the future.
>>>>>>>>>>>
>>>>>>>>>>> The PMC are very, very excited about having Gradle
as part of
>>>>>>>>>>> future
>>>>>>>>>>> of
>>>>>>>>>>> OFBiz and we hope that the community will think
so too. As
>>>>>>>>>>> always,
>>>>>>>>>>>
>>>>>>>>>>> feedback
>>>>>>>>>>
>>>>>>>>>> welcome.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Sharan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message