Re: Project Dependency Trees schema...

2016-09-27 Thread Christian Schulte 
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 can use to identify the entity having produced an artifact
>> and useable to verify an artifact has not been modified as it has been
>> provided by that entity. Like a common name in a certificate. This
>> decouples things from location (repositories). There always needs to be
>> an entity claiming responsibility of an artifact/group of artifacts. We
>> have GPG signatures and jarsinger already. We maybe should decouple
>> artifacts from technologies like these and make that attributes (maybe
>> just one attribute: a common name like in a X.509 certificate) a
>> property of a projects' dependency trees file. So maybe those project
>> dependency trees files need to somehow hold some information about who
>> is to be claimed responsible for the trees. XMLDsig comes to mind.
>>
>> 
> 
> In the sense of: The location an artifact is retrieved from does not
> matter. The verifiable authorship related integrity of that artifact
> matters. Currently you can deploy unrelated artifacts to the same
> coordinates to various repositories. For example: The 'commons-lang'
> artifact jar file obtainable from repository A can contain completely
> different content compared to the 'commons-lang' artifact obtainable
> from repository B. There needs to be a way to express artifact
> responsibility so that an entity not responsible for an artifact cannot
> procude it. This is what I am heading after. There needs to be a way to
> verify that an artifact obtained from group id 'commons-lang' really
> contains content the entity responsible for artifacts of that group id
> claimed responsibility for. That's where the "resolve authoritative
> repositories from DNS TXT records based on group id" proposal came from.
> That's really a: Need a way to verify the artifact I obtained for
> coordinates XYZ really is the artifact the entity responsible for those
> coordinates has provided. I don't see a way to implement that in an
> artifact-self-contained way. Like a service you can post an artifact to
> asking for verification of the artifact to be identical to the artifact
> the orignal author has deployed.

So that whenever I see something like


  junit
  junit
  4.12
  test


I can be sure that this will always represent the exactly same files no
matter in what environment this declaration appears. There is only one
and only one 'junit:junit:4.12' artifact and that needs to be enforced
somehow. Currently it isn't.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Project Dependency Trees schema...

2016-09-27 Thread 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 can use to identify the entity having produced an artifact
> and useable to verify an artifact has not been modified as it has been
> provided by that entity. Like a common name in a certificate. This
> decouples things from location (repositories). There always needs to be
> an entity claiming responsibility of an artifact/group of artifacts. We
> have GPG signatures and jarsinger already. We maybe should decouple
> artifacts from technologies like these and make that attributes (maybe
> just one attribute: a common name like in a X.509 certificate) a
> property of a projects' dependency trees file. So maybe those project
> dependency trees files need to somehow hold some information about who
> is to be claimed responsible for the trees. XMLDsig comes to mind.
> 
> 

In the sense of: The location an artifact is retrieved from does not
matter. The verifiable authorship related integrity of that artifact
matters. Currently you can deploy unrelated artifacts to the same
coordinates to various repositories. For example: The 'commons-lang'
artifact jar file obtainable from repository A can contain completely
different content compared to the 'commons-lang' artifact obtainable
from repository B. There needs to be a way to express artifact
responsibility so that an entity not responsible for an artifact cannot
procude it. This is what I am heading after. There needs to be a way to
verify that an artifact obtained from group id 'commons-lang' really
contains content the entity responsible for artifacts of that group id
claimed responsibility for. That's where the "resolve authoritative
repositories from DNS TXT records based on group id" proposal came from.
That's really a: Need a way to verify the artifact I obtained for
coordinates XYZ really is the artifact the entity responsible for those
coordinates has provided. I don't see a way to implement that in an
artifact-self-contained way. Like a service you can post an artifact to
asking for verification of the artifact to be identical to the artifact
the orignal author has deployed.




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Project Dependency Trees schema...

2016-09-27 Thread 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 artifact
and useable to verify an artifact has not been modified as it has been
provided by that entity. Like a common name in a certificate. This
decouples things from location (repositories). There always needs to be
an entity claiming responsibility of an artifact/group of artifacts. We
have GPG signatures and jarsinger already. We maybe should decouple
artifacts from technologies like these and make that attributes (maybe
just one attribute: a common name like in a X.509 certificate) a
property of a projects' dependency trees file. So maybe those project
dependency trees files need to somehow hold some information about who
is to be claimed responsible for the trees. XMLDsig comes to mind.




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-plugins pull request #92: MDEPLOY-214: Added property "retryFailedDepl...

2016-09-27 Thread pabloa 
GitHub user pabloa opened a pull request:

https://github.com/apache/maven-plugins/pull/92

MDEPLOY-214: Added property "retryFailedDeploymentDelay" on 
maven-deploy-plugin

