This is a really bad plan.

Your dependencies should not depend on what profile is active.

IMHO it was a mistake to allow specification of dependencies from profiles.

The best solution is to have either:

1. A project for spring 3 and a project for spring 2.5 that defines the
dependencyManagement for each of the spring versions and then use dependency
scope import to pull in the spring 3 or the spring 2.5 dependency version
info (assumes that the same GAV coords exist in both versions of spring and
only the versions/exclusions change, and or the transitive deps are pulling
in the diffs)

2. A project for spring 3 and a project for spring 2.5 that pull in all the
deps for these and then just depend on either the spring 3 or the spring 2.5
version.

-Stephen

On 24 June 2010 08:50, Dunstan, Tom (SACE Board)
<t...@saceboard.sa.gov.au>wrote:

> Hi all
>
> We're trying to set up a set of maven projects which can be used with both
> spring 2.5.x and spring 3.0.x. Mostly our applications are currently using
> 2.5.6 atm, but we'd like to gradually move them over to 3.0.x as time goes
> on.
>
> Rather than have our libraries and apps hard-code the versions of the
> various spring modules, spring security modules and the compatible junit
> library, I'm trying to put those version numbers into our parent pom under
> spring2/spring3 profiles with <dependencyManagement> sections which can then
> be activated project by project. This only works if specifying that profile
> on the command line, though. There appears to be no other way to activate
> the parent pom profile:
>
>  - I've tried creating a profiles.xml and adding the id to the
> <activeProfiles> section, but this appears not to work unless the profile is
> also declared in that file, and if I declare it, the information from the
> parent pom is then ignored. Having this setup working would be the ideal, as
> I don't want the profile getting switched off if I happen to activate
> another profile.
>
>  - I've tried defining the profile again the child pom and marking it
> <activeByDefault>. This wouldn't be ideal, since activating any other
> profile would switch it off, but it doesn't work anyway.
>
>  - I've tried creating a file and activating the profile by file existence.
>
>  - I've even tried setting a property in the child pom, but it seems that
> this is read too late in the process.
>
> I really *don't* want to have to specify the profile name on the command
> line every time. It's not something that is going to change often, and it's
> easy for one of our devs (including me!) to accidentally leave off. We've
> considered having the different spring settings in different intermediate
> pom projects, but we plan to have other children of our parent on an
> orthogonal axis (e.g. one for web apps etc, one for webstart etc). Lack of
> mixins or an equivalent in maven is kinda hurting us.
>
> Is there any way to activate this parent profile for every build of a
> dependent project?
>
> Am I going about this the wrong way? Surely we aren't the only people
> trying to define a coherent set of dependencies in a non-hardcoded
> fashion...
>
> Any suggestions gratefully accepted!
>
> Thanks
>
> Tom
>
>
>
>
> Tom Dunstan
> Senior Analyst/Programmer
>
> SACE Board of South Australia
> 60 Greenhill Road, Wayville, SA 5034
> P   +61 8 8372 7543
> F   +61 8 8372 7438
> E   t...@saceboard.sa.gov.au
> W  www.sace.sa.edu.au
>
> <http://www.sace.sa.edu.au/> <http://www.sace.sa.edu.au/> SACE
>
>
>
> The information may be confidential and/or legally privileged. It is
> intended solely for the addressee. Access to this email by anyone apart from
> the addressee or his or her delegate is unauthorised. If you are not the
> intended recipient any disclosure, copying, distribution, or any action
> taken or omitted to be taken in reliance on it, is prohibited and may be
> unlawful. If you have received this email in error please advise the author
> immediately.
>
> P Please consider the environment before printing this email.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Reply via email to