Steve,
To me reproducibility does include testing, both unit and integrated. Now
I utilize properties from setting.xml to account for differences is environment.
Also note, the suggested enhancement adds functionality, thus you existing use
of profiles do not have to change.
Paul Spencer
Steve Ebersole wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
