Maven vs Gradle.
Locked
|
Hi All,
Over this week (along with the earlier maven) I was able to integrate a relatively new system gradle (http://gradle.org) as well. Integrating gradle did not prove out to be tough because gradle understands the maven (or standard) directory layout.
The build files for both maven and gradle and available at the git hub repository Please note there are some dependencies still missing from the gradle files so test cases don't run successfully. Compilation and packaging works. you can give gradle a spin by
$ gradle compile -Dskip.test Here are some points we should consider. Maven pros * Lots of third party plugins for tasks * Fairly robust IDE support (eclipse, netbeans, intellij)
* Dependency management * Jetty plugin (you can run the web app off the compiled source with hot deployment) Maven cons * XML based configuration. which usually ends up being very verbose.
* Writing simple and custom tasks (for instance copy a set of files somewhere) is tedious. You have to write a plugin and testing + development time for simple tasks may end up too long and time consuming.
For things to go smooth you usually will have to follow maven conventions and standard plugins.
* Everything is a plugin. Even simple tasks like compile and running tests. So for a fresh project, downloading all the plugins takes considerable time. Plus there might be updates to the plugin which will be downloaded occasionally when you run the build.
* Lots of maven plugins usually have problems and a general opinion is that it is hard to debug. * Building is slow compared to ant and gradle * Does not prepare the html unit test case report by default (but something called a surefire reports)
Gradle (pros) * Based on groovy. Scripting tasks are quite coz it is in a programming language. * Uses ivy dependency management (which uses maven repositories). Dependency downloads are quite fast.
* Integrates ant tasks also. * Supports the standard directory layout. So for compilation, testing and packaging no extra tasks need to be written as long the files are in the layout.
* Come bundles with a default set of plugins which are core to gradle. So it does not have to download/update plugins * Builds are quite fast. * Standard junit reports * Supports jetty server
Gradle (cons) * IDE support or the lack of it. Eclipse does not come with good support for gradle or groovy. Intellij idea and netbeans supports it (idea supports gradle projects) however.
* Third party plugin support is not as good as maven On the whole gradle looks better. If we were to carry out the migrations gradle will prove easier to migrate the current ant tasks, while we have to write plugins for maven to get things working.
Cheers, Zabil
[hidden email] from OpenMRS Developers' mailing list |
|
|
Zabil
I apologize for the long overdue reply. So if you're promoting Gradle, can we see a setup with it on openmrs? Perhaps a new branch to make all the necessary changes? See http://openmrs.org/wiki/Developers#Requesting_Subversion_Repository_Access for the "steps" on how to request the branch space. Then a quick step-by-step for how we devs could play around with it and we can actually see it and try things out. Ben On Thu, 2010-02-04 at 00:32 -0500, Zabil C.M wrote: > Hi All, > Over this week (along with the earlier maven) I was able to integrate > a relatively new system gradle (http://gradle.org) as well. > Integrating gradle did not prove out to be tough because gradle > understands the maven (or standard) directory layout. > The build files for both maven and gradle and available at the git > hub repository > > > http://github.com/zabil/openmrs > > > Please note there are some dependencies still missing from the > gradle files so test cases don't run successfully. Compilation and > packaging works. you can give gradle a spin by > $ gradle compile -Dskip.test > > > Here are some points we should consider. > > Maven pros > * Lots of third party plugins for tasks > * Fairly robust IDE support (eclipse, netbeans, intellij) > * Dependency management > * Jetty plugin (you can run the web app off the compiled source with > hot deployment) > > > Maven cons > * XML based configuration. which usually ends up being very verbose. > * Writing simple and custom tasks (for instance copy a set of files > somewhere) is tedious. > You have to write a plugin and testing + development time for > simple tasks may end up too long and time consuming. > For things to go smooth you usually will have to follow maven > conventions and standard plugins. > * Everything is a plugin. Even simple tasks like compile and running > tests. > So for a fresh project, downloading all the plugins takes > considerable time. > Plus there might be updates to the plugin which will be downloaded > occasionally when you run the build. > * Lots of maven plugins usually have problems and a general opinion > is that it is hard to debug. > * Building is slow compared to ant and gradle > * Does not prepare the html unit test case report by default (but > something called a surefire reports) > > > Gradle (pros) > * Based on groovy. Scripting tasks are quite coz it is in a > programming language. > * Uses ivy dependency management (which uses maven repositories). > Dependency downloads are quite fast. > * Integrates ant tasks also. > * Supports the standard directory layout. > So for compilation, testing and packaging no extra tasks need to be > written as long the files are in the layout. > * Come bundles with a default set of plugins which are core to > gradle. So it does not have to download/update plugins > * Builds are quite fast. > * Standard junit reports > * Supports jetty server > > > Gradle (cons) > * IDE support or the lack of it. Eclipse does not come with good > support for gradle or groovy. > Intellij idea and netbeans supports it (idea supports gradle > projects) however. > * Third party plugin support is not as good as maven > > On the whole gradle looks better. If we were to carry out the > migrations gradle will prove easier to migrate the current ant tasks, > while we have to write plugins for maven to get things working. > > > Cheers, > Zabil > > ______________________________________________________________________ > Click here to unsubscribe from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l] |
|
|
Hi All,
I followed on Zabil's work. I am not familiar with Gradle but I have some experience with Maven. Here is what I have done so far 1. Can build both api and web modules and generate artifacts. 2. Can run all tests and there is only one test failed. 3. Can run openmrs under jetty. However there are a few issues I have encountered as well. 1. ModuleInteroperabilityTest class has dependency on web module. The Circular dependency is introduced by one of these modules: atd-0.51.omod, logic-0.2.omod or dssmodule-1.44.omod. The missing class is org.openmrs.module.web.extensionAdministrationSectionExt.class. 2. hibernate.jar 3.2.5.ga is patched. 3. simple-xml.jar 1.6.1 is patched. 4. hlapi-0.5.jar doesn't exist in central repository 5. liquidbase-1.9.4 is patched. 6. CreateCoreUuids is not a test but extends from BaseContextSensitiveTest. If I use Intellij to scan all test classes, This class will be picked which will fail eventually. A possible solution for issue 2 to 5 is to set up our own repository so that developers don't have to manually install these jars in their own local repository. If you are interested, I will proceed to set up a branch. By the way, I was using Revision 12391. Fred On Wed, Mar 10, 2010 at 2:14 PM, Ben Wolfe <[hidden email]> wrote: > Zabil > > I apologize for the long overdue reply. So if you're promoting Gradle, > can we see a setup with it on openmrs? > > Perhaps a new branch to make all the necessary changes? See > http://openmrs.org/wiki/Developers#Requesting_Subversion_Repository_Access for the "steps" on how to request the branch space. > > Then a quick step-by-step for how we devs could play around with it and > we can actually see it and try things out. > > Ben > > On Thu, 2010-02-04 at 00:32 -0500, Zabil C.M wrote: >> Hi All, >> Over this week (along with the earlier maven) I was able to integrate >> a relatively new system gradle (http://gradle.org) as well. >> Integrating gradle did not prove out to be tough because gradle >> understands the maven (or standard) directory layout. >> The build files for both maven and gradle and available at the git >> hub repository >> >> >> http://github.com/zabil/openmrs >> >> >> Please note there are some dependencies still missing from the >> gradle files so test cases don't run successfully. Compilation and >> packaging works. you can give gradle a spin by >> $ gradle compile -Dskip.test >> >> >> Here are some points we should consider. >> >> Maven pros >> * Lots of third party plugins for tasks >> * Fairly robust IDE support (eclipse, netbeans, intellij) >> * Dependency management >> * Jetty plugin (you can run the web app off the compiled source with >> hot deployment) >> >> >> Maven cons >> * XML based configuration. which usually ends up being very verbose. >> * Writing simple and custom tasks (for instance copy a set of files >> somewhere) is tedious. >> You have to write a plugin and testing + development time for >> simple tasks may end up too long and time consuming. >> For things to go smooth you usually will have to follow maven >> conventions and standard plugins. >> * Everything is a plugin. Even simple tasks like compile and running >> tests. >> So for a fresh project, downloading all the plugins takes >> considerable time. >> Plus there might be updates to the plugin which will be downloaded >> occasionally when you run the build. >> * Lots of maven plugins usually have problems and a general opinion >> is that it is hard to debug. >> * Building is slow compared to ant and gradle >> * Does not prepare the html unit test case report by default (but >> something called a surefire reports) >> >> >> Gradle (pros) >> * Based on groovy. Scripting tasks are quite coz it is in a >> programming language. >> * Uses ivy dependency management (which uses maven repositories). >> Dependency downloads are quite fast. >> * Integrates ant tasks also. >> * Supports the standard directory layout. >> So for compilation, testing and packaging no extra tasks need to be >> written as long the files are in the layout. >> * Come bundles with a default set of plugins which are core to >> gradle. So it does not have to download/update plugins >> * Builds are quite fast. >> * Standard junit reports >> * Supports jetty server >> >> >> Gradle (cons) >> * IDE support or the lack of it. Eclipse does not come with good >> support for gradle or groovy. >> Intellij idea and netbeans supports it (idea supports gradle >> projects) however. >> * Third party plugin support is not as good as maven >> >> On the whole gradle looks better. If we were to carry out the >> migrations gradle will prove easier to migrate the current ant tasks, >> while we have to write plugins for maven to get things working. >> >> >> Cheers, >> Zabil >> >> ______________________________________________________________________ >> Click here to unsubscribe from OpenMRS Developers' mailing list > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. > > [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l] > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l] |
 
