Re: Project Dependency Trees schema...

Am 09/29/16 um 19:34 schrieb Christian Schulte: > Am 09/29/16 um 19:13 schrieb Christian Schulte: >> >> I fail to come up with anything more appropriate than DNS TXT records to >> map coordinates/group ids to download locations in combination with >> DNSSEC. It's exactly the model we are heading

Re: Project Dependency Trees schema...

Am 09/29/16 um 19:13 schrieb Christian Schulte: > > I fail to come up with anything more appropriate than DNS TXT records to > map coordinates/group ids to download locations in combination with > DNSSEC. It's exactly the model we are heading after. This would make > signing/hashing superfluous

Re: Project Dependency Trees schema...

Am 09/28/16 um 23:23 schrieb Stephen Connolly: > So I am seeing conflicting requirements and I am unsure how we should > approach resolving them: > > 1. Seems perfectly reasonable to add some form of integrity details about > the *project's artifacts* into the PDT. Probably a SHA512 hash... Adds

Re: Project Dependency Trees schema...

So I am seeing conflicting requirements and I am unsure how we should approach resolving them: 1. Seems perfectly reasonable to add some form of integrity details about the *project's artifacts* into the PDT. Probably a SHA512 hash... 2. We could probably add the SHA512 hashes of dependencies...

Re: Project Dependency Trees schema...

Besides adding the original repository somewhere I would like to add the file-extension. Now you are required to translate the type to the extension based on the ArtifactHandler, which is a waste of time in this case. During build it is indeed good to use packaging, so you can control the

Re: Project Dependency Trees schema...

Or we say that repositories must be self-consistent and include a "sources" metadata at the root. If I resolve A from central and B from corp-proxy... B may list central' ID as an aggregated source, in which case it doesn't matter if the artifact is in both A and B, we can just take the artifact

Re: Project Dependency Trees schema...

Am 09/28/16 um 19:27 schrieb Stephen Connolly: > On Wednesday 28 September 2016, Christian Schulte wrote: > >> Am 09/28/16 um 08:25 schrieb Stephen Connolly: >>> So if we provide a way to decentralise. >> >> We do already. >> >>> >>> So now junit hosts their own artifacts, not

Re: Project Dependency Trees schema...

On Wednesday 28 September 2016, Christian Schulte wrote: > Am 09/28/16 um 08:25 schrieb Stephen Connolly: > > So if we provide a way to decentralise. > > We do already. > > > > > So now junit hosts their own artifacts, not central > > Or some company hosts it at the same

Re: Project Dependency Trees schema...

Am 09/28/16 um 08:25 schrieb Stephen Connolly: > So if we provide a way to decentralise. We do already. > > So now junit hosts their own artifacts, not central Or some company hosts it at the same coordinates and I happen to need to add that repository to a project of mine. > Now the absolute

Re: Project Dependency Trees schema...

Stephen Connolly wrote: > I am toying with having the format be xml.gz rather than xml > OTOH transport GZ should be easy and makes the file easier for users > to > inspect > > Thought? If you mean by "transport GZ", serving the XML with "Content-Encoding: gzip" by the repository manager, than

Re: Project Dependency Trees schema...

What happens if I want to use an in-house patch build of junit? I will not have the same origin... On Wednesday 28 September 2016, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > > > On Wednesday 28 September 2016, Christian Schulte

Re: Project Dependency Trees schema...

On Wednesday 28 September 2016, Christian Schulte wrote: > Am 09/28/16 um 04:48 schrieb Christian Schulte: > > Am 09/28/16 um 04:16 schrieb Christian Schulte: > >> Am 09/27/16 um 15:24 schrieb Stephen Connolly: > >>> I think that may be problematic... but probably not the worst

Re: Project Dependency Trees schema...

Am 09/28/16 um 04:48 schrieb Christian Schulte: > Am 09/28/16 um 04:16 schrieb Christian Schulte: >> Am 09/27/16 um 15:24 schrieb Stephen Connolly: >>> I think that may be problematic... but probably not the worst thing to add >>> to the schema (would just be an extra attribute) >> >> Something

Re: Project Dependency Trees schema...

Am 09/28/16 um 04:16 schrieb Christian Schulte: > Am 09/27/16 um 15:24 schrieb Stephen Connolly: >> I think that may be problematic... but probably not the worst thing to add >> to the schema (would just be an extra attribute) > > Something you can use to identify the entity having produced an

Re: Project Dependency Trees schema...

Am 09/27/16 um 15:24 schrieb Stephen Connolly: > I think that may be problematic... but probably not the worst thing to add > to the schema (would just be an extra attribute) Something you can use to identify the entity having produced an artifact and useable to verify an artifact has not been

Re: Project Dependency Trees schema...

I think that may be problematic... but probably not the worst thing to add to the schema (would just be an extra attribute) Btw an alternative schema has a top level tag as a container for the platform specific artifacts... has advantages with non-atomic deploys of different artifacts as you can

Re: Project Dependency Trees schema...

Just thinking about how different repositories can be handled. I think we should at least track the "origin" repository ids an artifact has been resolved from to have something to match against the effective repositories of a project. So that an artifact resolved from a repository not part of a

Re: Project Dependency Trees schema...

I am toying with having the format be xml.gz rather than xml JavaScript, Rubies, .NET and the JRE all have portable implementations so would seem reasonable given the high repeats in the content. OTOH transport GZ should be easy and makes the file easier for users to inspect Thought? On Monday

Re: Project Dependency Trees schema...

On Monday 26 September 2016, Christian Schulte wrote: > Am 09/26/16 um 15:29 schrieb Stephen Connolly: > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --

Re: Project Dependency Trees schema...

Am 09/26/16 um 15:29 schrieb Stephen Connolly: >

Re: Project Dependency Trees schema...

On Monday 26 September 2016, Christian Schulte wrote: > Am 26.09.2016 um 15:29 schrieb Stephen Connolly: > > Here's an approximation of my current thinking: > > > > > > > > > > [...] > > [...] > > ... > > > > > > > >

Re: Project Dependency Trees schema...

Am 26.09.2016 um 15:29 schrieb Stephen Connolly: > Here's an approximation of my current thinking: > > > > > [...] > [...] > ... > > > groupId, artifactId and version are the ones specified at level, correct? > >

Project Dependency Trees schema...

Here's an approximation of my current thinking: [...] [...] ... ... ...