Am 08/21/16 um 14:36 schrieb Robert Scholte: > Hi, > > Keep in mind that Maven is not the only tool/application using the pom.xml.
Do they implement the import scope feature themselves? > Some of them probably never check the xsd or the modelVersion, so we need > to be very carefull with this. > If we introduce a new major modelVersion, that should probably result in a > new file including a backported to the current 4.0.0 so all tools will > keep working, including older versions of Maven. > In this case 4.1.0 doesn't change the xsd but the handling of > dependencies. I have no idea yet about the impact of such change. The last > thing we want is that it'll destroy the Maven repository eco system. Situation is this. I worked on the import scope due to issues in JIRA. I am not the reporter of those issues. During preliminary testing users asked to restore backwards compatibility. The reporters of those issues asked to not revert the new behaviour. I proposed to update the model version. Someone else asked to not do that. There is no consensus on anything now. Leave things in 3.4.0 the way they are. No. Revert the changes. No. Increase the model version. No. There is no other proposal I can make. Current master is solving all but the don't increase the model version objection just fine, in my opinion. Whatever you do. No. Do nothing! But that's not the build tool I would want to continue using. [...] > > Hervé and I plan to work on the consumer-pom, but that requires a good > roadmap. > First of all we need to separate the build-pom with the distribution-pom. Won't have an impact on the issues with the import scope. That is changing the way the effective 'dependenyManagement' is build. > Next we need to think of the consumer-pom. The idea of this file is that > it contains only relevant transitive information. [...] > Another advantage of this is that the file already contains the fully > resolved tree, so you don't depend on the implementation of any tool > anymore regarding resolution rules. Think about version ranges here. Resolving the dependency tree and deploying that resolution result would be ideal. Add version ranges to the mix and this becomes nearly impossible. Deploying the logic to get to that resolution result could work. You would need to invent some kind of artifact resolution scripting language for this. Let's just do that. > > What is important it that we must keep a pom in the repository > understandable for all other tools. If somehow the Maven repository > becomes useless by introducing changes to the current pom we shouldn't do > that, but think of a new file-format being extra installed/deployed. If someone upgrades a pom from model version 4.0.0 to 4.1.0 that person is just opting in for the new import scope behaviour. Information in the pom is just interpreted differently. Someone not wanting to deploy a model 4.1.0 pom can use the release:prepare-with-pom goal today. Does not stop users from deploying 4.1.0 poms, however. There are other things we already released years ago justifying a new minor model version. So maybe there is even more we can do for that model version in 3.4.0. I don't know yet. Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
