>I'm responsible for the technical architecture of many projects at my
>location. One project in particular (still in active development with
>code released to production) will likely never upgrade past 2.0.4
>because of the changes to dependency resolution. Although these
>changes are a good thing, problems will not show up in a build, but in
>the runtime environment; the most problematic ones are class loading
>issues with WebSphere, but occasionally I have had to deal with
>"invalid class" errors because somehow commons-collections 2.0 made it
>into the war when the project was compiled and tested against 3.2.
We made a tool in the dependency plugin to help detect and correct
these. Even if you aren't upgrading, you might want to run the tool as
you might have problems you don't know about. I understood the problem
enough to write the tool and was shocked how many issues I had in my own
corp builds.
>Anyway, I'm rambling. The project does not want to upgrade because
>we would likely need to stop all work for at least two days for a
>complete system test / regression test / fix pom cycle. After
>spending many weeks overall resolving issues that were deemed to be
>"maven brain damage" nobody wants the hassle.
Not entirely try if you use the tool mentioned above. You will be able
to fix your poms before moving over to the next version. That's how I
did it with 60+ developer and 100s of modules.
>I am having success at convincing newer projects to start out using
>2.0.8; so I am wondering how to easily maintain two maven versions for
>us developers on the technical architecture team -- is it as simple as
>swapping out MAVEN_HOME?
And path, yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
