[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463010#comment-15463010
]
Robert Patrick commented on MNG-6083:
-------------------------------------
Karl,
Comments (mostly) in order...
1.) I only have a profile for it so that I can chain them actions together:
mvn clean install -Pdev,dev-install
or
mvn clean install -Pdev,system-test
The dev profile is active by default so yes, it could be removed at the expense
of needing to run mvn twice to run it with one of the other profiles.
2.) The dev-install profile runs our zipinstall and install-a2c-home
modules--it does not include the core software modules built by the dev profile.
3.) system-test uses the failsafe plugin so yes, it runs during the standard
integration-test-related phases...
4.) I am not sure how your suggestion to move the removal of functionality down
into the module POMs really helps. It essentially just pushes the problem down
a level at the expense of added complexity both in the POMs and for developers.
5.) Yes, we could move developer- and/or environment-specific information into
settings.xml but that itself causes a problems.
- Typically, I like to keep project dependencies out of settings.xml because we
work across multiple projects where the information might be conflicting. I
usually only define things that never change in my ~/.m2/settings.xml (e.g.,
mirrors, servers that require credentials and other such configuration).
- When putting project-specific settings in settings.xml without which the
project will not build, I *believe* that the best practice is to put
settings.xml under source control, typically inside the project source tree.
In doing so, I end up with a similar problem to the one that I currently have
with maven.config. The only difference is that I can have as many
settings-xxx.xml files in my source tree as I want--I just have to make sure
that the developers (and IDEs) make sure to always add -s
relative/path/ro/settings-rpatrick-laptop.xml to the mvn command-line. This is
a pain because I, for one, get distracted sometimes and forget.
5.) I will take a look at toolchain.xml to see if this will help.
6.) Profiles for OSes don't help when the settings vary across environment.
They also likely clash with our current use of profiles to segment the build.
I could, for example, move system-test outside the main project into an
integration-test project. The problem with that is the added complexity of
figuring out how to retain control all of the dependency, plugin, etc.
management in a single location. I have learned the hard way that parent POMs
that are not the top-level aggregate POM for the project are problematic for
things like the release plugin...
I think your suggestions are glossing over the complexities of managing
numerous Maven projects across a real-world development organization. At any
point in time, I am working across a dozen or more projects and while you offer
solutions like "push environment-specific settings into ~/.m2/settings.xml",
you don't offer solutions for dealing with the complexities of managing
multiple ~/.m2/settings.xml files that contain project-specific information
(i.e., remembering to copy the right file to settings.xml and/or use
remembering to use the right -s for each build).
Clearly, maven.config was made for Maven command-line properties. This
discussion seems to be about why Maven breaking compatibility between 3.3.3 and
3.3.9 is ok because what I am doing is wrong and I need to do things in the way
you are suggesting so that I do not care about Maven breaking compatibility
across releases. I wish my customers would accept this as an argument.
Unfortunately, customers tend to use features in ways that you never expect and
breaking compatibility for those features is a problem for customers. :-)
Unfortunately, the way you are suggesting seems to introduce other problems
that:
- don't work well in real-world development environments where at any point in
time, developers are working on any number of projects, and
- most open-source projects using Maven (that I have looked at) avoid by not
following some of your suggestions.
Thanks,
Robert
> Maven 3.3.9 breaks release:perform by not including maven.config
> ----------------------------------------------------------------
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
> Issue Type: Bug
> Components: General
> Affects Versions: 3.3.9
> Reporter: Robert Patrick
> Priority: Blocker
>
> Our release process runs both our build and our integration tests. The
> integration tests rely on our project root directory's .mvn/maven.config file
> to run properly. The maven.config file is NOT checked into the source tree
> because it contains environment-specific values so each developer has their
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in
> another location and with Maven 3.3.9, the maven.config from the original
> location is not being used. The build specifies the release-plugin version
> so the difference seems to be in the core Maven distribution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
