If I understand you correctly, the reason for putting this in the parent of Z is that a developer of Z shouldn't change this. If it's local to Z, it shouldnit go in the parent... Having said that, it is always possible to override in a childs dependencies section.
/Anders On Tue, Feb 16, 2010 at 14:26, Moser, Christian <[email protected]> wrote: > Ok I agree with your solution, it will make it less complicated and more > maintainable. > > Ok if I go ahead and add depmgmt-x:1.0.0 to the dependencyManagement > section of Z(Parent), subsystem X (with released components) is going to be > properly referenced by project Z. But what if a developer want's to work > with subsystem x? Isn't there any other way than editing and installing pom > Z(parent) with depmgmt-x-SNAPSHOT? Or is this the procedure in the fields? > > Stephen, could you be more specific on this, please? > "If you are working locally on two subsystems, you will do > > cd subsys1 > mvn clean install > cd ../subsys2 > mvn versions:use-latest-snapshots > > to pull in the subsys1 -SNAPSHOTs" > > It sounds interesting but I don't get the point of it. Will this load > depmgmt-x-SNAPSHOT into Z(parent), only local? How does it work? > > http://mojo.codehaus.org/versions-maven-plugin/use-latest-snapshots-mojo.htmlcould > be more instructive. > > > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] Im > Auftrag von Anders Hammar > Gesendet: Dienstag, 16. Februar 2010 12:42 > An: Maven Users List > Betreff: Re: Profile activation with maven & subsystems > > 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
