Re: [Mifos-developer] [OPENMRS-DEV] Maven omod plugin and OpenMRS build
Adam Monsen
I agree, the dependency management is fantastic. Working with Java
libraries is complex, and Maven totally nails this. There are myriad
packages available which Maven will automatically pull down. Other bits
I like:
* if you follow the conventions (which mainly means just placing
files in the directories Maven recognizes), many plugins "just
work"
* site creation, JSP compression, embedded containers like
Jetty, package (JAR/WAR/EAR/etc.) creation
* writing your own Maven plugins is straightforward and fun
* 3rd-party integrations are excellent
* continuous integration uh, integration (Hudson knows
what to do with Maven projects)
* IDE integration, especially for discovering dependencies
* the source code is easy to read, even easier than the
documentation in some cases
* the procedural grunt work of building software (ie: Ant!) is no
longer necessary
* sharing and deploying your code is second nature ("mvn clean
install", the standard way to build, creates a sharable library
by default)
Drawbacks:
* Maven is complex: the conventions can be difficult to figure out
* ditching the procedural approach takes some getting used to
* profiles are confusing and difficult to get right
* Maven (at least 2.0.9) is slow
* Maven 3 is supposedly faster
* be prepared for even more XML situps than when you used Ant
* look for the experimental "polyglot" library for Maven
3, allowing the use of YAML/Groovy/whatever for POM data
Overall? Maven is a huge win for us. We now have our code in standard
directories, built code _only_ ends up in "target" directories, Hudson
loves Maven, and we have a clear path towards modularization.
On Thu, 2009-11-19 at 09:23 -0800, Adam Feuer wrote:
> Aliya,
>
> The switch to maven was challenging, but extremely helpful. It has
> accelerated our development and made it easy to change our software. In
> particular maven's dependency management system is great.
>
> Maven's "worldview" is quite different from ant, and just like any large
> software it has quirks and bugs. These things take an investment of time to
> get ones' head around. It's worth it though.
>
>
> On 11/18/09 22:54 , Aliya Walji wrote:
>
> >
> > Hey Guys,
> >
> > I¹m just curious, when you made your switch from ant to maven for Mifos, was
> > it challenging or painful? Was it difficult for new developers to grasp or
> > was the barrier relatively low for learning how to use Maven? I¹m curious
> > because Ben from the OpenMRS team has seemed to say a few times things along
> > the lines of ³it makes my head hurt² when he¹s had to use it, however the
> > developers my current project, MoTeCH, seemed to think otherwise. They feel
> > like it would be a valuable transition for the OpenMRS team to make. I wanted
> > to get a sense from you guys about your experiences about the learning curve
> > and whether it¹s worth the benefits of using Maven (and maybe share those with
> > the OpenMRS team, if relevant).
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Matthew Blanchette
> > Date: 2009/11/17
> > Subject: Re: [OPENMRS-DEV] Maven omod plugin and OpenMRS build
> > To: openmrs...@listserv.iupui.edu
> >
> >
> > I would say this has been successful for both our omod and the OpenMRS build.
> >
> > To be able to have Maven omod projects use the OpenMRS core artifacts,
> > there just needs to be a Maven repository with them installed. Right
> > now, we manually installed the artifacts we needed in our Archiva
> > repository. For the OpenMRS build, this included installing the
> > modified libraries (like Hibernate). For our omod project, this
> > included the Ant built OpenMRS libraries. Ideally with a Maven OpenMRS
> > build, the core OpenMRS artifacts would be built by the CI server and
> > deployed to its Maven repository (we've done this for our omod project
> > with Continuum and Archiva).
> >
> > Ideally for omod developers, there would be an initial omod Maven
> > project (or even a Maven archetype), which includes the omod plugin,
> > OpenMRS core artifacts, and initial files and directory (functioning
> > much like the basicmodule Ant starter project).
> >
> > Reorganizing the directory structure wasn't really a problem, it was
> > just moving files to fit the Maven conventions.
> > The largest problem was the tests, first determining dependencies and
> > then running them during the build.
> >
> > Normally tests for a Maven module would be in that module, for
> > instance tests for the core api would be in the core Maven module.
> > Since some of the core tests depend on the web api (due to Spring
> > classpath scanning), all tests (core and web) were moved into their
> > own Maven module.
> >
> > Tests seem to be affected by the order they run in. Maven normally
> > runs all tests in a module together, in no particular order. Our Maven
> > builds run and interweave different test types causing a Hibernate
> > session exception. For example, running a BaseContextSensitiveTest
> > between two BaseModuleContextSensitiveTest tests. I worked around this
> > in the main OpenMRS build by running the tests in the tests Maven
> > module separately, first the core api tests and then the web api
> > tests. The major concern here is test isolation.
> >
> > I've only been seriously working with Maven since we started this
> > project (roughly 7 months). While there is some overhead to learning
> > its conventions, once you have them, it just makes sense and makes
> > managing development a lot easier.
> > I think for new omod developers, Maven would definitely help. For
> > existing OpenMRS developers, it will be an adjustment to get
> > comfortable with the Maven practices.
> >
> > I use the Maven site, which has great documentation (especially the
> > POM Reference):
> > http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
> > There is also the Definitive Guide Book:
> > http://www.sonatype.com/products/maven/documentation/book-defguide
> >
> > -Matt
> >
> >
> > On Tue, Nov 17, 2009 at 10:38 AM, Ben Wolfe <bwo...@regenstrief.org> wrote:
> >> Very cool Matt! How is this working out for your modules and with core?
> >> Any hiccups?
> >>
> >> I am pretty sick of some of the manual dependency copying, multiple jars,
> >> etc between modules and core. There has been a ticket for Ivy for a while
> >> to solve this (and to keep us with the simple-to-use ant). Using would
> >> replace the need for Ivy.
> >> http://dev.openmrs.org/ticket/1130
> >>
> >> The biggest win would be to have modules and the module-plugin use the
> >> openmrs core artifacts (openmrs-1.5.jar) automatically. You say that the
> >> plugin isn't doing that yet though. Is there a way to do that easily, or is
> >> that a lot more work?
> >>
> >> It looks like there are some pretty big modifications that you did:
> >> https://motech.rcg.usm.maine.edu/redmine/wiki/openmrs-maven/Usage#Changes-for
> >> -Maven-Build
> >> Namely:
> >> 1) reorganized folder structure
> >> 2) removed tests to separate module (I'm assuming this is maven module and
> >> not openmrs module)
> >>
> >> Maven makes my head hurt whenever I have to use it in other projects. Is
> >> there a maven-for-dummies guide that you like to use? Or if we were to
> >> incorporate this into openmrs, is there a way we could make this easier than
> >> the typical maven for a new-comer?
> >>
> >> Ben
> >>
> >> Matt Blanchette wrote:
> >>>
> >>> Hello everyone,
> >>>
> >>> I'm working with Bruce MacLeod and Brent Atkinson on the MoTECH project
> >>> (Bruce previously introduced us in the forum).
> >>>
> >>> We're using Maven for development of our OpenMRS module for the project.
> >>> I've seen some discussions about Maven in the past and wanted to bring up
> >>> our use of it with OpenMRS and get some feedback.
> >>>
> >>> Maven Plugin for OpenMRS Module:
> >>>
> >>> Brent has developed an OpenMRS module (omod) Maven Plugin for use in our
> >>> project. The main purpose is to build an artifact with the omod extension
> >>> when the
> >>> project packaging is omod. Other actions provided by the plugin include:
> >>> * Automatically includes compile or runtime scoped dependencies (and their
> >>> transitive dependencies) in the omod lib folder.
> >>> * Provides means to automatically manage list of hibernate mapping files
> >>> for
> >>> use in config.xml and hibernate configuration.
> >>> * Verifies the structure of omod based on the config.xml file. This plugin
> >>> is still in development and is currently hosted in our Apache
> >>> Archiva repository.
> >>> Here is the generated site for the project:
> >>> http://motech.rcg.usm.maine.edu/projects/maven-openmrs-plugin/
> >>> http://motech.rcg.usm.maine.edu/projects/maven-openmrs-plugin/
> >>> Maven Build of OpenMRS:
> >>>
> >>> I have setup a Maven build of OpenMRS 1.5.0, starting from the tagged
> >>> release. The main purpose of this build was to explore the possibility of
> >>> a Maven
> >>> build for OpenMRS and to also better understand the dependencies and their
> >>> versions. We are not using this build or its artifacts for our module
> >>> project. The
> >>> OpenMRS artifacts used in our module project were built using the Ant
> >>> build
> >>> and installed in our Archiva repository. This Wiki provides example usages
> >>> and also reasons for the changes:
> >>> https://motech.rcg.usm.maine.edu/redmine/wiki/openmrs-maven/Usage
> >>> https://motech.rcg.usm.maine.edu/redmine/wiki/openmrs-maven/Usage
> >>> Thanks,
> >>>
> >>> Matt Blanchette
Krishnan M
Anyone have any thoughts for when Maven is *NOT* the right choice...i am having to do something on a project that uses Google Web Toolkit, Spring, and Hibernate, and its a real pain with Maven taking a half hour to compile every time we make a one-line change to any of the classes.
Its only been a few days working with this code, but it looks like 99% of the half hour is spent compiling GWT code that wasn't even changed or impacted in any other way. Perhaps the way things are setup are not quite right (separate projects may be needed for different parts of the app and i have yet to post a similar post to GWT or Maven forums), but when i read this post, i can't help but agree "it makes my head hurt"...
regards,
|
-----Inline Attachment Follows----- |
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
Adam Monsen
> i am having to do something on a project that uses Google Web Toolkit,
> Spring, and Hibernate, and its a real pain with Maven taking a half
> hour to compile every time we make a one-line change to any of the classes.
This is a great question for a Maven or GWT mailing list.