[ 
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)

Reply via email to