These are all discussions about abstractions we had when talking about Maven 1.x, so let me save you the circuitous route back to the fact that users don’t care about having an abstraction that lets them store artifacts as blobs in any potential systems coming from any potential source. People take artifacts from http servers and save them as files on disk. I think we would be better served evolving to the concrete thing it has actually become. To a Maven user it resolves artifacts, to someone who used Aether they resolved artifacts. What we see it as doesn’t matter, we know it does all sorts of things but apache-diritytree-selector-transformer-transporter-collector-resolver is probably not the best name. You are thinking about this too much. I’m a user, I resolve artifacts.
> On Aug 4, 2016, at 3:44 PM, Christian Schulte <[email protected]> wrote: > > If I wanted to store my artifacts in a database instead of putting files > into some well-known locations. Can I write an implementation of > 'RepositorySystem' which allows me to do that? No. It's way too > file-system based. A database would give me a blob. A path or a filename > is meaningless for the way artifacts are stored/accessed. I'd need to > convert that blob to a file locally when it needs to become part of some > classpath, for example. Speaking about "RepositorySystem", File or URL > is the wrong abstraction, in my opinion. A repository can be accessed > over the network (hostname and port) using a protocol. No URL involved. > No filesystem involved. Just thoughts. > > Regards, > -- > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