This property impose a delay between 0 seconds to 5 minutes (max)
between retries. Default value: 20 seconds. The intention is to
make maven-deploy-plugin more solid and stable when network
glitches happens.

ticket https://issues.apache.org/jira/browse/MDEPLOY-214
in maven-deploy-plugin has the details.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pabloa/maven-plugins MDEPLOY-214

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/92.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #92


commit f1a0513e371ba38e5bb07395a75a07c68eba7249
Author: Pablo Alcaraz 
Date:   2016-09-28T01:48:11Z

Added property "retryFailedDeploymentDelay".
This property impose a delay between 0 seconds to 5 minutes (max)
between retries. Default value: 20 seconds. The intention is to
make maven-deploy-plugin more solid and stable when network
glitches happens.

ticket https://issues.apache.org/jira/browse/MDEPLOY-214
in maven-deploy-plugin has the details.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-shared pull request #18: MDEPLOY-214: Added property "retryFailedDeplo...

2016-09-27 Thread pabloa 
GitHub user pabloa opened a pull request:

https://github.com/apache/maven-shared/pull/18

MDEPLOY-214: Added property "retryFailedDeploymentDelay".

This property impose a delay between 1 second to 5 minutes (max)
between retries. The intention is to make maven more
solid and stable when network glitches happens.

ticket https://issues.apache.org/jira/browse/MDEPLOY-214
in maven-deploy-plugin has the details.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pabloa/maven-shared MDEPLOY-214

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-shared/pull/18.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #18


commit 51c75a3deec743c02ab9ab80af11fbf8f874aaae
Author: Pablo Alcaraz 
Date:   2016-09-28T01:45:09Z

Added property "retryFailedDeploymentDelay".
This property impose a delay between 1 second to 5 minutes (max)
between retries. The intention is to make maven more
solid and stable when network glitches happens.

ticket https://issues.apache.org/jira/browse/MDEPLOY-214
in maven-deploy-plugin has the details.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

annotation to prevent parallel surefire execution

2016-09-27 Thread James Taylor 
Hello,
I noticed in the documentation here[1] that you can use
the @net.jcip.annotations.NotThreadSafe annotation to prevent a test class
from running in parallel. Is it also possible to use
the javax.annotation.concurrent.NotThreadSafe annotation in the same way as
I'd like to not have to introduce a new project dependency if possible.

Thanks,
James


[1]
http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html#Parallel_Test_Execution_and_Single_Thread_Execution

Re: Project Dependency Trees schema...

2016-09-27 Thread 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)

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 mandate such side-trees are single
platform only

On Tuesday 27 September 2016, Christian Schulte  wrote:

> 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 consuming project can be discarded. It may not
> be available for download for that project. The causing issue is the
> lack of artifactId or groupId authority. So as long as the coordinates
> cannot be used to map to a set of authoritative repositories, this
> information needs to be tracked somehow.
>
>
> Am 09/26/16 um 15:29 schrieb Stephen Connolly:
> > Here's an approximation of my current thinking:
> >
> > 
> > 
> > 
> > [...]
> > [...]
> > ...
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ...
> > 
> > 
> > 
> > 
> > ...
> > 
> > 
> >  > version="..." [range="..."] type="..." [classifier="..."]>
> > 
> > 
> >  [platformId="..."]
> > version="..." [range="..."] type="..." [classifier="..."]>
> > ...
> > 
> >  [platformId="..."]
> > version="..." [range="..."] type="..." [classifier="..."]>
> > ...
> > 
> > 
> > ...
> > 
> >  > version="..." [range="..."] type="..." [classifier="..."]>
> > ...
> > 
> > ...
> >  > version="..." [range="..."] type="..." [classifier="..."]>
> > ...
> > 
> > 
> >  > version="..." range="..." type="..." [classifier="..."]>
> > 
> > 
> >  [platformId="..."]
> > version="..." [range="..."] type="..." [classifier="..."]>
> > ...
> > 
> >  [platformId="..."]
> > version="..." range="..." type="..." [classifier="..."]>
> > ...
> > 
> >  [platformId="..."]
> > version="..." [range="..."] type="..." [classifier="..."]/>
> > 
> >  > version="..." range="..." type="..." [classifier="..."]>
> > ...
> > 
> > ...
> >  > version="..." range="..." type="..." [classifier="..."]>
> > ...
> > 
> > 
> >  > version="..." [range="..."] type="..." [classifier="..."]/>
> >  > version="..." [range="..."] type="..." [classifier="..."]/>
> >  > version="..." [range="..."] type="..." [classifier="..."]/>
> > 
> > 
> > ...
> > 
> > ...
> > 
> > ...
> > 
> > 
> > 
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> For additional commands, e-mail: dev-h...@maven.apache.org 
>
>

-- 
Sent from my phone