Re: Using WO with modern dependency management
Re: Using WO with modern dependency management
- Subject: Re: Using WO with modern dependency management
- From: Faizel Dakri <email@hidden>
- Date: Wed, 06 May 2015 02:47:59 -0500
Accidentally hit send too soon…
In defense of Maven, I don’t think you have to be an expert, but you do have to be willing to give in to the maven way of doing things and go the whole hog (for me, that also meant abandoning Fluffy Bunny and adopting the maven layout, something I actually had no problem with). I currently have a development environment built on maven that I’m happy with. It took a little while to get my head around maven and lots of reading and re-reading the wiki and the Wonder POMs (thanks to all that contributed), but it is now a relatively predictable environment. I don’t know if what I’m doing is the ideal way of doing things, but it does work well for me. There are a couple of idiosyncrasies to deal with, but nothing serious. Granted, I haven’t yet had to deal with the maven deployment end of things (e.g. incrementing version numbers) for a production rollout, but I’m pretty confident that I’ll be able to jump that hurdle when the time comes.
What I like:
- quickly adding a new library by adding a dependency to a POM file
- overriding a Wonder dependency in a local POM file
- building a true war that I can test with “mvn jetty:run-war”
- creating a fully contained war file with static resources bundled (via a custom assembly)
Stumbling blocks I encountered:
- initial setup
- creating projects using the m2e plugin
- launching from within Eclipse
- embedding all resources in the final product
For the initial setup, once I got the right settings.xml [1] and archetype-catalog.xml [2] installed in my local repo things ran much more smoothly. I also ended up installing Maven 3, although I initially started with Maven 2. For the archetype-catalog.xml, I pruned it so that it only had the version 2.1 archetypes. After that, I setup a launch configuration following the wiki instructions [3]. For my project repo, I ended up with the following structure (I follow the Wonder style where my repo contains many frameworks and apps):
project_root/
pom.xml
frameworks/
pom.xml
framework1/
pom.xml
framework2/
pom.xml
applications
pom.xml
app1/
pom.xml
app2/
pom.xml
In this layout, dependencies are declared in the root POM, including version info (this allows me to control which versions of which libraries are used), along with any properties that are to be pushed to child POMs. All lower-level POMs are descendants of the root POM (in a parent-child hierarchy). This is directly inspired by the way the Wonder POMs are structured. Most of the complexity is in the root POM and in the frameworks/pom.xml and applications/pom.xml (through pluginManagement and dependencyManagement sections). The individual app and framework POMs are pretty simple and are basically just dependency declarations (versions are inherited from the root POM by default) plus some workarounds for flattening resources, which is one of the idiosyncrasies I was referring to. Using this setup, it has become trivial to try out new libraries by declaring the full dependency coordinate in the root POM and then just referring to it in the specific project that needs it.
I still do my development in Eclipse/WOLips running with direct connect and then deploy to Tomcat (running behind Apache) when I’m ready to test by just copying over a single war file. Again, this is just in my development environment—I haven’t yet attempted a full production install—and there is some runtime hackery going on to use the appropriate context class depending on whether or not we’re running in a servlet. One of the shortcomings that I’ve encountered is that I do have to do some setup for my launch configurations to set up the build path when running in Eclipse, but this is a one-time thing and is addressed in the wiki [3].
To package the war file for Tomcat, I use a custom assembly that takes static resources and adds them to the war file, but this was pretty trivial to create (basically just some xml files, packaged as a maven project), however the assembly does make some assumptions about which Wonder frameworks have static resources that are to be bundled (more for my convenience) and does require me to declare which of my frameworks need to have their static resource dependencies bundled. I would like to improve on the assembly by expanding the resources before the war file is created, but for now it involves manipulating the war file after the fact, which does take a non-trivial amount of time. However, it does work and it is extremely satisfying to see a single file with all of my classes, dynamic and static resources (static resources are served by Tomcat, not Apache).
F
[1] https://wiki.wocommunity.org/download/attachments/2623477/settings.xml?version=2&modificationDate=1239236585000&api=v2
[2] http://maven.wocommunity.org/content/groups/public/archetype-catalog.xml
[3] https://wiki.wocommunity.org/display/documentation/Maven+Running+or+Debugging+as+WO+Application
--
Faizel Dakri
email@hidden
> On 2015-May-04, at 11:43 AM, Chuck Hill <email@hidden> wrote:
>
> I think that “Maven expert” is the key here. This is not a trivial thing to setup correctly and maintain. It is trivial to setup and use incorrectly and I have seen the pain resulting from that. To benefit from Maven you need to really deeply understand Maven and its approach to dependancy management. And you need to ensure that the whole team plays by The Maven Rules, even if it makes more work short term and a bit of cheating does not seem that bad at the moment.
>
> Chuck
>
>
>
> On 2015-05-04, 8:29 AM, "Jean-François Veillette" wrote:
>
> At my previous workplace, we did the switch to Maven. Luckily we had a real maven expert to drive the move.
> We started with around 50+ projects, all ant based, using the ‘standard’ fluffy-bunny layout. He added pom.xml here and there, and everything just started working with maven. We had choice to build/run with maven and/or ant and it was (almost) transparent. The only exception was that if you decided to use in maven, you had to change the class path to remove everything but the maven and java dependencies (2 lines left), a simple .classpath that was standard and could be copied from one project to the other.
> The maven build was then integrated with Jenkins (CI) and SonarQube (so that future ‘JF’ is happy with old ‘JF’, and all the team's work are standardized a bit) with ease.
>
> From my experience, the team was happy with the Maven switch, none of us had to become an expert (because we had one already).
> Maven help a lot on easing the dependency management of your apps (a building block only declare his direct dependency). Once you remove the noise of declaring dependencies, you will be left with a clear graph of dependent block. You will then have to tackle the real problem of incompatible dependencies (A need B and Xv1, but B need Xv2). Maven will make the graph simple and clear, it will try to provide helper but can’t really help much after that.
>
> jfv
>
>
>> On May 4, 2015, at 5:09 AM, David Avendasora <email@hidden> wrote:
>>
>>> On May 1, 2015, at 6:35 PM, Chuck Hill <email@hidden> wrote:
>>>
>>> Maven seems like a better thought out and implemented solution.
>>
>> …
>>
>> Have you ever had one of those moments where things just seem so off-kilter you’re sure you’re having a dream, but no matter how many times you cry out for mommy you are left sitting there slowly realizing that there’s been some fundamental shift in the universe that you missed out on. (And your wife is slowly picking up her phone and dialing your therapist. Again.)
>>
>> —————————————————————————————
>> WebObjects - so easy that even Dave Avendasora can do it!™
>> —————————————————————————————
>> David Avendasora
>> Senior Software Abuser
>> Nekesto, Inc.
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden