Yes. So you'll have different version of this pom, but it's still just one import pom (artifact). The version will determine if it's a released version of the dep mgmt set or a dev version (SNAPSHOT).
/Anders On Tue, Feb 16, 2010 at 10:51, Moser, Christian <[email protected]> wrote: > Every component in a subsystem has a different version. > What do you mean with: "ONE import pom per subsystem"? > e.g. replacing depmgmt-rel-x & depmgmt-dev-x with depmgmt-x ? If so, how > can I handle different subsystem component-versions in depmgmt-x without > profiles? > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 08:58 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > Don't use profiles, as I said in my previous post. > > What's the release idea of a subsystem's components - will they all have > the > same version number? If so, you could skip the import pom and just define a > property for each subsystem's version and use that in your > dependencyManagement section. > > If not, just have ONE import pom per subsystem. The version of that pom > defines if it's a release or dev (SNAPSHOT). > > /Anders > On Tue, Feb 16, 2010 at 08:44, Moser, Christian <[email protected]> wrote: > > > Thanks a lot for your fast response! > > The file can be found here: > > http://www.christian-moser.ch/fx/subsystems.pdf > > > > Yes im using depmgmt poms with import. Every of the five subsystems can > be > > used by any project(in diagram project Z) with different versions, this > > would mean I had to set 5 project dependent version properties in project > > parent pom? (in diagram Z(parent))? > > Currently Z(parent) contains five profiles, every profile contains the > > project dependent subsystem versions (4 released subsystems & 1 snapshot > > subsystem version). How can i activate those profiles and make the maven > > embedder notice that in the (IDE)? > > > > Thanks in advance > > Chris > > > > > > -----Ursprüngliche Nachricht----- > > Von: [email protected] [mailto:[email protected]] Im > > Auftrag von Anders Hammar > > Gesendet: Dienstag, 16. Februar 2010 08:04 > > An: Maven Users List > > Betreff: Re: Profile activation with maven & subsystems > > > > First, the pdf is missing. Without that I'm not sure I fully understand > > your > > thoughts. > > > > In general, having your dependencies defined by a profile being active is > > IMHO bad practice. The biggest reason for this, however possible not so > > important for you if you have a "subsystem", is that if some other > artifact > > has a dependency to your artifact, they will not the get the correct > > transitive dependencies (or different ones dependending on whatever). > This > > is not portability or reproducibility. > > > > I'm wondering why you just don't simply keep the version of the depmgmt > pom > > (I guess you use import scope for this one?) as a property and update > this > > property as you need. If you want to try a different version it is > possible > > to override a property value from CLI. However, NEVER override for a > > release! The pom should then always contain the correct config. > > > > /Anders > > On Tue, Feb 16, 2010 at 07:33, Moser, Christian <[email protected]> wrote: > > > > > We've trouble creating a concept for maven using subsystems. > > > > > > > > > > > > In the attached pdf you can see a maven/subsystem concept. In short, > > we've > > > got a component based software which is based on quiet a lot of > > components > > > (each component is a maven project). Those components are bundled in > > > subsystems. Every subsystem features a parent pom which contains all > > > components of this subsystem as a snapshot version. > > > > > > The snapshot versions are managed by the pom depmgmt-*dev*-*x* in all > > > subsystems. > > > > > > The release versions are managed by the pom depmgmt-*rel*-*x* in all > > > subsystems. > > > > > > > > > > > > As you can see project Z retrieves dependecy versions from > > depmgmt-*dev*-x > > > & depmgmt-*rel*-x from the subsystems *X* & *Y*. Our plan is that we > only > > > want the subsystem a developer currently is working with snapshot > > versions, > > > all other needed subsystems by the project, in this case project Z, are > > only > > > available with their released components. > > > > > > > > > > > > e.g for working with subystem *X*, you need to set in user > settings.xml: > > > > > > <activeProfile>subsystem-*x*</activeProfile> > > > > > > > > > > > > In this case profile subsystem-x gets activated in Z(parent) and > resolves > > > the snapshot dependencies versions from depmgmt-*dev*-*x* & the > released > > > dependencies versions from depmgmt-*rel*-*y *by dependency management. > > > > > > > > > > > > This is simular to the "reproduce example project" I've uploaded in > > > http://jira.codehaus.org/browse/MNG-4538. Not exactely the same, > though. > > > > > > > > > > > > I was told activating dependencies by settings.xml isn't a good idea > and > > > like the issue above demonstrates, it doesn't work properly, either. So > I > > > could go ahead and activate the profile "subsystem-x" by a CLI > property. > > > This would also work, but isn't really comfortable to working with in > > IDE's > > > because you had to set this for every component by hand or the IDE > won't > > > find any dependency version. Setting these properties in the > settings.xml > > > for profile activation won't work, it's also not by design. > > > > > > > > > > > > So how to easily activate profile "subsystem-*x*" for maven & maven > > > embedder in IDE's? Do you have any best practice tip for solving our > > > problem? > > > > > > > > > > > > I would really appreciate your help & please ask if my description of > the > > > diagram is too unclear > > > > > > Chris > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
