Re: [VOTE] Release Apache Maven Changelog Plugin version 2.3
+1 24. Juni 2014 21:43 skrev "Karl Heinz Marbaise" følgende: > Hi, > > We solved 13 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa? > projectId=11211&version=16516 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/issues/?jql=project%20%3D% > 20MCHANGELOG%20AND%20status%20%3D%20Open%20ORDER%20BY% > 20key%20DESC%2C%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1027 > > http://repository.apache.org/content/repositories/maven- > 1027/org/apache/maven/plugins/maven-changelog-plugin/2.3/ > maven-changelog-plugin-2.3-source-release.zip > > Source release checksum(s): > maven-changelog-plugin-2.3-source-release.zip sha1: > 66bf25b213e3af3cbe4de850e06ddd2bfc1414f7 > > Staging site: > http://maven.apache.org/plugins-archives/maven-changelog-plugin-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Kind regards > Karl-Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[GitHub] maven-surefire pull request: Break tag to make stack traces format...
GitHub user jeversmann opened a pull request: https://github.com/apache/maven-surefire/pull/41 Break tag to make stack traces formatted Breaks would make the stack traces appear properly formatted instead of a single long line of text. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jeversmann/maven-surefire master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/41.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #41 commit 0ca47a26ea9aa2e5e226eb68315e4a126ee9fc3d Author: Joshua Eversmann Date: 2014-06-27T01:16:41Z Break tag to make stack traces formatted --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
Am 06/26/14 17:18, schrieb Stephen Connolly: > And the staleness is another killer on the: "oh why don't we use DNS > records to resolve the repository" because what if foobar.org do not renew > their domain, now all the org.foobar artifacts will just drop off the net > and we have no means to inject a repo for them again... Central authority fallback zone. So if 'foobar.org' isn't renewed so that DNS becomes unavailable, one could move that groupId to a fallback zone like: 'groupid.central.apache.org' or something like this. Some mechanism like this would already be required for group ids like 'commons-io' or such which cannot be mapped to a domain directly. So resolve repositories for 'groupId' by DNS at 'groupId', not finding any records there, search the fallback zone 'groupId.central.apache.org', not finding anything there, fallback to legacy POM repositories (optionally). Still nothing found, fail with artifact not found. If a '' with an URL like 'repository.foobar.org' is used, that repository would become stale as well already. You would have control about that via such a repository authority zone. > I think dropping and using social pressure to "get thee to > central" is probably the best worst long term solution Nothing can stop people from grabbing the Maven source distribution and patching it to theire needs and nothing can stop people from grabbing the sources of some artifact from 'central' and redeploy it to some other repository. I am heading after a mechanism to make the artifact providers the autoritative entity controlling the repositories to resolve _theire_ artifacts from. If someone needs to e.g. deploy a custom 'commons-io', they are forced to change the groupId to something they are authoritative for since Maven will never fetch that 'commons-io' from a non-authoritative repository. Just put everything into 'central' isn't practical, I think. That's like deploying all websites of the world to a central server. You type 'maven.apache.org' into the browser and you are connected to the corresponding web server. You type 'commons-io:commons-io:2.4' into the POM, and you get connected to somewhere non-authoritative and fetch some non-authoritative content, if not careful and the providers of 'commons-io' cannot do anything about that. Regards, -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Changelog Plugin version 2.3
Hi Martin, > Deprecating: As far as deprecating ..be mindful that Maven is used by over 100,000 shops for production builds Before anything gets trashed we need to keep release managers implementing previous maven installations satisfied. Are you talking about something in particular ? As i can see this release only fixes bugs and improves things...so? Apart from that if you like to discuss things we should make it outside the VOTE thread... May be you can start a different thread about the topic you would like to discuss in relationship with that... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Changelog Plugin version 2.3
+1 Regards, Hervé Le mardi 24 juin 2014 21:43:17 Karl Heinz Marbaise a écrit : > Hi, > > We solved 13 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11211&version=165 > 16 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/issues/?jql=project%20%3D%20MCHANGELOG%20AND%20stat > us%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1027 > > http://repository.apache.org/content/repositories/maven-1027/org/apache/mave > n/plugins/maven-changelog-plugin/2.3/maven-changelog-plugin-2.3-source-relea > se.zip > > Source release checksum(s): > maven-changelog-plugin-2.3-source-release.zip sha1: > 66bf25b213e3af3cbe4de850e06ddd2bfc1414f7 > > Staging site: > http://maven.apache.org/plugins-archives/maven-changelog-plugin-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Kind regards > Karl-Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Changelog Plugin version 2.3
On Thu, Jun 26, 2014 at 4:56 PM, Martin Gainty wrote: > I dont know enough to make an intelligent comment on any of the deltas that > may have been fixed in changelog > > Deprecating: > As far as deprecating ..be mindful that Maven is used by over 100,000 shops > for production builds > Before anything gets trashed we need to keep release managers implementing > previous maven installations satisfied. Why? If they don't want the new version, they keep using the old version. Or they get off their duffs and volunteer to help. There are way too many plugins and way too few volunteers for us to take a 'never inconvenience anyone' attitude. > > *congratulations on your win today* > Martin > >> Date: Thu, 26 Jun 2014 22:49:21 +0200 >> From: khmarba...@gmx.de >> To: dev@maven.apache.org >> Subject: Re: [VOTE] Release Apache Maven Changelog Plugin version 2.3 >> >> Hi, >> >> anyone else? >> >> >> > On 6/26/14 1:38 AM, Olivier Lamy wrote: >> > +1 >> > >> > On 25 June 2014 05:43, Karl Heinz Marbaise wrote: >> >> Hi, >> >> >> >> We solved 13 issues: >> >> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11211&version=16516 >> >> >> >> There are still a couple of issues left in JIRA: >> >> http://jira.codehaus.org/issues/?jql=project%20%3D%20MCHANGELOG%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC >> >> >> >> Staging repo: >> >> https://repository.apache.org/content/repositories/maven-1027 >> >> >> >> http://repository.apache.org/content/repositories/maven-1027/org/apache/maven/plugins/maven-changelog-plugin/2.3/maven-changelog-plugin-2.3-source-release.zip >> >> >> >> Source release checksum(s): >> >> maven-changelog-plugin-2.3-source-release.zip sha1: >> >> 66bf25b213e3af3cbe4de850e06ddd2bfc1414f7 >> >> >> >> Staging site: >> >> http://maven.apache.org/plugins-archives/maven-changelog-plugin-LATEST/ >> >> >> >> Guide to testing staged releases: >> >> http://maven.apache.org/guides/development/guide-testing-releases.html >> >> >> >> Vote open for 72 hours. >> >> >> >> [ ] +1 >> >> [ ] +0 >> >> [ ] -1 >> >> >> >> Kind regards >> >> Karl-Heinz Marbaise >> >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >> > >> > >> > >> >> >> Mit freundlichem Gruß >> Karl-Heinz Marbaise >> -- >> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 >> Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029 >> Hauptstrasse 177 USt.IdNr: DE191347579 >> 52146 Würselen http://www.soebes.de >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE] Release Apache Maven Changelog Plugin version 2.3
I dont know enough to make an intelligent comment on any of the deltas that may have been fixed in changelog Deprecating: As far as deprecating ..be mindful that Maven is used by over 100,000 shops for production builds Before anything gets trashed we need to keep release managers implementing previous maven installations satisfied. *congratulations on your win today* Martin > Date: Thu, 26 Jun 2014 22:49:21 +0200 > From: khmarba...@gmx.de > To: dev@maven.apache.org > Subject: Re: [VOTE] Release Apache Maven Changelog Plugin version 2.3 > > Hi, > > anyone else? > > > > On 6/26/14 1:38 AM, Olivier Lamy wrote: > > +1 > > > > On 25 June 2014 05:43, Karl Heinz Marbaise wrote: > >> Hi, > >> > >> We solved 13 issues: > >> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11211&version=16516 > >> > >> There are still a couple of issues left in JIRA: > >> http://jira.codehaus.org/issues/?jql=project%20%3D%20MCHANGELOG%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > >> > >> Staging repo: > >> https://repository.apache.org/content/repositories/maven-1027 > >> > >> http://repository.apache.org/content/repositories/maven-1027/org/apache/maven/plugins/maven-changelog-plugin/2.3/maven-changelog-plugin-2.3-source-release.zip > >> > >> Source release checksum(s): > >> maven-changelog-plugin-2.3-source-release.zip sha1: > >> 66bf25b213e3af3cbe4de850e06ddd2bfc1414f7 > >> > >> Staging site: > >> http://maven.apache.org/plugins-archives/maven-changelog-plugin-LATEST/ > >> > >> Guide to testing staged releases: > >> http://maven.apache.org/guides/development/guide-testing-releases.html > >> > >> Vote open for 72 hours. > >> > >> [ ] +1 > >> [ ] +0 > >> [ ] -1 > >> > >> Kind regards > >> Karl-Heinz Marbaise > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > > > > > > Mit freundlichem Gruß > Karl-Heinz Marbaise > -- > SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 > Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029 > Hauptstrasse 177 USt.IdNr: DE191347579 > 52146 Würselen http://www.soebes.de > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
Re: [VOTE] Release Apache Maven Changelog Plugin version 2.3
Hi, anyone else? > On 6/26/14 1:38 AM, Olivier Lamy wrote: +1 On 25 June 2014 05:43, Karl Heinz Marbaise wrote: Hi, We solved 13 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11211&version=16516 There are still a couple of issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MCHANGELOG%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1027 http://repository.apache.org/content/repositories/maven-1027/org/apache/maven/plugins/maven-changelog-plugin/2.3/maven-changelog-plugin-2.3-source-release.zip Source release checksum(s): maven-changelog-plugin-2.3-source-release.zip sha1: 66bf25b213e3af3cbe4de850e06ddd2bfc1414f7 Staging site: http://maven.apache.org/plugins-archives/maven-changelog-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: "supplies" concept proposal (was "provides" could be "proffers")
On 21 Jun 2014, at 0:51, Stephen Connolly wrote: "supplies" concept proposal I've not yet had a good read thru this thread yet, but I thought I'd point out the OSGi "requirements and capabilities" work that's going on with those specs, which is similar/related to a degree. http://blog.osgi.org/2012/03/requirements-and-capabilities.html http://wiki.osgi.org/wiki/Provide-Capability http://wiki.osgi.org/wiki/Require-Capability Whilst the "supplies" is more about aliasing, and/or working with automating a I think there's potentially cross over in intent... Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
On 27 Jun 2014, at 0:55, Arnaud Héritier wrote: > My main concern with current POM entries about repositories is that we are > hardcoding some information that may change in the future ( the repo moved, > sources moved ...). Thus depending for what you are looking at an old POM > it may be a problem or not. Even including those mentioned in distributionManagement? Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
On 27 Jun 2014, at 7:47, Bernd Eckenfels wrote: 2) Deploy transitive runtime dependencies along with your release ... or make sure they are centrally available. I think this is an (important) best practice since years: +1 - that might even be a good first step - and could even just be a plugin in its own right - maven-central-plugin:check-dependencies :) http://blog.sonatype.com/2010/03/why-external-repos-are-being-phased-out-of-central/ And it is really good if it is enforced on MC. Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
On 27 Jun 2014, at 7:44, Michael Osipov wrote: let me rephrase your intention: you want to re-upload dependencies -- even if they are already in a repo?! Am I wrong? Essentially yes - as a means of enforcing that "everything required to actually compile or use my artefact is in a repository", that way limiting the need for consumers having to scour and configure N number of mirrored repositories in a nexus or something. Mostly as some form of "guarantee of accessibility", and in the name of reproducible builds. amrk - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
On 27 Jun 2014, at 3:18, Stephen Connolly wrote: > I think dropping and using social pressure to "get thee to > central" is probably the best worst long term solution Best worst? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
On 27 Jun 2014, at 2:18, Paul Benedict wrote: I agree with Jorg. Furthermore, I have found repositories addresses change overtime. I *don't* want this information in the POM either because it becomes stale. It's not really build information, per se, as it is Maven connection information. I have to fallback to modifying my settings.xml when I encounter one of these situations -- which is "smell" enough of this very issue. +1 - it's this reason I and others recommend all devs run a local archiva/nexus as a mirror, even if they have a company mirror - then you can add such repositories either company wide, or local if you need them. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
Am Thu, 26 Jun 2014 21:44:55 +0200 schrieb Michael Osipov : > Am 2014-06-26 21:41, schrieb Mark Derricutt: > > On 27 Jun 2014, at 7:27, Michael Osipov wrote: > > > >> 2) Deploy transitive runtime dependencies along with your release ... or make sure they are centrally available. I think this is an (important) best practice since years: http://blog.sonatype.com/2010/03/why-external-repos-are-being-phased-out-of-central/ And it is really good if it is enforced on MC. Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
Hi Jörg, On 27 Jun 2014, at 2:11, Jörg Schaible wrote: When maven is checking for a repository for an artefact, and using a mirror - if that artefact can't be found, maven should retry using the original repository directly with builds warnings. Very bad idea. Especially if the original repo is not/no longer reachable and you have to wait for a timeout. And you can no longer control with an Archive Manager what actually is used from where. True - as mentioned in one of my other replies, this was the part of the idea I wasn't 100% sold on myself, and the reason you state here is also the #1 reason I loathe being mentioned inside a pom.xml as well. essentially an implicit mirroring your dependencies. And suddenly we have all kind of stuff in public repos that are not allowed to be distributed. True - a further thought on this was that a) `optional` or `provided` dependencies shouldn't be published, but further - we _could_ add an `exclusions` list inside `dependencyManagement` to exclude those that shouldn't be published. Part of my thinking here is that if you're artefact depends on things that can't be published, why are you pushing that artefact to a public repository in the first place? IMHO, the best option *is* actually to remove the elements. Agreed - but for other reasons.
Re: POM 5.0 and Maven.next idea - re: 's
Am 2014-06-26 21:41, schrieb Mark Derricutt: On 27 Jun 2014, at 7:27, Michael Osipov wrote: 2) Deploy transitive runtime dependencies along with your release This beats DRY and reinvents the wheel. I would obstain doing either one. I don't see this as repeating oneself, just about populating a repository with required dependencies - not bundling dependencies inside your artefact or anything. Still - it's only an idea for discussion around a common problem. Mark, let me rephrase your intention: you want to re-upload dependencies -- even if they are already in a repo?! Am I wrong? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
On 27 Jun 2014, at 7:27, Michael Osipov wrote: 2) Deploy transitive runtime dependencies along with your release This beats DRY and reinvents the wheel. I would obstain doing either one. I don't see this as repeating oneself, just about populating a repository with required dependencies - not bundling dependencies inside your artefact or anything. Still - it's only an idea for discussion around a common problem. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
On 27 Jun 2014, at 7:27, Michael Osipov wrote: Not going to work if you are behing a MRM instance and proxied in a company like me. Given that is a settings.xml thing, thats purely your local maven installation - if we're talking about changing maven, that potentially could be up for changes. That being said - this was the only part of my idea I thought was horrible and not overly worth pursuing. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
Am 2014-06-26 14:34, schrieb Mark Derricutt: In last weeks dev hangout I raised the idea of removing elements due to some issues with them regarding mirrors etc which was somewhat negatively received, however I've been thinking about this a bit and came up with an interesting idea earlier in the night whilst at a gig. One of the problems I'm often seeing is that: 1) a project uploads their artefact to a repository ( mostly maven central ) 2) 90% of their dependencies are available from the repository in question 3) 1 critical dependency is not - which ultimately means you can't build..if you have a mirror setup (usually because you've not noticed a declaration which you need to configure in your nexus/arifactory/archiva etc. ) The idea I had is three fold: 1) Fallback on original repository when a mirror doesn't resolve When maven is checking for a repository for an artefact, and using a mirror - if that artefact can't be found, maven should retry using the original repository directly with builds warnings. Not going to work if you are behing a MRM instance and proxied in a company like me. 2) Deploy transitive runtime dependencies along with your release This beats DRY and reinvents the wheel. I would obstain doing either one. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
And the staleness is another killer on the: "oh why don't we use DNS records to resolve the repository" because what if foobar.org do not renew their domain, now all the org.foobar artifacts will just drop off the net and we have no means to inject a repo for them again... I think dropping and using social pressure to "get thee to central" is probably the best worst long term solution On 26 June 2014 15:18, Paul Benedict wrote: > I agree with Jorg. Furthermore, I have found repositories addresses change > overtime. I *don't* want this information in the POM either because it > becomes stale. It's not really build information, per se, as it is Maven > connection information. I have to fallback to modifying my settings.xml > when I encounter one of these situations -- which is "smell" enough of this > very issue. > > > > Cheers, > Paul > > > On Thu, Jun 26, 2014 at 9:11 AM, Jörg Schaible < > joerg.schai...@swisspost.com > > wrote: > > > Hi Mark, > > > > Mark Derricutt wrote: > > > > > In last weeks dev hangout I raised the idea of removing > > > elements due to some issues with them regarding mirrors etc which was > > > somewhat negatively received, however I've been thinking about this a > > > bit and came up with an interesting idea earlier in the night whilst at > > > a gig. > > > > > > One of the problems I'm often seeing is that: > > > > > > 1) a project uploads their artefact to a repository ( mostly maven > > > central ) > > > 2) 90% of their dependencies are available from the repository in > > > question > > > 3) 1 critical dependency is not - which ultimately means you can't > > > build..if you have a mirror setup > > > > > > (usually because you've not noticed a declaration which > you > > > need to configure in your nexus/arifactory/archiva etc. ) > > > > > > The idea I had is three fold: > > > > > > 1) Fallback on original repository when a mirror doesn't resolve > > > > > > When maven is checking for a repository for an artefact, and using a > > > mirror - if that artefact can't be found, maven should retry using the > > > original repository directly with builds warnings. > > > > > > Very bad idea. Especially if the original repo is not/no longer reachable > > and you have to wait for a timeout. And you can no longer control with an > > Archive Manager what actually is used from where. > > > > > > > 2) Deploy transitive runtime dependencies along with your release > > > > > > We currently have the section of a pom > > > declaring the deploy repository. If we added a new > `deploy-dependencies` > > > goal to some plugin and updated maven-release-plugin with a this in its > > > default deployment goals, I think some magical things could happen: > > > > > >- Find the _runtime_ dependency tree of your project > > >- Check which artefacts don't exist on the deployment repo > > >- Deploy those artefacts out to the repository - essentially an > > > implicit mirroring your dependencies. > > > > > > At the same time, modify the POM reader to add the repository defined > in > > > `` as a `` for discovering > > > dependencies. > > > > > > Any thoughts on this? Since it's now 12:32am, _hopefully_ I'll be awake > > > in time to join the discussion tomorrow to raise this idea. > > > > > > And suddenly we have all kind of stuff in public repos that are not > allowed > > to be distributed. > > > > IMHO, the best option *is* actually to remove the elements. > > > > - Jörg > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: [RESULT] [VOTE] Release Maven 3.2.2
Okay, but let me explain how I got to that page :-) At the bottom of each of the version pages, there's a link to "all release notes". Go to the bottom of the 3.2.2 highlights (and other versions), and you'll see that. So that's a deadlink now and all these pages should be fixed. Cheers, Paul On Thu, Jun 26, 2014 at 8:44 AM, Jason van Zyl wrote: > No, I removed that page and replaced it with a list of pointers to the > release notes for a particular version. It should theoretically update > shortly. > > On Jun 26, 2014, at 9:39 AM, Paul Benedict wrote: > > > The only other page needing updating is this. We need the list of jira > > tickets for 3.2.2: > > http://maven.apache.org/release-notes-all.html > > > > > > Cheers, > > Paul > > > > > > On Thu, Jun 26, 2014 at 7:14 AM, Jason van Zyl wrote: > > > >> There, I checked in my solution which is to remove much of the redundant > >> information. There is also a large amount of duplication in the history > >> document and the all releases document. The historical information can > be > >> combined with the complete release history document. > >> > >> On Jun 26, 2014, at 2:05 AM, Michael Osipov > wrote: > >> > >>> Am 2014-06-24 13:08, schrieb Jason van Zyl: > Hi, > > The vote passed with the following result: > > +1 (binding): Jason van Zyl, Hervé Boutemy, Olivier Lamy, Arnaud > >> Héritier, Robert Scholte > +1 (non-binding): Karl-Heinz Marbaise, Mirko Friedenhagen, Mark > >> Derricutt, Igor Fedorenko, Baptiste Mathus > > I will finish the writeup of the release notes and promote to Maven > >> Central. Hervé can you publish the site please? > >>> > >>> http://maven.apache.org/release-notes-all.html still refers to 3.1. No > >> word about 3.2.1 or 3.2.2. > >>> > >>> Michael > >>> > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >> > >> Thanks, > >> > >> Jason > >> > >> -- > >> Jason van Zyl > >> Founder, Apache Maven > >> http://twitter.com/jvanzyl > >> http://twitter.com/takari_io > >> - > >> > >> There's no sense in being precise when you don't even know what you're > >> talking about. > >> > >> -- John von Neumann > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > Be not afraid of growing slowly, be only afraid of standing still. > > -- Chinese Proverb > > > > > > > > > >
Re: POM 5.0 and Maven.next idea - re: 's
I agree with Jorg. Furthermore, I have found repositories addresses change overtime. I *don't* want this information in the POM either because it becomes stale. It's not really build information, per se, as it is Maven connection information. I have to fallback to modifying my settings.xml when I encounter one of these situations -- which is "smell" enough of this very issue. Cheers, Paul On Thu, Jun 26, 2014 at 9:11 AM, Jörg Schaible wrote: > Hi Mark, > > Mark Derricutt wrote: > > > In last weeks dev hangout I raised the idea of removing > > elements due to some issues with them regarding mirrors etc which was > > somewhat negatively received, however I've been thinking about this a > > bit and came up with an interesting idea earlier in the night whilst at > > a gig. > > > > One of the problems I'm often seeing is that: > > > > 1) a project uploads their artefact to a repository ( mostly maven > > central ) > > 2) 90% of their dependencies are available from the repository in > > question > > 3) 1 critical dependency is not - which ultimately means you can't > > build..if you have a mirror setup > > > > (usually because you've not noticed a declaration which you > > need to configure in your nexus/arifactory/archiva etc. ) > > > > The idea I had is three fold: > > > > 1) Fallback on original repository when a mirror doesn't resolve > > > > When maven is checking for a repository for an artefact, and using a > > mirror - if that artefact can't be found, maven should retry using the > > original repository directly with builds warnings. > > > Very bad idea. Especially if the original repo is not/no longer reachable > and you have to wait for a timeout. And you can no longer control with an > Archive Manager what actually is used from where. > > > > 2) Deploy transitive runtime dependencies along with your release > > > > We currently have the section of a pom > > declaring the deploy repository. If we added a new `deploy-dependencies` > > goal to some plugin and updated maven-release-plugin with a this in its > > default deployment goals, I think some magical things could happen: > > > >- Find the _runtime_ dependency tree of your project > >- Check which artefacts don't exist on the deployment repo > >- Deploy those artefacts out to the repository - essentially an > > implicit mirroring your dependencies. > > > > At the same time, modify the POM reader to add the repository defined in > > `` as a `` for discovering > > dependencies. > > > > Any thoughts on this? Since it's now 12:32am, _hopefully_ I'll be awake > > in time to join the discussion tomorrow to raise this idea. > > > And suddenly we have all kind of stuff in public repos that are not allowed > to be distributed. > > IMHO, the best option *is* actually to remove the elements. > > - Jörg > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: POM 5.0 and Maven.next idea - re: 's
Hi Mark, Mark Derricutt wrote: > In last weeks dev hangout I raised the idea of removing > elements due to some issues with them regarding mirrors etc which was > somewhat negatively received, however I've been thinking about this a > bit and came up with an interesting idea earlier in the night whilst at > a gig. > > One of the problems I'm often seeing is that: > > 1) a project uploads their artefact to a repository ( mostly maven > central ) > 2) 90% of their dependencies are available from the repository in > question > 3) 1 critical dependency is not - which ultimately means you can't > build..if you have a mirror setup > > (usually because you've not noticed a declaration which you > need to configure in your nexus/arifactory/archiva etc. ) > > The idea I had is three fold: > > 1) Fallback on original repository when a mirror doesn't resolve > > When maven is checking for a repository for an artefact, and using a > mirror - if that artefact can't be found, maven should retry using the > original repository directly with builds warnings. Very bad idea. Especially if the original repo is not/no longer reachable and you have to wait for a timeout. And you can no longer control with an Archive Manager what actually is used from where. > 2) Deploy transitive runtime dependencies along with your release > > We currently have the section of a pom > declaring the deploy repository. If we added a new `deploy-dependencies` > goal to some plugin and updated maven-release-plugin with a this in its > default deployment goals, I think some magical things could happen: > >- Find the _runtime_ dependency tree of your project >- Check which artefacts don't exist on the deployment repo >- Deploy those artefacts out to the repository - essentially an > implicit mirroring your dependencies. > > At the same time, modify the POM reader to add the repository defined in > `` as a `` for discovering > dependencies. > > Any thoughts on this? Since it's now 12:32am, _hopefully_ I'll be awake > in time to join the discussion tomorrow to raise this idea. And suddenly we have all kind of stuff in public repos that are not allowed to be distributed. IMHO, the best option *is* actually to remove the elements. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven 3.2.2
No, I removed that page and replaced it with a list of pointers to the release notes for a particular version. It should theoretically update shortly. On Jun 26, 2014, at 9:39 AM, Paul Benedict wrote: > The only other page needing updating is this. We need the list of jira > tickets for 3.2.2: > http://maven.apache.org/release-notes-all.html > > > Cheers, > Paul > > > On Thu, Jun 26, 2014 at 7:14 AM, Jason van Zyl wrote: > >> There, I checked in my solution which is to remove much of the redundant >> information. There is also a large amount of duplication in the history >> document and the all releases document. The historical information can be >> combined with the complete release history document. >> >> On Jun 26, 2014, at 2:05 AM, Michael Osipov wrote: >> >>> Am 2014-06-24 13:08, schrieb Jason van Zyl: Hi, The vote passed with the following result: +1 (binding): Jason van Zyl, Hervé Boutemy, Olivier Lamy, Arnaud >> Héritier, Robert Scholte +1 (non-binding): Karl-Heinz Marbaise, Mirko Friedenhagen, Mark >> Derricutt, Igor Fedorenko, Baptiste Mathus I will finish the writeup of the release notes and promote to Maven >> Central. Hervé can you publish the site please? >>> >>> http://maven.apache.org/release-notes-all.html still refers to 3.1. No >> word about 3.2.1 or 3.2.2. >>> >>> Michael >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> - >> >> There's no sense in being precise when you don't even know what you're >> talking about. >> >> -- John von Neumann >> >> >> >> >> >> >> >> >> >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Be not afraid of growing slowly, be only afraid of standing still. -- Chinese Proverb
Re: [RESULT] [VOTE] Release Maven 3.2.2
The only other page needing updating is this. We need the list of jira tickets for 3.2.2: http://maven.apache.org/release-notes-all.html Cheers, Paul On Thu, Jun 26, 2014 at 7:14 AM, Jason van Zyl wrote: > There, I checked in my solution which is to remove much of the redundant > information. There is also a large amount of duplication in the history > document and the all releases document. The historical information can be > combined with the complete release history document. > > On Jun 26, 2014, at 2:05 AM, Michael Osipov wrote: > > > Am 2014-06-24 13:08, schrieb Jason van Zyl: > >> Hi, > >> > >> The vote passed with the following result: > >> > >> +1 (binding): Jason van Zyl, Hervé Boutemy, Olivier Lamy, Arnaud > Héritier, Robert Scholte > >> +1 (non-binding): Karl-Heinz Marbaise, Mirko Friedenhagen, Mark > Derricutt, Igor Fedorenko, Baptiste Mathus > >> > >> I will finish the writeup of the release notes and promote to Maven > Central. Hervé can you publish the site please? > > > > http://maven.apache.org/release-notes-all.html still refers to 3.1. No > word about 3.2.1 or 3.2.2. > > > > Michael > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > There's no sense in being precise when you don't even know what you're > talking about. > > -- John von Neumann > > > > > > > > > >
[GitHub] maven-wagon pull request: [WAGON-416] Correctly set proxyInfo in o...
GitHub user grgrzybek opened a pull request: https://github.com/apache/maven-wagon/pull/11 [WAGON-416] Correctly set proxyInfo in other varian of wagon.connect() You can merge this pull request into a Git repository by running: $ git pull https://github.com/grgrzybek/maven-wagon WAGON-416 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-wagon/pull/11.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #11 commit 53e666502080d6a9131b4aef43021dec5928977a Author: Grzegorz Grzybek Date: 2014-06-26T13:09:54Z [WAGON-416] Correctly set proxyInfo in other varian of wagon.connect() --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM 5.0 and Maven.next idea - re: 's
Hi, On Thu, Jun 26, 2014 at 2:34 PM, Mark Derricutt wrote: > In last weeks dev hangout I raised the idea of removing > elements due to some issues with them regarding mirrors etc which was > somewhat negatively received, however I've been thinking about this a bit > and came up with an interesting idea earlier in the night whilst at a gig. > > One of the problems I'm often seeing is that: > > 1) a project uploads their artefact to a repository ( mostly maven central > ) > 2) 90% of their dependencies are available from the repository in question > 3) 1 critical dependency is not - which ultimately means you can't > build..if you have a mirror setup > > (usually because you've not noticed a declaration which you > need to configure in your nexus/arifactory/archiva etc. ) > > The idea I had is three fold: > > 1) Fallback on original repository when a mirror doesn't resolve > > When maven is checking for a repository for an artefact, and using a > mirror - if that artefact can't be found, maven should retry using the > original repository directly with builds warnings. > Don't forget here that some companies will want to enforce (for various reasons) to use specific repository and only it. > > 2) Deploy transitive runtime dependencies along with your release > > We currently have the section of a pom declaring > the deploy repository. If we added a new `deploy-dependencies` goal to some > plugin and updated maven-release-plugin with a this in its default > deployment goals, I think some magical things could happen: > > - Find the _runtime_ dependency tree of your project > - Check which artefacts don't exist on the deployment repo > - Deploy those artefacts out to the repository - essentially an implicit > mirroring your dependencies. > > At the same time, modify the POM reader to add the repository defined in > `` as a `` for discovering dependencies. > My main concern with current POM entries about repositories is that we are hardcoding some information that may change in the future ( the repo moved, sources moved ...). Thus depending for what you are looking at an old POM it may be a problem or not. > > Any thoughts on this? Since it's now 12:32am, _hopefully_ I'll be awake in > time to join the discussion tomorrow to raise this idea. > > Cheers, > Mark > cheers -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
POM 5.0 and Maven.next idea - re: 's
In last weeks dev hangout I raised the idea of removing elements due to some issues with them regarding mirrors etc which was somewhat negatively received, however I've been thinking about this a bit and came up with an interesting idea earlier in the night whilst at a gig. One of the problems I'm often seeing is that: 1) a project uploads their artefact to a repository ( mostly maven central ) 2) 90% of their dependencies are available from the repository in question 3) 1 critical dependency is not - which ultimately means you can't build..if you have a mirror setup (usually because you've not noticed a declaration which you need to configure in your nexus/arifactory/archiva etc. ) The idea I had is three fold: 1) Fallback on original repository when a mirror doesn't resolve When maven is checking for a repository for an artefact, and using a mirror - if that artefact can't be found, maven should retry using the original repository directly with builds warnings. 2) Deploy transitive runtime dependencies along with your release We currently have the section of a pom declaring the deploy repository. If we added a new `deploy-dependencies` goal to some plugin and updated maven-release-plugin with a this in its default deployment goals, I think some magical things could happen: - Find the _runtime_ dependency tree of your project - Check which artefacts don't exist on the deployment repo - Deploy those artefacts out to the repository - essentially an implicit mirroring your dependencies. At the same time, modify the POM reader to add the repository defined in `` as a `` for discovering dependencies. Any thoughts on this? Since it's now 12:32am, _hopefully_ I'll be awake in time to join the discussion tomorrow to raise this idea. Cheers, Mark
Re: [RESULT] [VOTE] Release Maven 3.2.2
There, I checked in my solution which is to remove much of the redundant information. There is also a large amount of duplication in the history document and the all releases document. The historical information can be combined with the complete release history document. On Jun 26, 2014, at 2:05 AM, Michael Osipov wrote: > Am 2014-06-24 13:08, schrieb Jason van Zyl: >> Hi, >> >> The vote passed with the following result: >> >> +1 (binding): Jason van Zyl, Hervé Boutemy, Olivier Lamy, Arnaud Héritier, >> Robert Scholte >> +1 (non-binding): Karl-Heinz Marbaise, Mirko Friedenhagen, Mark Derricutt, >> Igor Fedorenko, Baptiste Mathus >> >> I will finish the writeup of the release notes and promote to Maven Central. >> Hervé can you publish the site please? > > http://maven.apache.org/release-notes-all.html still refers to 3.1. No word > about 3.2.1 or 3.2.2. > > Michael > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: [RESULT] [VOTE] Release Maven 3.2.2
I, or someone else, can make something to aggregate all the notes. For the 3.1.1 release it was a cutting/pasting exercise which seems useless. We don't need a markup file and a text file where it's primarily cut/paste. I think enumerating the versions and pointing at the markup is sufficient. I'll take a look over the preparation of the next release if no one else does. There's too much manual work for updating the site for a release. On Jun 26, 2014, at 2:05 AM, Michael Osipov wrote: > Am 2014-06-24 13:08, schrieb Jason van Zyl: >> Hi, >> >> The vote passed with the following result: >> >> +1 (binding): Jason van Zyl, Hervé Boutemy, Olivier Lamy, Arnaud Héritier, >> Robert Scholte >> +1 (non-binding): Karl-Heinz Marbaise, Mirko Friedenhagen, Mark Derricutt, >> Igor Fedorenko, Baptiste Mathus >> >> I will finish the writeup of the release notes and promote to Maven Central. >> Hervé can you publish the site please? > > http://maven.apache.org/release-notes-all.html still refers to 3.1. No word > about 3.2.1 or 3.2.2. > > Michael > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
Re: Evolving the POM format
In the case of a multi module build - or any reactor build I think a valid
rule would be all poms should be compatible with the maven version being
used.
Maybe even as far as to say the same version.
Mind you - I'm also largely of the opinion that support for multi module
should be deprecated/removed - but that's a separate story.
... Sent from Android
On 20/06/2014 3:51 am, "Stephen Connolly"
wrote:
> If backwards compatible interoperability is not a requirement then:
>
> If I upgrade one module in my multi-module build to Maven 5.1 then I am
> forced right then and there to either:
>
> * upgrade all of them to Maven 5.1; or
> * remove the module from my multi-module build
>
> Neither of these are a good user experience in my mind. Maven 5.1 should be
> able to build a Maven [2.0,5.1] project without modifying the pom... it can
> do that by loading shim layers on demand if necessary, but to my thinking
> anything less is going to cause issues for users.
>
>
> So to my thinking we just accept that Maven needs to evolve such that for
> every version X.Y of Maven you know that you can build a Maven project from
> the range [2.0,X.Y].
>
> If you have a project that has a parent, then the parent must be in a pom
> format that buildable by Maven [2.0,${project.prerequisites.maven}], so a
> child pom requiring Maven 5.1 to build can have a parent pom that requires
> Maven 5.0 to build but not a parent pom requiring Maven 5.2... there may
> even be turtles all the way down to an ancestor pom that requires Maven
> [2.0,3.0.3] to build (IIRC after 3.0.3 you get things like wildcards in
> excludes due to aether injecting "bonus" functionality... that should have
> been a modelVersion bump in the strictest sense... but well it wasn't)
>
> I also think people overestimate how difficult it is to maintain backwards
> compatibility.
>
> I have a Jenkins plugin that was written against Hudson 1.96 and I can take
> that .hpi file and drop it into Jenkins 1.568 and it still works
> unmodified. Similarly I can upgrade a Jenkins installation jumping quite a
> large number of versions without issue.
>
> It is possible to evolve and maintain the ability to read older data... is
> it easy? well it's not trivial, but it is a disservice to our users if we
> don't try
>
>
> On 19 June 2014 16:24, Paul Benedict wrote:
>
> > I am curious why you interoperability as a requirement? Perhaps
> questioning
> > that may seem outrageous, but I see no problem with saying that you need
> to
> > upgrade to Maven X.Y to read newer POM formats. If a vendor wants to
> > backport their project into older POM formats, that should be the
> vendor's
> > shoulders and not be a concern of Maven core. If Maven does publish older
> > formats of POMs, you then have to decide how many older formats do you
> want
> > to publish? One day there will be a 4.1 or 5.0, and it's going to
> > complicate the world if Maven takes on the burden of interoperability.
> >
> >
> > Cheers,
> > Paul
> >
> >
> > On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On 19 June 2014 15:48, Igor Fedorenko wrote:
> > >
> > > >
> > > >
> > > > On 2014-06-19, 10:30, Stephen Connolly wrote:
> > > >
> > > >> - Igor is*mostly* right in that we should not deploy the pom that
> is
> > > used
> > > >>
> > > >> to build to the repository...
> > > >> - Where Igor is wrong is that for pom we
> should
> > > >> actually deploy the build time pom to the repository... probably
> with
> > > the
> > > >> classifier `build`... this is safe as `pom` does cannot have a
> > > classifier
> > > >> in model version 4.0.0.
> > > >> - You couple that with a simple and obvious restriction... your
> parent
> > > >> must
> > > >> be the same or earlier version of Maven. You cannot have as a
> parent a
> > > >> newer version of Maven than the child is built with.
> > > >>
> > > >
> > > > I think there is more to this.
> > > >
> > > > At very least we need to decide what to do with in 4.0.0
> > > > compatible poms. Maybe we should always deploy effective pom with
> > > > build-related elements removed.
> > > >
> > >
> > > Well I think the simple thing is that the 4.0.0 pom is fully resolved
> > when
> > > you have a builder pom
> > >
> > >
> > > >
> > > > I am also not sure if it is enough to deploy "build" parent poms as
> is.
> > > > Your suggested "parent must be the same or earlier version of Maven"
> > > > implies new versions of Maven can read older pom formats, which I
> think
> > > > will significantly limit our flexibility to evolve pom format.
> > >
> > >
> > > They need to be able to parse it into the model. Perhaps they do the
> > > parsing by downloading a parser. But I think it is reasonable to expect
> > > that we can convert older build pom formats into newer ones and just
> let
> > > Maven take care of it... if we cannot do that then we are really
> > creating a
> > > brand new build tool rather than evolving Maven
> > >
>
Re: Evolving the POM format
I'm not sure I like the idea deploying a resolved/effective parent POM - simply because a parent is essentially the same as an abstract class or a template: it can't be used on its own. It's only non-parents that get build, get profiles activated on etc. ... Sent on android On 20/06/2014 2:48 am, "Igor Fedorenko" wrote: > > > On 2014-06-19, 10:30, Stephen Connolly wrote: > >> - Igor is*mostly* right in that we should not deploy the pom that is used >> to build to the repository... >> - Where Igor is wrong is that for pom we should >> actually deploy the build time pom to the repository... probably with the >> classifier `build`... this is safe as `pom` does cannot have a classifier >> in model version 4.0.0. >> - You couple that with a simple and obvious restriction... your parent >> must >> be the same or earlier version of Maven. You cannot have as a parent a >> newer version of Maven than the child is built with. >> > > I think there is more to this. > > At very least we need to decide what to do with in 4.0.0 > compatible poms. Maybe we should always deploy effective pom with > build-related elements removed. > > I am also not sure if it is enough to deploy "build" parent poms as is. > Your suggested "parent must be the same or earlier version of Maven" > implies new versions of Maven can read older pom formats, which I think > will significantly limit our flexibility to evolve pom format. I wonder > if we can have different solution for force parent poms, like > org.apache:apache, which are used by multiple projects and different > versions of maven and project-specific parent poms, where it is much > easier to require specific version of maven. > > -- > Regards, > Igor > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
