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 protected]
> On 2015-May-04, at 11:43 AM, Chuck Hill <[email protected]> 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 protected]>
>> wrote:
>>
>>> On May 1, 2015, at 6:35 PM, Chuck Hill <[email protected]> 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 protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/listfez%40dakri.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
