[GitHub] maven-surefire issue #110: SUREFIRE-1216: TEST-*.xml files generated by Sure...

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/110 @jonenst Next week on Friday it should be already in Maven Central. See the raod map [1]. We have last issue in good progress with 100% coverage of stream encoder and the only

Re: Taking Security Seriously

From: Bernd Eckenfels Sent: Monday, December 5, 2016 5:10 PM To: Maven Developers List Subject: Re: Taking Security Seriously Having artifact checksums (hashes not signatures) in POM dependency declarations would be cool, but that is

Re: Taking Security Seriously

Having artifact checksums (hashes not signatures) in POM dependency declarations would be cool, but that is not what .md5 or .asc is used for.  Gruss Bernd -- http://bernd.eckenfels.net On Mon, Dec 5, 2016 at 10:45 PM +0100, "Alexander Kjäll" wrote:

Re: Taking Security Seriously

Maybe we are talking about different attack scenarios? The vector I would like to protect against is that someone is able to inject false binaries in a caching nexus server (or over the network if https is not used). The way I envision the trust to be established is: The developer goes either

Re: [VOTE] Release Apache Maven Resources Plugin version 3.0.2

+1 On Mon, 05 Dec 2016 13:20:25 +0100, Christian Schulte wrote: Hi, We solved 3 issues: There are still a couple of issues left in JIRA:

Re: POM 5: The problems with mixins

On 6 Dec 2016, at 4:17, Jochen Wiedmann wrote: > You have personal experience with a feature, that doesn't even exist? > I am impressed... I need to read thru this thread fully and write up a longer response - but we've been using the tiles plugin ( which myself and Richard Vowles took over )

[GitHub] maven-surefire issue #110: SUREFIRE-1216: TEST-*.xml files generated by Sure...

Github user jonenst commented on the issue: https://github.com/apache/maven-surefire/pull/110 @Tibor17 Hi, thanks for the releases. Any idea of the release date ? Cheers. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well.

Re: Taking Security Seriously

I fear the proposed change would not improve security but lower it: if the pom contains the reference to a key "to be used to sign the artifact", anybody wanting to change the content will just change the key reference to a value it owns yes, knowing which keys you should trust to sign which

Re: POM 5: The problems with mixins

Stephen, One more slightly more abstract comment. Your design document seems like a survey of current maven design. I think it should be better to present several 3-4 current main pain points and/or much desired features at first and then show how each and every design alteration provides for

Re: POM 5: The problems with mixins

I haven't been following your proposals. I have schemed through just now. I can say that I generally like some aspects of your proposal: * build/artifact description split is a good thing. * custom lifecycle declaration is great. * building and reporting rejoin seems right I've fails to fully

Re: POM 5: The problems with mixins

Victor, have you been following my designs? https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0 https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema and https://cwiki.apache.org/confluence/display/MAVEN/Remote+repository+layout ? On 5 December

Re: POM 5: The problems with mixins

I've been experimenting with profile-based system that is close to mixins [1]. Another existing maven extension for this is maven-tiles [2]. I think your design is close to maven-tiles, so you can try to survey it's developers to get feedback based on actual usage... Personally after my

Re: POM 5: The problems with mixins

On Mon, Dec 5, 2016 at 3:31 PM, Chas Honton wrote: > My personal experience is that mixins lead to jar hell rather fast. You have personal experience with a feature, that doesn't even exist? I am impressed... Jochen -- The next time you hear: "Don't reinvent the wheel!"

Re: POM 5: The problems with mixins

Am 05.12.2016 um 16:03 schrieb Christian Schulte: > checkout the project for you automatically. You only need the "master" > POM and the first invocation of "mvn" will checkout the aggregator > automatically in some way. Just thoughts, though.) With this I am referring to what is called "build

Re: POM 5: The problems with mixins

Am 05.12.2016 um 15:31 schrieb Chas Honton: > What problems are you trying to solve with mixins? What is missing from the > current inheritance scheme? > > It appears to me that you are putting the "how before the "what". > > My personal experience is that mixins lead to jar hell rather fast.

Re: POM 5: The problems with mixins

What problems are you trying to solve with mixins? What is missing from the current inheritance scheme? It appears to me that you are putting the "how before the "what". My personal experience is that mixins lead to jar hell rather fast. Chas > On Dec 5, 2016, at 4:28 AM, Christian Schulte

Re: POM 5: The problems with mixins

Not having read all of this for now, but that's what I was referring to with "relaxing a constraint is easier than enforcing a new one". When in doubt how to process conflicting elements or something like that, just error out and fail the build with a descriptive error message. If we later find

[VOTE] Release Apache Maven Resources Plugin version 3.0.2

Hi, We solved 3 issues: There are still a couple of issues left in JIRA:

Re: Taking Security Seriously

Regarding verifying the gpg signature, as a contributor to the gpg verify plugin here: http://www.simplify4u.org/pgpverify-maven-plugin/index.html I have some thoughts on why the current infrastructure doesn't really help us to verify the signatures in practice: 1) Very hard to know what