On Thursday 28 July 2016, Jason van Zyl <ja...@takari.io> wrote: > What the external name is can be whatever people feel is most suitable. > > We should jump into IRC, as I think that will be faster, to figure out how > it should be used. > > I’m a vehement -1 to changing the artifactIds or structure without a plan. > We have to change the groupId because we cannot deploy into Eclipse’s > namespace but for anyone using this code just leave it how it is while > making improvements.
> As I understand it, they said that they were OK with giving us a temporary derogation to use the eclipse namespace as long as we made clear that this was not precedent setting and we were working in good faith to move off and the first indication of that good faith would be to change the name (even if we cannot change the other things just yet) As such I think we could actually deploy relocation poms in the eclipse groupId as a migration pathway... > > Consider it just moving the body of code from Eclipse because that’s all it > is right now. If we’re going to make changes to the API in a new package > space then just delegate to the Aether code, like we are doing in the core > right now and maybe even working from the core if possible. Shore up and > fix the usage in the core, we have artifact related code all over the place > doing duplicate things that we should consolidate too. Swizzling the Aether > code around and changing it all is not going to help anything at all. > Fixing bugs, great. Making additions that leave the library compatible yet > improve it, great. If it works in the core and works in the plugins it will > work for everyone else. > > The library as it stands functions and people are using it. We have > something in Maven core that uses it and it’s pretty terrible but it’s a > great place to start trying to flesh out something new because the ITs will > catch most things. There is also the questions of what kind of testing > harness we need because everyone is sort of looking at how these changes > affect the outcome but I think tools that perform deltas on the dirty tree > and final list with their scope transformations should be considered before > starting to fiddle with any existing Aether code. > > For now leave the Aether code in as close a state that from which it > arrived here from Eclipse. No one has touched this stuff for years, I can’t > see how anyone would think changing it all is a good idea because it’s not. > At any rate, a discussion is in order before any change to it’s structure > it made. > > > On Jul 28, 2016, at 12:24 PM, Christian Schulte <c...@schulte.it > <javascript:;>> wrote: > > > > Am 07/28/16 um 18:21 schrieb Christian Schulte: > >> Am 07/28/16 um 17:37 schrieb Andreas Sewe: > >>> Jason van Zyl wrote: > >>>> It’s all Maven specific, it’s always been Maven specific and that’s > >>>> unlikely to change after how many years? Even if it can employ > >>>> different strategies it’s still the Maven Artifact Resolution API. No > >>>> one is going to use this API to resolve from NuGet, NPMJS, PyPi or > >>>> anything else. Let’s just make it better for our specific use cases > >>>> instead of imagining this is going to be a general purpose tool. It > >>>> is clear that this never happened and probably never will. > >>> > >>> I think the confusion stems from the fact that there is both Maven (the > >>> tool) and the Maven repository format (the combination of directory > >>> structure, maven-metadata.xml, checksums files, etc.). > >>> > >>> The API we are talking about is for the Maven repository format and not > >>> some other repository format (like p2, NuGet, ...). It may be used by > >>> Maven *and* other tools (like Gradle, sbt, ...). In that sense, it is > >>> *not* specific to the Maven tool, but it is specific to the Maven > >>> repository format. Hence, calling it something with Maven in the name > >>> makes sense to me. > >> > >> +1 > >> > >>> FWIW, we (the Eclipse Code Recommenders project) have been using (first > >>> Sonatype, then Eclipse) Aether since ~2010 to download recommendation > >>> models stored in a repository which does follow the Maven repository > >>> format, but which does not store your typical artifacts (JARs with > >>> pom.xml). If that use case is still supported by the new API, I really > >>> don't care how the API is called. ;-) > >> > >> +1 > >> > >> It's an abstraction to access Maven(-format) repositories in a > >> consistent way. Project name could be "Maven Repositories" and the > >> artifacts could be > >> > >> maven-repositories-api > >> maven-repositories-impl > >> maven-repositories-utilities > >> etc. > >> > >> No need to add "API" to the project name. It's more than that. In the > >> end, it's just a name. We should avoid what was done in the past and try > >> to use a self-describing name. We had to tell people what "Aether" > >> stands for every now and then. This should be avoided. > >> > >> Regards, > >> > > > > Group-Id: org.apache.maven.shared.repositories > > Artifact-Id: maven-repositories-api, maven-repositories-impl, etc. > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> > > For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Takari and Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@maven.apache.org <javascript:;> > > -- Sent from my phone
