I wanted to throw a comment into this discussion... Please keep in mind that this level of build reproducibility is not *necessarily* a good thing. The particular issue I have with the reproducibility is actually the testing side of it (functional/integration testing). I would love to use profiles in a drop-in fashion specifically to alter the reproducibility of the builds *from a test perspective*. However, that would mean use of either profiles.xml or profiles in settings.xml, neither of which is allowed to change either of the two things which would be needed, in the name of reproducibility: dependencies and testResources.
So I would argue that the notion of "build reproducibility" should be limited to not cover test related concerns. On Sat, 2007-06-02 at 15:09 -0500, Jeff Jensen wrote: > I agree! This I said: "if they truly all have the same profiles and profile > deps", which in your case fails - they share some, but not all share the > same ones. > > In the spirit of idea exchange...if you really don't want poms having > duplicate deps, profiles, etc., I would consider using multiple parent poms. > > One of the things I've done for my current customer is multiple "base poms". > There is the master base pom that they all use eventually extend from, and > every component uses every dependency in that top base pom. I'm sure you > can imagine the next tier or two having one or a few poms. Each component's > pom extends from the correct parent pom so it has only the deps necessary > from the lineage. Component specific info is in its own pom. There are > only a handful of parent poms, so it is not unwieldy. The thing I like is > the "change it in one place". It's just like a class hierarchy in the end, > but pom info instead :-). It is a very large system (approaching 12,000 > classes) and many components (jars, wars, ear - web apps and batches), and > this structure helps us ensure all components have the same dep versions per > release as we need. > > This still has the inconvenience of new versions for _all_ poms when the > top-level master changes, but it is fine for me (and a smaller impact when a > different parent pom changes). Things usually change when many components > are in development mode; hence they are all in SNAPSHOT versions anyway. > > I would appreciate a "better way" suggestion or two if someone has any > ideas. This is what works well for us. > > > -----Original Message----- > From: Paul Spencer [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 02, 2007 2:15 PM > To: Maven Users List > Subject: Re: Can a POM import a profile from anothe POM? > > Jeff, > My projects fit into the following groups: > o jars containing business logic > o jars containing common utilities > o wars for specific application servers > > All of the above may share a parent POM, but why should a project that > produces a "jars containing business logic" be affected when a profile > that it does not use, like "cargo_tomcat_test", is updated? > > Like you, I am just sharing my thoughts. The more we understand how > something is used, the better decision we can make. Worse yet, we may > learn something new in the process :) > > Paul Spencer > > Jeff Jensen wrote: > > Hi Paul, > > > > Indeed, yes. My comment on lack of build reproducibility was addressing > the > > "shared resource" approach (and you did not suggest), which is usually not > > reproducible unless steps are deliberately made to source control the > shared > > resource in a correct manner (in the codelines of all its dependents); > > apologies for not making that clear! :-) > > > > By the fact that your deps & profiles are in the pom, which is versioned > of > > its own series, the profiles have the build reproducibility. > > > > I also was commenting on the "weigh the effort for the benefit" of holding > > profiles in a parent pom, which you commented was impractical, but the > > benefit of reuse may outweigh the inconvenience, if they truly all have > the > > same profiles and profile deps. That is kind of stating the obvious, but > > wanted to share the thought that it does have value even though I agree it > > can be inconvenient... :-) > > > > > > -----Original Message----- > > From: Paul Spencer [mailto:[EMAIL PROTECTED] > > Sent: Saturday, June 02, 2007 12:59 PM > > To: Maven Users List > > Subject: Re: Can a POM import a profile from anothe POM? > > > > Jeff, > > I believe I address your concern, which I share, of build > > reproducibility by including a version number on the imported profile's > > artifact, essentially making it behave like a dependency. > > > > Below is the example, which was in my original post. > > *** > > * POM of project which imports the profiles cargo_tomcat_remote and > > * cargo_jetty_remote and selenium-integration-test. > > *** > > <project> > > ... > > <groupId>com.foo.applications</groupId> > > <artifactId>webapp_1</artifactId> > > ... > > <profiles> > > <profile> > > <id>cargo_tomcat_remote</id> > > <groupId>com.foo.profiles</groupId> > > <artifactId>cargo</artifactId> > > <version>1.0</version> > > <activation> > > ... > > </activation> > > </profile> > > <profile> > > <id>cargo_jetty_remote</id> > > <groupId>com.foo.profiles</groupId> > > <artifactId>cargo</artifactId> > > <version>1.0</version> > > <!-- used activation rules in imported profile --> > > ... > > </profile> > > <profile> > > <id>selenium-integration-test</id> > > <groupId>com.foo.profiles</groupId> > > <artifactId>selenium</artifactId> > > <version>1.0</version> > > <!-- used activation rules in imported profile --> > > ... > > </profile> > > </project> > > > > Paul Spencer > > > > Jeff Jensen wrote: > >> One consideration of this though is build reproducibility. While it is > >> inconvenient to update all projects depending on the parent POM, it > >> facilitates build reproducibility, as the profiles are then correctly > >> versioned. A "shared resource" is not usually setup to facility a > >> reproducible build. What that means is consider the importance of > >> reproducible builds vs the effort to manage parent pom releases vs > keeping > >> them separate in their own respective poms. > >> > >> > >> -----Original Message----- > >> From: Armin Ehrenfels [mailto:[EMAIL PROTECTED] > >> Sent: Saturday, June 02, 2007 11:02 AM > >> To: Maven Users List > >> Subject: Re: Can a POM import a profile from anothe POM? > >> > >> Paul Spencer wrote: > >> > >>> Armin, > >>> I did not know about profiles.xml, but this does not meet my > >>> requirements. Since I used Continuum on a different server in > >>> addition to developers on Windows and Unix machine, the use of > >>> symbolic links will not work. > >> Indeed, my suggestion is not helpful in your particular case. The idea > >> of having a "central" profile resource available in a development > >> community sounds interesting to me. Maybe, you should formulate an > >> improvement to maven such as being able to access a network wide profile > >> resource via URL. > >> > >> Good luck. > >> > >> Armin > >> > >>> Paul Spencer > >>> > >>> > >>> Armin Ehrenfels wrote: > >>> > >>>> Paul Spencer wrote: > >>>> > >>>>> I am finding that profiles are very powerful. As I make more use of > >>>>> them across projects, many of which are unrelated, I find myself > >>>>> copying a profile from one POM to another. Placing profiles in a > >>>>> POM the is extended is impractical because each change to a profile > >>>>> in the POM will prompt a release cycle of the POM and every project > >>>>> that extends the POM. > >>>>> > >>>>> Thus my question, is their a way of importing a profile from another > >>>>> POM? > >>>> Hi Paul, > >>>> you don't need to import a profile. You can store it in a separate > >>>> file called profiles.xml, located in the same directory as your > >>>> pom.xml. Maven automatically looks for this file. If you work with an > >>>> UNIX OS, you probably know symbolic links, so locating a single > >>>> profiles.xml at a particular place and pointing to it from every > >>>> module directory is very easy. > >>>> > >>>> HTH > >>>> > >>>> Armin > > > > > --------------------------------------------------------------------- > 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]
