Hi, I like the idea of simplification: I just factorized mavenVersion property to parent pom.
I have only one fear: what happens when the API changes in an incompatible way then we must release maven-artifact-resolver, then maven-resolver provider, then ant-tasks and demos. AFAIK, this chicken and egg issue is exactly why everything was released in 3 independent components (with associated complexity that I'd like also to remove) What about creating a "withMavenProvider" module where we could put ant tasks and demos, which would define the mavenVersion property? In case of such breaking change, we would just have to skip this module (and its sub-modules) for the API breaking release, then once the new compatible Maven provider is released, we could continue "the simple way" this would give us the benefit of being simple in general, and have just something a little more complex in special incompatible cases. Here, it would be "bizarre", since would bring a partial release for artifact resolver. Another "bizarre effect" of this way of releasing is: Artifact Resolver 1.1.1 will provide Ant Tasks and demos using Maven Resolver Provider 3.5.0, but Maven Resolver Provider 3.5.3 (or 3.6.0 or 4.0.0) will be the first using Artifact Resolver 1.1.1 Perhaps there is another simplification idea that would avoid this issue: - merge demos in artifact resolver master, since demos are never really released - let Ant Tasks in an independent branch (or component one day) Regards, Hervé Le jeudi 9 novembre 2017, 06:35:51 CET Manfred Moser a écrit : > Hi all, > > I have started and made good progress on getting Maven resolver all into the > master branch instead of having master, demos and ant-tasks in separate > branches. > > Details are tracked in https://issues.apache.org/jira/browse/MRESOLVER-28 > > All of it is now in a new branch called master-all for you to see. > > I am now wondering what the next steps are. I added what I think should > happen next in the issue in a comment and would appreciate any input on the > current setup and next steps. > > Any help would be appreciated. > > manfred > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