|
Nyoman Ribeka |
Re: Maven vs Gradle.
|
|
I will vote +1 on moving forward on this one. I use Maven a while back
and really love them. I know the setting up is kinda pain but once you set everything up, we just need to do mvn install or mvn eclipse:eclipse. I think once you have something that can be shown to the community, everyone will be very excited Fred :) Looking forward to see the work on this. On 03/11/2010 08:48 PM, Fred Chen wrote: > Hi All, > > I followed on Zabil's work. I am not familiar with Gradle but I have > some experience with Maven. Here is what I have done so far > > 1. Can build both api and web modules and generate artifacts. > 2. Can run all tests and there is only one test failed. > 3. Can run openmrs under jetty. > > However there are a few issues I have encountered as well. > 1. ModuleInteroperabilityTest class has dependency on web module. The > Circular dependency is introduced by one of these modules: > atd-0.51.omod, logic-0.2.omod or dssmodule-1.44.omod. The missing > class is org.openmrs.module.web.extensionAdministrationSectionExt.class. > > 2. hibernate.jar 3.2.5.ga is patched. > 3. simple-xml.jar 1.6.1 is patched. > 4. hlapi-0.5.jar doesn't exist in central repository > 5. liquidbase-1.9.4 is patched. > > 6. CreateCoreUuids is not a test but extends from > BaseContextSensitiveTest. If I use Intellij to scan all test classes, > This class will be picked which will fail eventually. > > A possible solution for issue 2 to 5 is to set up our own repository > so that developers don't have to manually install these jars in their > own local repository. > > If you are interested, I will proceed to set up a branch. By the way, > I was using Revision 12391. > > Fred > > > > On Wed, Mar 10, 2010 at 2:14 PM, Ben Wolfe<[hidden email]> wrote: >> Zabil >> >> I apologize for the long overdue reply. So if you're promoting Gradle, >> can we see a setup with it on openmrs? >> >> Perhaps a new branch to make all the necessary changes? See >> http://openmrs.org/wiki/Developers#Requesting_Subversion_Repository_Access for the "steps" on how to request the branch space. >> >> Then a quick step-by-step for how we devs could play around with it and >> we can actually see it and try things out. >> >> Ben >> >> On Thu, 2010-02-04 at 00:32 -0500, Zabil C.M wrote: >>> Hi All, >>> Over this week (along with the earlier maven) I was able to integrate >>> a relatively new system gradle (http://gradle.org) as well. >>> Integrating gradle did not prove out to be tough because gradle >>> understands the maven (or standard) directory layout. >>> The build files for both maven and gradle and available at the git >>> hub repository >>> >>> >>> http://github.com/zabil/openmrs >>> >>> >>> Please note there are some dependencies still missing from the >>> gradle files so test cases don't run successfully. Compilation and >>> packaging works. you can give gradle a spin by >>> $ gradle compile -Dskip.test >>> >>> >>> Here are some points we should consider. >>> >>> Maven pros >>> * Lots of third party plugins for tasks >>> * Fairly robust IDE support (eclipse, netbeans, intellij) >>> * Dependency management >>> * Jetty plugin (you can run the web app off the compiled source with >>> hot deployment) >>> >>> >>> Maven cons >>> * XML based configuration. which usually ends up being very verbose. >>> * Writing simple and custom tasks (for instance copy a set of files >>> somewhere) is tedious. >>> You have to write a plugin and testing + development time for >>> simple tasks may end up too long and time consuming. >>> For things to go smooth you usually will have to follow maven >>> conventions and standard plugins. >>> * Everything is a plugin. Even simple tasks like compile and running >>> tests. >>> So for a fresh project, downloading all the plugins takes >>> considerable time. >>> Plus there might be updates to the plugin which will be downloaded >>> occasionally when you run the build. >>> * Lots of maven plugins usually have problems and a general opinion >>> is that it is hard to debug. >>> * Building is slow compared to ant and gradle >>> * Does not prepare the html unit test case report by default (but >>> something called a surefire reports) >>> >>> >>> Gradle (pros) >>> * Based on groovy. Scripting tasks are quite coz it is in a >>> programming language. >>> * Uses ivy dependency management (which uses maven repositories). >>> Dependency downloads are quite fast. >>> * Integrates ant tasks also. >>> * Supports the standard directory layout. >>> So for compilation, testing and packaging no extra tasks need to be >>> written as long the files are in the layout. >>> * Come bundles with a default set of plugins which are core to >>> gradle. So it does not have to download/update plugins >>> * Builds are quite fast. >>> * Standard junit reports >>> * Supports jetty server >>> >>> >>> Gradle (cons) >>> * IDE support or the lack of it. Eclipse does not come with good >>> support for gradle or groovy. >>> Intellij idea and netbeans supports it (idea supports gradle >>> projects) however. >>> * Third party plugin support is not as good as maven >>> >>> On the whole gradle looks better. If we were to carry out the >>> migrations gradle will prove easier to migrate the current ant tasks, >>> while we have to write plugins for maven to get things working. >>> >>> >>> Cheers, >>> Zabil >>> >>> ______________________________________________________________________ >>> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> _________________________________________ >> >> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. >> >> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l] >> > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. > > [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l] -- Thanks, Nyoman Ribeka _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l] |
|
Matt Blanchette |
Re: Maven vs Gradle.
|
|
In reply to this post by Fred Chen
Hey Zabil and Fred,
I definitely think it would be good to work together and setup a branch and a Maven repository. I've posted this in another thread, but I'll post it here as well. I previously setup a Maven project for OpenMRS 1.5.0 and was planning to update it to 1.6 after the release. We have a Maven repository we use for our OpenMRS module development that I used to provide the modified libraries you referenced (2-5). We are using Archiva with Continuum. Here is a wiki with details: https://motech.rcg.usm.maine.edu/redmine/wiki/openmrs-maven -Matt On Thu, Mar 11, 2010 at 8:48 PM, Fred Chen <[hidden email]> wrote: > Hi All, > > I followed on Zabil's work. I am not familiar with Gradle but I have > some experience with Maven. Here is what I have done so far > > 1. Can build both api and web modules and generate artifacts. > 2. Can run all tests and there is only one test failed. > 3. Can run openmrs under jetty. > > However there are a few issues I have encountered as well. > 1. ModuleInteroperabilityTest class has dependency on web module. The > Circular dependency is introduced by one of these modules: > atd-0.51.omod, logic-0.2.omod or dssmodule-1.44.omod. The missing > class is org.openmrs.module.web.extensionAdministrationSectionExt.class. > > 2. hibernate.jar 3.2.5.ga is patched. > 3. simple-xml.jar 1.6.1 is patched. > 4. hlapi-0.5.jar doesn't exist in central repository > 5. liquidbase-1.9.4 is patched. > > 6. CreateCoreUuids is not a test but extends from > BaseContextSensitiveTest. If I use Intellij to scan all test classes, > This class will be picked which will fail eventually. > > A possible solution for issue 2 to 5 is to set up our own repository > so that developers don't have to manually install these jars in their > own local repository. > > If you are interested, I will proceed to set up a branch. By the way, > I was using Revision 12391. > > Fred > > > > On Wed, Mar 10, 2010 at 2:14 PM, Ben Wolfe <[hidden email]> wrote: >> Zabil >> >> I apologize for the long overdue reply. So if you're promoting Gradle, >> can we see a setup with it on openmrs? >> >> Perhaps a new branch to make all the necessary changes? See >> http://openmrs.org/wiki/Developers#Requesting_Subversion_Repository_Access for the "steps" on how to request the branch space. >> >> Then a quick step-by-step for how we devs could play around with it and >> we can actually see it and try things out. >> >> Ben >> >> On Thu, 2010-02-04 at 00:32 -0500, Zabil C.M wrote: >>> Hi All, >>> Over this week (along with the earlier maven) I was able to integrate >>> a relatively new system gradle (http://gradle.org) as well. >>> Integrating gradle did not prove out to be tough because gradle >>> understands the maven (or standard) directory layout. >>> The build files for both maven and gradle and available at the git >>> hub repository >>> >>> >>> http://github.com/zabil/openmrs >>> >>> >>> Please note there are some dependencies still missing from the >>> gradle files so test cases don't run successfully. Compilation and >>> packaging works. you can give gradle a spin by >>> $ gradle compile -Dskip.test >>> >>> >>> Here are some points we should consider. >>> >>> Maven pros >>> * Lots of third party plugins for tasks >>> * Fairly robust IDE support (eclipse, netbeans, intellij) >>> * Dependency management >>> * Jetty plugin (you can run the web app off the compiled source with >>> hot deployment) >>> >>> >>> Maven cons >>> * XML based configuration. which usually ends up being very verbose. >>> * Writing simple and custom tasks (for instance copy a set of files >>> somewhere) is tedious. >>> You have to write a plugin and testing + development time for >>> simple tasks may end up too long and time consuming. >>> For things to go smooth you usually will have to follow maven >>> conventions and standard plugins. >>> * Everything is a plugin. Even simple tasks like compile and running >>> tests. >>> So for a fresh project, downloading all the plugins takes >>> considerable time. >>> Plus there might be updates to the plugin which will be downloaded >>> occasionally when you run the build. >>> * Lots of maven plugins usually have problems and a general opinion >>> is that it is hard to debug. >>> * Building is slow compared to ant and gradle >>> * Does not prepare the html unit test case report by default (but >>> something called a surefire reports) >>> >>> >>> Gradle (pros) >>> * Based on groovy. Scripting tasks are quite coz it is in a >>> programming language. >>> * Uses ivy dependency management (which uses maven repositories). >>> Dependency downloads are quite fast. >>> * Integrates ant tasks also. >>> * Supports the standard directory layout. >>> So for compilation, testing and packaging no extra tasks need to be >>> written as long the files are in the layout. >>> * Come bundles with a default set of plugins which are core to >>> gradle. So it does not have to download/update plugins >>> * Builds are quite fast. >>> * Standard junit reports >>> * Supports jetty server >>> >>> >>> Gradle (cons) >>> * IDE support or the lack of it. Eclipse does not come with good >>> support for gradle or groovy. >>> Intellij idea and netbeans supports it (idea supports gradle >>> projects) however. >>> * Third party plugin support is not as good as maven >>> >>> On the whole gradle looks better. If we were to carry out the >>> migrations gradle will prove easier to migrate the current ant tasks, >>> while we have to write plugins for maven to get things working. >>> >>> >>> Cheers, >>> Zabil >>> >>> ______________________________________________________________________ >>> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> _________________________________________ >> >> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. >> >> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l] >> > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. > > [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l] > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l] |
|
|
Yeah Matt we could set up archiva (http://archiva.apache.org/) to get over the problems of custom/patched jar files that Fred has pointed out.
I have set up gradle build files at http://github.com/zabil/openmrs . As of now it just compiles. But somehow the more i have used gradle i have faced bigger problems on it that maven on dependency resolution, running the jetty server etc.
Also adding to what Fred mentioned there are some tasks in the current build files we need to look at porting to maven like arden tasks tomcat tasks hl7-test I think we should get started by setting up a branch of 1.6 and doing the whole maven exercise. Zabil On Fri, Mar 12, 2010 at 7:40 AM, Matthew Blanchette <[hidden email]> wrote: Hey Zabil and Fred, [hidden email] from OpenMRS Developers' mailing list |
«
Return to Developers
|
1 view|%1 views
Loading...
| Powered by Nabble | See how NAML generates this page |
