Re: Distribution management
Karl Heinz Marbaise-3 wrote > The distributionManagement should be offered by a company parent pom > which handles this...and it is a good idea to use placeholders here to > have chance to change that in particular with CI environments which can > control this... OK that's workable. One layer indirection won't hurt. Karl Heinz Marbaise-3 wrote >> If not, why don't I understand the paradigm? It makes little sense to me >> that a change in the environment (the repository URLs) should force a >> version change in all projects under development. > > Because it represents an different state of the environment in time > which is recorded in a version control... That's clear, but it doesn't explain why Maven was designed to allow unversioned download repositories changes, while making it difficult by default not to version distribution repository changes. i.e. I still don't understand why Maven does not allow the distributionManagement xml in the settings.xml It really does look like an oversight - if it hadn't been unchanged for a decade. -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Distribution management
Hi, On 10/07/18 11:09, ahardy42 wrote: Hi maven-users, it seems this issue was last discussed almost 10 years ago but despite reading the docs and the email lists there is still an issue with distribution management that I don't understand. I do not wish to declare our company's internal release and snapshot repositories in pom files which are versioned, and I can't put the xml in the settings.xml. The distributionManagement should be offered by a company parent pom which handles this...and it is a good idea to use placeholders here to have chance to change that in particular with CI environments which can control this... I only see two alternatives: - I declare the distributionManagement xml for my team in a parent pom which I deploy on an updateable repository where we do not have to increment the version The parent should also have a fixed version which means release versions. The parent can/should also contain the definition of plugins etc...which means they can/should be upgraded on a regular base... - I provide everybody with the command line script snippet to do the deploy manually Only a CI server should deploy to a repository / repository manager ...cause you don't know which state people are deploying... If not, why don't I understand the paradigm? It makes little sense to me that a change in the environment (the repository URLs) should force a version change in all projects under development. Because it represents an different state of the environment in time which is recorded in a version control... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Distribution management
altDeploymentRepository (or alternatively altReleaseDeploymentRepository/altSnapshotDeploymentRepository) sounds like THE solution to this problem: https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository mvn deploy -DaltDeploymentRepository=company-repo:default:https://… —or— mvn release:perform -Darguments="-DaltDeploymentRepository=company-repo:default:https://…"; Using placeholders in doesn't buy much… And using an extension sounds like "why make it simple when it can be complicated" (I don't deny there are probably situations where this would be a better choice, but that really sounds like the exception rather than the rule). On Tue, Jul 10, 2018 at 11:33 AM Matthieu BROUILLARD wrote: > Hi Adam, > > 'distributionManagement' is part of the pom not part of settings : maven is > like that. > > If you do not want to expose some company repositories or if those ones are > often changing then you can: > - either use placeholders in some predefined `distributionManagement` tags > (in project or in parent) > - use `altDeploymentRepository` of maven deploy plugin > - write a maven core extension that updates dynamically & in memory the POM > of your projects > > Matthieu > > > On Tue, Jul 10, 2018 at 11:09 AM ahardy42 > wrote: > > > Hi maven-users, > > > > it seems this issue was last discussed almost 10 years ago but despite > > reading the docs and the email lists there is still an issue with > > distribution management that I don't understand. > > > > I do not wish to declare our company's internal release and snapshot > > repositories in pom files which are versioned, and I can't put the xml in > > the settings.xml. > > > > I only see two alternatives: > > > > - I declare the distributionManagement xml for my team in a parent pom > > which I deploy on an updateable repository where we do not have to > > increment > > the version > > > > - I provide everybody with the command line script snippet to do the > > deploy > > manually > > > > Both of these alternatives have drawbacks. > > > > If there is another way of keeping the distributionManagement out of the > > versioned poms? > > > > If not, why don't I understand the paradigm? It makes little sense to me > > that a change in the environment (the repository URLs) should force a > > version change in all projects under development. > > > > Regards > > Adam > > > > > > > > -- > > Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: Distribution management
Hi Adam, 'distributionManagement' is part of the pom not part of settings : maven is like that. If you do not want to expose some company repositories or if those ones are often changing then you can: - either use placeholders in some predefined `distributionManagement` tags (in project or in parent) - use `altDeploymentRepository` of maven deploy plugin - write a maven core extension that updates dynamically & in memory the POM of your projects Matthieu On Tue, Jul 10, 2018 at 11:09 AM ahardy42 wrote: > Hi maven-users, > > it seems this issue was last discussed almost 10 years ago but despite > reading the docs and the email lists there is still an issue with > distribution management that I don't understand. > > I do not wish to declare our company's internal release and snapshot > repositories in pom files which are versioned, and I can't put the xml in > the settings.xml. > > I only see two alternatives: > > - I declare the distributionManagement xml for my team in a parent pom > which I deploy on an updateable repository where we do not have to > increment > the version > > - I provide everybody with the command line script snippet to do the > deploy > manually > > Both of these alternatives have drawbacks. > > If there is another way of keeping the distributionManagement out of the > versioned poms? > > If not, why don't I understand the paradigm? It makes little sense to me > that a change in the environment (the repository URLs) should force a > version change in all projects under development. > > Regards > Adam > > > > -- > Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Distribution management
Hi maven-users, it seems this issue was last discussed almost 10 years ago but despite reading the docs and the email lists there is still an issue with distribution management that I don't understand. I do not wish to declare our company's internal release and snapshot repositories in pom files which are versioned, and I can't put the xml in the settings.xml. I only see two alternatives: - I declare the distributionManagement xml for my team in a parent pom which I deploy on an updateable repository where we do not have to increment the version - I provide everybody with the command line script snippet to do the deploy manually Both of these alternatives have drawbacks. If there is another way of keeping the distributionManagement out of the versioned poms? If not, why don't I understand the paradigm? It makes little sense to me that a change in the environment (the repository URLs) should force a version change in all projects under development. Regards Adam -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
