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 af
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 be
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
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...
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 plu
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 f
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 central
>>
>> Or so
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 coordinates and I happen
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
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
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 > wrote:
>
>> Am 09/28/16 um 04:48 schrieb Christi
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 thing to
> add
> >
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 you
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 art
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 mod
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
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 con
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
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
>
>
--
Sent from my phone
Am 09/26/16 um 15:29 schrieb Stephen Connolly:
>
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:
> >
> >
> >
> >
> > [...]
> > [...]
> > ...
> >
> >
> >
>
> groupId, artifactId an
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?
>
>
Here's an approximation of my current thinking:
[...]
[...]
...
...
...
23 matches
Mail list logo
