Re: maven-3.x-jenkinsfile/MNG-6112 - build #1 - null

[Christian Schulte]

Am 03/21/17 um 03:57 schrieb Apache Jenkins Server:
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6112/1/
> 

Seems "null" does not always indicate a successful build. Can someone
take a look at this please and maybe update the Jenkinsfile to have a
subject indicating failures properly. This build job failed, right?

Regards,
-- 
Christian


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

Re: @since 3.5.0-alpha-2

[Christian Schulte]

Am 03/20/17 um 20:25 schrieb Stephen Connolly:
> Hervé requested to go straight to beta.
> 
> Since tags should be for the official release not alphas or betas imho

Ok. I'll update some since tags to 3.5.0 before the next release. No
need for a JIRA issue, right?

Regards,
-- 
Christian


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

Re: Maven Site / Report Plugins

[Hervé BOUTEMY]

ouch, "disabling" = "associating to an unknown phase": what a hack!
nice idea :)

there is no such phase association in reports: this hack for plugins can't be 
used with reports

What can be done is adding some reportExcludes in maven-site-plugin 
configuration: not so easy to configure and explain, but can be done without 
adding a parameter to every report plugin
Is this requirement worth the effort and complexity?

Regards,

Hervé

Le lundi 20 mars 2017, 09:05:07 CET Karl Heinz Marbaise a écrit :
> Hi Hervé,
> 
> On 20/03/17 08:31, Hervé BOUTEMY wrote:
> > adding a skip parameter to every plugin is a workaround: better than
> > nothing
> > 
> > should that be possible?
> > as a user, I want everything: I'd like it to be possible, or I'll be
> > frustrated because "Maven is inflexible" :)
> 
> ;-)
> 
> > the big question is more IMHO: is it possible to add this feature in a
> > consistent and easy to understand way?
> 
> Thats exactly the question I'm asking myself...
> 
> > When you say it is feasible with plugins, can you precise how, please?
> > We'll see if we can adpot the same way of doing with report plugins
> 
> Using an approach like this:
> 
>   
>  org.apache.maven.plugins
>  maven-enforcer-plugin
>  
>
>  enforce-maven
>  UNKNOWN
>
>  
>
> 
> This will just simply turn off maven-enforcer-plugin completely..
> 
> Only for the id you need to be very carefull...You can do the executions
> of this appropriate plugin and bind it to an unknown life cycle phase.
> 
> To be honest this feels like a Hack! The skip would be more convenient
> way from a user point of view but I think we need to reconsider this and
> a take deeper look and may be we find a better solution...
> 
> Kind regards
> Karl Heinz Marbaise
> 
> > Regards,
> > 
> > Hervé
> > 
> > Le lundi 20 mars 2017, 13:54:24 CET Maxim Solodovnik a écrit :
> >> Hello Karl,
> >> 
> >> I guess you can "skip" report for subproject?
> >> 
> >> On Mon, Mar 20, 2017 at 1:48 PM, Karl Heinz Marbaise 
> > 
> > wrote:
> >>> Hi Hervé,
> >>> 
> >>> On 19/03/17 23:39, Hervé BOUTEMY wrote:
>  That's the first time I see this part of the doc: defining an empty
>  reportSet
>  could remove a report plugin? I'm not convinced it ever worked.
> >>> 
> >>> Me neither and made the experience that this will not work.
> >>> 
> >>> But in the end this means a report can not being turned off in a sub
> >>> project...which in contradiction is possible with plugins..
> >>> 
> >>> So the question is: Should that be possible ?
> >>> 
> >>> Kind regards
> >>> Karl Heinz Marbaise
> >>> 
>  to me, it is inconsistent with following documentation, associated to
>  an
>  IT:
>  http://maven.apache.org/plugins/maven-site-plugin/
>  maven-3.html#Inheritance_of_reports_for_Maven_3_before_3.0.4
>  
>  Reports are additive: they were not in Maven 3.0 to 3.0.3, and it was
>  identified as a bug.
>  
>  Regards,
>  
>  Hervé
>  
>  Le dimanche 19 mars 2017, 11:28:06 CET Karl Heinz Marbaise a écrit :
> > Hi,
> > 
> > currently I stumbled over a thing which I don't understand.
> > 
> > I have parent pom[1] which defines several parts of a site including
> > some reports for example maven-changes-plugin with github-report..
> > 
> > Now I inherit from that parent pom and of course I can do a mvn site.
> > 
> > But now the important part.
> > 
> > I would like to deactive maven-changes-plugin in particular
> > github-report...cause this test project does not has a github repo
> > which
> > will fail the mvn site build..
> > 
> > I have taken a look into the documentation[2] to find a way to
> > deactive
> > github-report or maven-changes-plugin at all...I tried to change
> > maven-project-info-reports parts etc. but without any luck..
> > 
> > Does someone has a good hint how to do this ?
> > 
> > Kind regards
> > Karl Heinz Marbaise
> > 
> > [1]: https://github.com/khmarbaise/smpp/blob/master/pom.xml
> > [2]: http://maven.apache.org/pom.html#Reporting
> >>> 
> >>> -
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: @since 3.5.0-alpha-2

[Hervé BOUTEMY]

even if we call the release beta-1, since alpha-2 is not wrong

and in the long term, we don't care about alphas or betas

Regards,

Hervé

Le lundi 20 mars 2017, 19:25:53 CET Stephen Connolly a écrit :
> Hervé requested to go straight to beta.
> 
> Since tags should be for the official release not alphas or betas imho
> 
> On Mon 20 Mar 2017 at 18:48, Christian Schulte  wrote:
> > There will be no alpha-2? Should I update those @since tags to match the
> > new beta-1 name? Maybe something to add to the other discussions.
> > 
> > Regards,
> > --
> > Christian
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > --
> 
> Sent from my phone



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

[GitHub] maven-indexer pull request #16: MINDEXER-102 - indexer-reader OSGI changes f...

[sesuncedu]

GitHub user sesuncedu opened a pull request:

https://github.com/apache/maven-indexer/pull/16

MINDEXER-102 - indexer-reader OSGI changes forward ported to master

Forward ports index-reader changes from MINDEXER-97. 

Requires/includes  MINDEXER-100, which forward ports other changes from 5.x 
to master. 

New commit is 
https://github.com/sesuncedu/maven-indexer/commit/171f0902f9424c8fed8bc6ca4f62eec6fa1759c6

Does not include MINDEXER-101, which forwards ports other OSGI related 
changes from MINDEXER-97. 

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

$ git pull https://github.com/sesuncedu/maven-indexer MINDEXER-102

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

https://github.com/apache/maven-indexer/pull/16.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 #16


commit 3f85beae30e75e982d28dce11ba4c0121254fcf7
Author: Tamas Cservenak 
Date:   2015-10-30T23:10:13Z

MINDEXER-94: Temp file cleanup on errors

(cherry picked from commit 7a0e7ad)

commit 897a6b011945e13d5fdbf34ddcbb2c9d0a0ad345
Author: Tamas Cservenak 
Date:   2015-10-31T00:05:08Z

Add Idea iml files to rat exclude

(cherry picked from commit 0f17245)

commit d4fb8373171bc343e98cf3c7dbbc7bef37ca8cec
Author: Tamas Cservenak 
Date:   2015-10-31T00:15:45Z

MINDEXER-95: Suboptimal indexing execution in updater

(cherry picked from commit c193888)

(sesunc...@gmail.com:
Removed call to optimize in NexusIndexWriter.
Merged config setup in NexusIndexWriter.
Kept increased gzip block size in IndexDataReader.

commit 5645ce868e3aadbff44a6a86e44b6ce5b2549123
Author: Tamas Cservenak 
Date:   2015-10-31T00:29:30Z

MINDEXER-96: Indexer reader

(cherry picked from commit af8783d)

commit 2848b0d2b72b7c1a2ea2df695f9bbebfda53e184
Author: Tamas Cservenak 
Date:   2015-11-03T11:28:41Z

Added index writer, that writes single chunk for now

(cherry picked from commit b9c4d90)

commit 26cbb0df8d3f358a7456086e9a18ab774725461b
Author: Tamas Cservenak 
Date:   2015-11-03T13:23:32Z

MINDEXER-96: Indexer reader and writer

(cherry picked from commit 5c75bba)

commit db9ab5080495058f50ccb2dcdb4d197feddc8466
Author: Tamas Cservenak 
Date:   2015-11-03T15:38:26Z

INDEXER-96: Fix iterators

(cherry picked from commit be227e2)

commit 6c905500423a324750f8c5256e6bd69b0083c640
Author: Tamas Cservenak 
Date:   2015-11-05T09:53:26Z

Cleanup

(cherry picked from commit c3431b6)

commit 6fc7a9661f3c5349a74f2f7eedbd25bb2d4eb43c
Author: Tamas Cservenak 
Date:   2015-11-05T12:53:34Z

Make the reader an osgi bundle

(cherry picked from commit 4c5d1d6)

commit 732fdbf82efe9f9412cd8d47c13e7431af4b9728
Author: Tamas Cservenak 
Date:   2015-11-05T14:36:13Z

rename helper class to avoid name clash with other utilities

(cherry picked from commit 4333789)

commit 62cdc3bd3cc7b18c54ee5b02f92f43ac28bbbac0
Author: Tamas Cservenak 
Date:   2015-11-11T20:11:06Z

Fix classifier separator

(cherry picked from commit ea1205e)

commit b680ab2bbc798f378ac7a65c738e0c9a2fe81813
Author: Tamas Cservenak 
Date:   2015-11-12T10:30:50Z

Remove Transform, let user use any lib it wants to for iterable manipulation

Also, UTs got new TestUtils based on Guava

(cherry picked from commit e0570bf)

commit 4efc41f7310f61c23c1e7b91ce0055d581eb56f9
Author: Simon Spero 
Date:   2017-03-19T21:41:07Z

Minor build and test-resource fixes.

commit 171f0902f9424c8fed8bc6ca4f62eec6fa1759c6
Author: Simon Spero 
Date:   2017-03-20T21:10:05Z

MINDEXER-102 Forward port OSGI related index-reader changes to master 
(Changes relative to MINDEXER-100)




---
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-indexer pull request #15: MINDEXER-101 Forward port OSGI improvements ...

[sesuncedu]

GitHub user sesuncedu opened a pull request:

https://github.com/apache/maven-indexer/pull/15

MINDEXER-101 Forward port OSGI improvements to master branch

Forward port most OSGI related changes from 5.x to master branch.

Does not include changes to index-reader, as that requires MINDEXER-100 to 
be applied.

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

$ git pull https://github.com/sesuncedu/maven-indexer MINDEXER-101

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

https://github.com/apache/maven-indexer/pull/15.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 #15


commit 963eb1a2d5a72b9d9fde87188d71b7c834a8bf41
Author: Simon Spero 
Date:   2017-03-20T20:48:46Z

MINDEXER-101 Forward port OSGI improvements (MINDEXER-97) to master




---
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

Re: @since 3.5.0-alpha-2

[Stephen Connolly]

Hervé requested to go straight to beta.

Since tags should be for the official release not alphas or betas imho

On Mon 20 Mar 2017 at 18:48, Christian Schulte  wrote:

> There will be no alpha-2? Should I update those @since tags to match the
> new beta-1 name? Maybe something to add to the other discussions.
>
> Regards,
> --
> Christian
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

[Stephen Connolly]

+1

On 20 March 2017 at 18:18, Stephen Connolly  wrote:

> Analyzer...
>
> stagingUrl: https://repository.apache.org/content/repositories/maven-1325
> groupId: org.apache.maven
> artifactId: apache-maven
> version: 3.5.0-beta-1
>
> Source ZIP url exists.
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-src.zip
>
> Source ZIP SHA1 url exists.
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-src.zip.sha1
>
> Binary ZIP url exists.
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-bin.zip
>
> Binary ZIP SHA1 url exists.
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-bin.zip.sha1
>
> Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
> c4ea6e55687f4c02338490dbe99bab9eca027841
>
> Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
> 533bdef7d861179a5393578901999fa56fdd3f39
>
> Git revision of release as determined from maven-core-3.5.0-beta-1.jar:
> org/apache/maven/messages/build.properties(buildNumber):
> 214540c2ae5431645bb927d6dc5498ebafc27359
>
> Files that are present in the source distribution but not in the source
> revision:
> DEPENDENCIES
>
>
> On 20 March 2017 at 18:18, Stephen Connolly  com> wrote:
>
>> Hi,
>>
>> We solved 15 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>> ctId=12316922=12339665=Text
>>
>> There are still 10  issues left in JIRA for 3.5.0, but I do not think any
>> of those are blocking an beta release and perhaps could be descoped for
>> 3.5.0:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVer
>> sion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%20BY%20due%
>> 20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> In addition there are 313 issues left in JIRA for Maven core:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>> 20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1325
>>
>> The distributable binaries and sources for testing can be found here:
>> https://repository.apache.org/content/repositories/maven-132
>> 5/org/apache/maven/apache-maven/3.5.0-beta-1/
>>
>> Specifically the zip, tarball, and source archives can be found here:
>> https://repository.apache.org/content/repositories/maven-132
>> 5/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.
>> 5.0-beta-1-bin.zip
>> https://repository.apache.org/content/repositories/maven-132
>> 5/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.
>> 5.0-beta-1-bin.tar.gz
>> https://repository.apache.org/content/repositories/maven-132
>> 5/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.
>> 5.0-beta-1-src.zip
>> https://repository.apache.org/content/repositories/maven-132
>> 5/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.
>> 5.0-beta-1-src.tar.gz
>>
>> Source release checksum(s):
>> apache-maven-3.5.0-beta-1-src.tar.gz sha1: 6f24770bfff1882ab7ff7120cda677
>> 4332c452ff
>> apache-maven-3.5.0-beta-1-src.zip sha1: c4ea6e55687f4c02338490dbe99bab
>> 9eca027841
>>
>> Git tag:
>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit
>> ;h=214540c2ae5431645bb927d6dc5498ebafc27359
>>
>> Staging site:
>> https://maven.apache.org/components/ref/3-LATEST/
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>>
>> Thanks,
>> -Stephen
>>
>
>

@since 3.5.0-alpha-2

[Christian Schulte]

There will be no alpha-2? Should I update those @since tags to match the
new beta-1 name? Maybe something to add to the other discussions.

Regards,
-- 
Christian

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

[VOTE] Release Apache Maven 3.5.0-beta-1

[Stephen Connolly]

Hi,

We solved 15 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12339665=Text

There are still 10  issues left in JIRA for 3.5.0, but I do not think any
of those are blocking an beta release and perhaps could be descoped for
3.5.0:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

In addition there are 313 issues left in JIRA for Maven core:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Staging repo:
https://repository.apache.org/content/repositories/maven-1325

The distributable binaries and sources for testing can be found here:
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/

Specifically the zip, tarball, and source archives can be found here:
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-bin.zip
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-bin.tar.gz
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-src.zip
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-src.tar.gz

Source release checksum(s):
apache-maven-3.5.0-beta-1-src.tar.gz sha1:
6f24770bfff1882ab7ff7120cda6774332c452ff
apache-maven-3.5.0-beta-1-src.zip sha1:
c4ea6e55687f4c02338490dbe99bab9eca027841

Git tag:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=214540c2ae5431645bb927d6dc5498ebafc27359

Staging site:
https://maven.apache.org/components/ref/3-LATEST/

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


Thanks,
-Stephen

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

[Stephen Connolly]

Analyzer...

stagingUrl: https://repository.apache.org/content/repositories/maven-1325
groupId: org.apache.maven
artifactId: apache-maven
version: 3.5.0-beta-1

Source ZIP url exists.
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-src.zip

Source ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-src.zip.sha1

Binary ZIP url exists.
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-bin.zip

Binary ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-bin.zip.sha1

Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
c4ea6e55687f4c02338490dbe99bab9eca027841

Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
533bdef7d861179a5393578901999fa56fdd3f39

Git revision of release as determined from
maven-core-3.5.0-beta-1.jar:org/apache/maven/messages/build.properties(buildNumber):
214540c2ae5431645bb927d6dc5498ebafc27359

Files that are present in the source distribution but not in the source
revision:
DEPENDENCIES


On 20 March 2017 at 18:18, Stephen Connolly  wrote:

> Hi,
>
> We solved 15 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12316922=12339665=Text
>
> There are still 10  issues left in JIRA for 3.5.0, but I do not think any
> of those are blocking an beta release and perhaps could be descoped for
> 3.5.0:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%
> 20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> In addition there are 313 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1325
>
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/
>
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.0-beta-1-src.tar.gz sha1: 6f24770bfff1882ab7ff7120cda677
> 4332c452ff
> apache-maven-3.5.0-beta-1-src.zip sha1: c4ea6e55687f4c02338490dbe99bab
> 9eca027841
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 214540c2ae5431645bb927d6dc5498ebafc27359
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Thanks,
> -Stephen
>

Re: [2/2] maven git commit: [MNG-6069] Have to treat -D as taking a single argument or else any property with = in the name or = in the value will be mangled

[Karl Heinz Marbaise]

Hi Stephen,

so moving to maven-3.5.0 or later until will have correct working tests 
...and yes I see it the same having more tests to see where the real 
issue is located...


I will change the target version...

Kind regards
Karl Heinz Marbaise
On 20/03/17 16:29, Stephen Connolly wrote:

Nope... Nope... Nope...

System property parsing is not fixed...

May be better to add some more tests to MavenCliTest so that this can be
iterated faster

On 20 March 2017 at 15:11, Stephen Connolly  wrote:


[MNG-6069] Have to treat -D as taking a single argument or else any
property with = in the name or = in the value will be mangled


Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/0cafb4c0
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/0cafb4c0
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/0cafb4c0

Branch: refs/heads/MNG-6069
Commit: 0cafb4c042da840d038d327b634619c9f26b6728
Parents: 04e67fd
Author: Stephen Connolly 
Authored: Mon Mar 20 15:09:38 2017 +
Committer: Stephen Connolly 
Committed: Mon Mar 20 15:09:38 2017 +

--
 .../src/main/java/org/apache/maven/cli/CLIManager.java|  2 +-
 .../src/main/java/org/apache/maven/cli/MavenCli.java  | 10
+-
 2 files changed, 2 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/maven/blob/0cafb4c0/m
aven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
--
diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
index 774dd0d..a474895 100644
--- a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
+++ b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
@@ -109,7 +109,7 @@ public class CLIManager
 options = new Options();
 options.addOption( Option.builder( HELP ).longOpt( "help"
).desc( "Display help information" ).build() );
 options.addOption( Option.builder( ALTERNATE_POM_FILE ).longOpt(
"file" ).hasArg().desc( "Force the use of an alternate POM file (or
directory with pom.xml)" ).build() );
-options.addOption( Option.builder( SET_SYSTEM_PROPERTY
).longOpt( "define" ).hasArgs().valueSeparator().desc( "Define a system
property" ).build() );
+options.addOption( Option.builder( SET_SYSTEM_PROPERTY
).longOpt( "define" ).hasArg().desc( "Define a system property" ).build() );
 options.addOption( Option.builder( OFFLINE ).longOpt( "offline"
).desc( "Work offline" ).build() );
 options.addOption( Option.builder( VERSION ).longOpt( "version"
).desc( "Display version information" ).build() );
 options.addOption( Option.builder( QUIET ).longOpt( "quiet"
).desc( "Quiet output - only show errors" ).build() );

http://git-wip-us.apache.org/repos/asf/maven/blob/0cafb4c0/m
aven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
--
diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
index f9eb17e..694f694 100644
--- a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
+++ b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
@@ -1671,15 +1671,7 @@ public class MavenCli
 {
 if ( CLIManager.SET_SYSTEM_PROPERTY.equals( opt.getOpt() ) )
 {
-String[] values = opt.getValues();
-if ( values.length == 1 )
-{
-setCliProperty( values[0], userProperties );
-}
-else
-{
-setCliProperty( values[0] + "=" + values[1],
userProperties );
-}
+setCliProperty( opt.getValue(), userProperties );
 }
 }




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

Re: [2/2] maven git commit: [MNG-6069] Have to treat -D as taking a single argument or else any property with = in the name or = in the value will be mangled

[Stephen Connolly]

Nope... Nope... Nope...

System property parsing is not fixed...

May be better to add some more tests to MavenCliTest so that this can be
iterated faster

On 20 March 2017 at 15:11, Stephen Connolly  wrote:

> If this does not fix the build then I am dropping this branch from the
> scope for Maven 3.5.0-beta-1
>
> If the build is fixed and all tests pass then we can include this... and
> fix any bugs found in a beta-2... hopefully no bugs will be found so we can
> call it 3.5.0 and move forward ;-)
>
> On 20 March 2017 at 15:09,  wrote:
>
>> [MNG-6069] Have to treat -D as taking a single argument or else any
>> property with = in the name or = in the value will be mangled
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/0cafb4c0
>> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/0cafb4c0
>> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/0cafb4c0
>>
>> Branch: refs/heads/MNG-6069
>> Commit: 0cafb4c042da840d038d327b634619c9f26b6728
>> Parents: 04e67fd
>> Author: Stephen Connolly 
>> Authored: Mon Mar 20 15:09:38 2017 +
>> Committer: Stephen Connolly 
>> Committed: Mon Mar 20 15:09:38 2017 +
>>
>> --
>>  .../src/main/java/org/apache/maven/cli/CLIManager.java|  2 +-
>>  .../src/main/java/org/apache/maven/cli/MavenCli.java  | 10
>> +-
>>  2 files changed, 2 insertions(+), 10 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/maven/blob/0cafb4c0/m
>> aven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> --
>> diff --git 
>> a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> index 774dd0d..a474895 100644
>> --- a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> +++ b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
>> @@ -109,7 +109,7 @@ public class CLIManager
>>  options = new Options();
>>  options.addOption( Option.builder( HELP ).longOpt( "help"
>> ).desc( "Display help information" ).build() );
>>  options.addOption( Option.builder( ALTERNATE_POM_FILE ).longOpt(
>> "file" ).hasArg().desc( "Force the use of an alternate POM file (or
>> directory with pom.xml)" ).build() );
>> -options.addOption( Option.builder( SET_SYSTEM_PROPERTY
>> ).longOpt( "define" ).hasArgs().valueSeparator().desc( "Define a system
>> property" ).build() );
>> +options.addOption( Option.builder( SET_SYSTEM_PROPERTY
>> ).longOpt( "define" ).hasArg().desc( "Define a system property" ).build() );
>>  options.addOption( Option.builder( OFFLINE ).longOpt( "offline"
>> ).desc( "Work offline" ).build() );
>>  options.addOption( Option.builder( VERSION ).longOpt( "version"
>> ).desc( "Display version information" ).build() );
>>  options.addOption( Option.builder( QUIET ).longOpt( "quiet"
>> ).desc( "Quiet output - only show errors" ).build() );
>>
>> http://git-wip-us.apache.org/repos/asf/maven/blob/0cafb4c0/m
>> aven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
>> --
>> diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
>> b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
>> index f9eb17e..694f694 100644
>> --- a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
>> +++ b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
>> @@ -1671,15 +1671,7 @@ public class MavenCli
>>  {
>>  if ( CLIManager.SET_SYSTEM_PROPERTY.equals( opt.getOpt() ) )
>>  {
>> -String[] values = opt.getValues();
>> -if ( values.length == 1 )
>> -{
>> -setCliProperty( values[0], userProperties );
>> -}
>> -else
>> -{
>> -setCliProperty( values[0] + "=" + values[1],
>> userProperties );
>> -}
>> +setCliProperty( opt.getValue(), userProperties );
>>  }
>>  }
>>
>>
>>
>

Re: [2/2] maven git commit: [MNG-6069] Have to treat -D as taking a single argument or else any property with = in the name or = in the value will be mangled

[Stephen Connolly]

If this does not fix the build then I am dropping this branch from the
scope for Maven 3.5.0-beta-1

If the build is fixed and all tests pass then we can include this... and
fix any bugs found in a beta-2... hopefully no bugs will be found so we can
call it 3.5.0 and move forward ;-)

On 20 March 2017 at 15:09,  wrote:

> [MNG-6069] Have to treat -D as taking a single argument or else any
> property with = in the name or = in the value will be mangled
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/0cafb4c0
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/0cafb4c0
> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/0cafb4c0
>
> Branch: refs/heads/MNG-6069
> Commit: 0cafb4c042da840d038d327b634619c9f26b6728
> Parents: 04e67fd
> Author: Stephen Connolly 
> Authored: Mon Mar 20 15:09:38 2017 +
> Committer: Stephen Connolly 
> Committed: Mon Mar 20 15:09:38 2017 +
>
> --
>  .../src/main/java/org/apache/maven/cli/CLIManager.java|  2 +-
>  .../src/main/java/org/apache/maven/cli/MavenCli.java  | 10 +-
>  2 files changed, 2 insertions(+), 10 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/0cafb4c0/
> maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> --
> diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> index 774dd0d..a474895 100644
> --- a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> +++ b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
> @@ -109,7 +109,7 @@ public class CLIManager
>  options = new Options();
>  options.addOption( Option.builder( HELP ).longOpt( "help" ).desc(
> "Display help information" ).build() );
>  options.addOption( Option.builder( ALTERNATE_POM_FILE ).longOpt(
> "file" ).hasArg().desc( "Force the use of an alternate POM file (or
> directory with pom.xml)" ).build() );
> -options.addOption( Option.builder( SET_SYSTEM_PROPERTY ).longOpt(
> "define" ).hasArgs().valueSeparator().desc( "Define a system property"
> ).build() );
> +options.addOption( Option.builder( SET_SYSTEM_PROPERTY ).longOpt(
> "define" ).hasArg().desc( "Define a system property" ).build() );
>  options.addOption( Option.builder( OFFLINE ).longOpt( "offline"
> ).desc( "Work offline" ).build() );
>  options.addOption( Option.builder( VERSION ).longOpt( "version"
> ).desc( "Display version information" ).build() );
>  options.addOption( Option.builder( QUIET ).longOpt( "quiet"
> ).desc( "Quiet output - only show errors" ).build() );
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/0cafb4c0/
> maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
> --
> diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
> b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
> index f9eb17e..694f694 100644
> --- a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
> +++ b/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
> @@ -1671,15 +1671,7 @@ public class MavenCli
>  {
>  if ( CLIManager.SET_SYSTEM_PROPERTY.equals( opt.getOpt() ) )
>  {
> -String[] values = opt.getValues();
> -if ( values.length == 1 )
> -{
> -setCliProperty( values[0], userProperties );
> -}
> -else
> -{
> -setCliProperty( values[0] + "=" + values[1],
> userProperties );
> -}
> +setCliProperty( opt.getValue(), userProperties );
>  }
>  }
>
>
>

Re: Maven Site / Report Plugins

[Karl Heinz Marbaise]

Hi Hervé,

On 20/03/17 08:31, Hervé BOUTEMY wrote:

adding a skip parameter to every plugin is a workaround: better than nothing

should that be possible?
as a user, I want everything: I'd like it to be possible, or I'll be
frustrated because "Maven is inflexible" :)


;-)



the big question is more IMHO: is it possible to add this feature in a
consistent and easy to understand way?


Thats exactly the question I'm asking myself...


When you say it is feasible with plugins, can you precise how, please?
We'll see if we can adpot the same way of doing with report plugins


Using an approach like this:

 
org.apache.maven.plugins
maven-enforcer-plugin

  
enforce-maven
UNKNOWN
  

  

This will just simply turn off maven-enforcer-plugin completely..

Only for the id you need to be very carefull...You can do the executions 
of this appropriate plugin and bind it to an unknown life cycle phase.


To be honest this feels like a Hack! The skip would be more convenient 
way from a user point of view but I think we need to reconsider this and 
a take deeper look and may be we find a better solution...


Kind regards
Karl Heinz Marbaise



Regards,

Hervé

Le lundi 20 mars 2017, 13:54:24 CET Maxim Solodovnik a écrit :

Hello Karl,

I guess you can "skip" report for subproject?

On Mon, Mar 20, 2017 at 1:48 PM, Karl Heinz Marbaise 

wrote:

Hi Hervé,

On 19/03/17 23:39, Hervé BOUTEMY wrote:

That's the first time I see this part of the doc: defining an empty
reportSet
could remove a report plugin? I'm not convinced it ever worked.


Me neither and made the experience that this will not work.

But in the end this means a report can not being turned off in a sub
project...which in contradiction is possible with plugins..

So the question is: Should that be possible ?

Kind regards
Karl Heinz Marbaise


to me, it is inconsistent with following documentation, associated to an
IT:
http://maven.apache.org/plugins/maven-site-plugin/
maven-3.html#Inheritance_of_reports_for_Maven_3_before_3.0.4

Reports are additive: they were not in Maven 3.0 to 3.0.3, and it was
identified as a bug.

Regards,

Hervé

Le dimanche 19 mars 2017, 11:28:06 CET Karl Heinz Marbaise a écrit :

Hi,

currently I stumbled over a thing which I don't understand.

I have parent pom[1] which defines several parts of a site including
some reports for example maven-changes-plugin with github-report..

Now I inherit from that parent pom and of course I can do a mvn site.

But now the important part.

I would like to deactive maven-changes-plugin in particular
github-report...cause this test project does not has a github repo which
will fail the mvn site build..

I have taken a look into the documentation[2] to find a way to deactive
github-report or maven-changes-plugin at all...I tried to change
maven-project-info-reports parts etc. but without any luck..

Does someone has a good hint how to do this ?

Kind regards
Karl Heinz Marbaise

[1]: https://github.com/khmarbaise/smpp/blob/master/pom.xml
[2]: http://maven.apache.org/pom.html#Reporting


-


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

Re: [DISCUSS] How to work with branches

[Hervé BOUTEMY]

+1 to the whole analysis on issue tracking vs scm

one addition: currently, our PR process is "asking for a second": IMHO, it 
works

Regards,

Hervé

Le dimanche 19 mars 2017, 22:27:20 CET Elliot Metsger a écrit :
> Just two cents from a long-time list lurker:
> 
> First, congrats on all the work done so far!  Monumental effort, and a
> well-deserved congratulations to everyone involved.
> 
> As a Release Manager,
> 
> > I cannot tell which branches on the CI server are targeted for the release
> > and which are "future work"
> 
> IMHO, this is the job of the issue tracking system.  It is the authority on
> what work is targeted for which release.  It is also the place where the
> impact or nature of the work is tracked (bug, feature enhancement, etc.),
> and whom is doing the work.  So I'm not sure that the CI server is the
> place where you would go *first* to see what branches are targeting which
> release.  Unfortunately, that process would first require searching the
> issue tracking system for issues targeting a certain release, and then each
> issue would have a link to the branch.
> 
> I see how a convention for naming branches could be helpful, but that seems
> a bit complex and requires everyone to comply with multiple rules (rules
> for the metadata required for an issue, which will have a link to the
> branch, and then rules for how a branch should be named).
> 
> I cannot tell who is responsible for which branches in order to know who to
> 
> > ask w.r.t. their status
> 
> Right; I think that's the responsibility of the issue tracker.  It knows
> what issues are being worked on for a release, and the release manager can
> use the issue tracker to see what is in-progress, and directly ask the
> developer who owns the issue.  No need to even look at the CI system.  But,
> each issue should have a link to the branch being used for the work, which
> could be used by the release manager if needed.
> 
> As a PMC member tasked with reviewing commits
> 
> > I cannot keep track of all the many commits and rebases
> 
> *If* the process is review then commit, a pull request would be opened by
> the owner of a branch against "master" (or whatever the target branch is).
> That is how a PMC member would know it is time to review a series of
> commits.  The owner of the branch would be responsible for insuring that it
> can apply cleanly to the target branch at any time.  For example, the owner
> of the branch opens a PR.  It must apply cleanly to the target branch at
> the time the PR is opened (i.e. the branch must be based on the tip of the
> target).  If, prior to merging the PR, the target branch progresses, the
> owner of the branch would need to rebase the branch and update the PR.
> 
> To me this seems like a clean separation of responsibilities.  The owner of
> a branch indicates that their work is ready for merging by requesting a
> PR.  It is the owner's responsibility to keep the PR current with respect
> to the target branch.  The PMC member or release manager is notified of the
> PR, and their responsibility is to perform a review, and either accept the
> merge request or ask for more changes (asking for more changes could mean:
> "please rebase this against the current tip of the target branch").
> 
> As PRs are accepted and merged into their target branches, the
> corresponding issues in the tracking system are updated with this
> information, and closed.
> 
> Having PRs that apply cleanly to the target branch also invites other
> developers who may not bear official responsibility, to attempt to build
> the branch and review the PR as well.  That is to say, cleanly applying PRs
> may have more eyes on them during the review process.
> 
> Just my thoughts!
> 
> > Proposal
> > 
> > 
> > 1. We should use a naming scheme for all branches. I am suggesting
> > owner/targetBranch/mng- - this gives me the information about who owns
> > the branch and where the branch is targeted for.
> > 
> > 2. We should have the Jenkinsfile build not just the head commit but the
> > head commit merged to the target branch for any branch following the
> > naming
> > scheme. We get the target branch from the naming scheme and by having the
> > build verify that the branch can be merged without conflict onto the
> > target
> > branch we remove the need for constant rebases
> > 
> > 3. We merge branches with an explicit merge commit and stop using
> > fast-forward merging only. Again this makes it easier to review and allows
> > the noisy branches to be quiet when looked at from the PoV of master
> > 
> > This will not solve all the issues, but it would solve the pain points I
> > have currently.
> > 
> > Now if others have a different PoV or a counter-proposal, please speak up!



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

Re: Maven Site / Report Plugins

[Jörg Schaible]

Hi,

Maxim Solodovnik wrote:

> then maybe copy/paste a little:
> 
> configure all necessary reports in parent pom (exclude github-report)
> Then add github-report to all child projects except one

or configure the github-report in the parent in a profile that is activated 
on existance of a "profiles/github" file. That is easier to maintain for 
multiple sub project requiring this report.

[snip]

Cheers,
Jörg


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

Re: [DISCUSS] How to work with branches

[Hervé BOUTEMY]

IMHO, we don't have sufficient *team focus* on one version: how could we have 
focus on multiple versions at the same time?

working on creating a scheme to let people work without the others on another 
objective (which is supposed to be "the next one") is a recipe for split 
developer efforts

Regards,

Hervé

Le lundi 20 mars 2017, 00:38:26 CET Christian Schulte a écrit :
> Am 03/19/17 um 18:34 schrieb Stephen Connolly:
> > Unlike the other discuss threads, I think I have some extra context that
> > means I am going to start from my proposal... or rather my requirements
> > and
> > then proposal to solve those requirements.
> > 
> > Requirements
> > ===
> > 
> > As a Release Manager,
> > 
> > I cannot tell which branches on the CI server are targeted for the release
> > and which are "future work"
> > 
> > I cannot tell who is responsible for which branches in order to know who
> > to
> > ask w.r.t. their status
> > 
> > As a PMC member tasked with reviewing commits
> > 
> > I cannot keep track of all the many commits and rebases
> > 
> > Proposal
> > 
> > 
> > 1. We should use a naming scheme for all branches. I am suggesting
> > owner/targetBranch/mng- - this gives me the information about who owns
> > the branch and where the branch is targeted for.
> 
> s/targetBranch/targetVersion/g
> 
> We currently have 3.5.0-SNAPSHOT on master. There is no way to create a
> branch for 3.5.1-SNAPSHOT today using that naming scheme. Today, master
> is at 3.5.0-SNAPSHOT, in one year master is at 3.6.0-SNAPSHOT. Creating
> a branch like schulte/master/MNG-6135 today, does not indicate the
> target version. The branch should be named schulte/3.6.0/MNG-6135. Not
> sure the name really is needed. Finding out about the author or
> committer is easy looking at the latest commits.
> 
> Regards,



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

Re: [DISCUSS] Towards a common understanding of things

[Hervé BOUTEMY]

one thing we need: common focus for some time

there are so many directions followed by so many people at the same time that 
nobody can't follow everything. And when it's about having Maven core evolve, 
this is critical to have many people review and evaluate (it's less critical 
for a plugin or even a shared component, that each plugin will upgrade or not)

we need to give some time to others on focused, well explained topics, to let 
them evaluate and test

Regards,

Hervé

Le lundi 20 mars 2017, 01:51:32 CET Christian Schulte a écrit :
> Am 03/20/17 um 01:47 schrieb Christian Schulte:
> > Am 03/20/17 um 01:11 schrieb Stephen Connolly:
> >> On Sun 19 Mar 2017 at 12:13, Stephen Connolly <
> >> 
> >> stephen.alan.conno...@gmail.com> wrote:
> >>> We need to define:
> >>> 
> >>> * what is a bug vs what is an rfe
> >>> 
> >>> * what are the different severities for bugs and rfes
> >> 
> >> S1: software is unusable, halts, crashes, or is inaccessible, resulting
> >> in
> >> a critical impact on the operation. No workaround is available
> >> 
> >> Examples:
> >> 
> >> Maven crashes on OS-X
> >> Maven goes into infinite loop when installing war artifacts
> >> 
> >> S2: software operates but due to an error, its operation is severely
> >> restricted. No workaround is available
> >> 
> >> Examples:
> >> 
> >> Maven deploys invalid/corrupt artifacts
> >> Maven silently skips tests without asking
> >> Maven ignores batch mode and auto-version submosules for a reactor with
> >> more than 20 modules to release
> >> 
> >> S3: software operates with limitations due to an error that is not
> >> critical
> >> to the overall operation. For example, a workaround forces a user to use
> >> a
> >> time-consuming procedure to operate the software, or removes a
> >> non-essential feature.
> >> 
> >> Examples:
> >> 
> >> Maven has started to prompt with Y/N for each test to be run when
> >> -DconfirmTests=false or when in batch mode.
> >> Maven is stuck logging at debug level
> >> 
> >> S4: software can be used with only slight inconvenience.
> >> 
> >> Examples:
> >> 
> >> Maven colour logging is broken.
> >> Maven is prompting to start execution at the start of the reactor when
> >> not
> >> in batch mode
> >> 
> >> Wdyt
> > 
> > Based on that, what severity would be assigned to the following issues?
> > This somehow lacks the "changes incorrect/unexpected/broken behaviour"
> > category we hopefully do not have to use that often. Some real-world
> > examples we can use to sort things out.
> > 
> > Bugs:
> > -
> > MRESOLVER-8
> > MRESOLVER-9
> > MNG-5359
> > MNG-5984
> > MNG-6114
> > MNG-6164
> > MNG-5227 (ModelBuilder part only - resolver does it since years)
> > MNG-5935
> > MNG-6135 (bug we discussed to death already)
> > 
> > RFEs:
> > -
> > MNG-4463 (or bug due to lack of support?)
> > MNG-5527 (or bug due to lack of support?)
> > MNG-5600 (or bug due to lack of support?)
> > MNG-5971 (currently a new scope - include)
> > MNG-5761+MRESOLVER-10 (or bug - current behaviour
> > unexpected/inconsistent with site)
> 
> Some of them available as pull requests already, in case you want to
> review the changes.
> 
> 
> 
> 
> Regards,



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

Re: Maven Site / Report Plugins

[Maxim Solodovnik]

then maybe copy/paste a little:

configure all necessary reports in parent pom (exclude github-report)
Then add github-report to all child projects except one

On Mon, Mar 20, 2017 at 2:19 PM, Karl Heinz Marbaise  wrote:
> Hi,
>
>
> On 20/03/17 07:54, Maxim Solodovnik wrote:
>>
>> Hello Karl,
>>
>> I guess you can "skip" report for subproject?
>
>
> In this case this is not possible cause I want to have the site except for
> the maven-changes-plugin ...(github-report cause I don't have a github
> project for it).
>
> Kind regards
> Karl Heinz Marbaise
>>
>>
>> On Mon, Mar 20, 2017 at 1:48 PM, Karl Heinz Marbaise 
>> wrote:
>>>
>>> Hi Hervé,
>>>
>>> On 19/03/17 23:39, Hervé BOUTEMY wrote:


 That's the first time I see this part of the doc: defining an empty
 reportSet
 could remove a report plugin? I'm not convinced it ever worked.
>>>
>>>
>>>
>>> Me neither and made the experience that this will not work.
>>>
>>> But in the end this means a report can not being turned off in a sub
>>> project...which in contradiction is possible with plugins..
>>>
>>> So the question is: Should that be possible ?
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>>

 to me, it is inconsistent with following documentation, associated to an
 IT:
 http://maven.apache.org/plugins/maven-site-plugin/
 maven-3.html#Inheritance_of_reports_for_Maven_3_before_3.0.4

 Reports are additive: they were not in Maven 3.0 to 3.0.3, and it was
 identified as a bug.

 Regards,

 Hervé

 Le dimanche 19 mars 2017, 11:28:06 CET Karl Heinz Marbaise a écrit :
>
>
> Hi,
>
> currently I stumbled over a thing which I don't understand.
>
> I have parent pom[1] which defines several parts of a site including
> some reports for example maven-changes-plugin with github-report..
>
> Now I inherit from that parent pom and of course I can do a mvn site.
>
> But now the important part.
>
> I would like to deactive maven-changes-plugin in particular
> github-report...cause this test project does not has a github repo
> which
> will fail the mvn site build..
>
> I have taken a look into the documentation[2] to find a way to deactive
> github-report or maven-changes-plugin at all...I tried to change
> maven-project-info-reports parts etc. but without any luck..
>
> Does someone has a good hint how to do this ?
>
> Kind regards
> Karl Heinz Marbaise
>
> [1]: https://github.com/khmarbaise/smpp/blob/master/pom.xml
> [2]: http://maven.apache.org/pom.html#Reporting
>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>>
>>
>



-- 
WBR
Maxim aka solomax

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

Re: [DISCUSS] How to work with branches

[Fred Cooke]

Because unless the unit test suite has 100% line and branch coverage, and
possibly various
other metrics, all of which are unfeasible for any real-world sized code
base, it could miss
something. The first line should/must (if you care) be manual integration
of the two change
sets, conflicting, or not. That's why! :-p

What you're suggesting is a good thing, however what you said was false or
at best misleading.

Part of the issue I see is that people keep rebasing so that they can be
sure their changes will merge without conflict.

I don't see that as an issue, I see that as due diligence and a wise thing
to do in a dynamic code base.



On 20 March 2017 at 20:15, Stephen Connolly  wrote:

> On Mon 20 Mar 2017 at 00:44, Fred Cooke  wrote:
>
> > Sounds like the solution is for people to use a different remote that you
> > don't feel personally responsible for checking every commit in. And to
> fix
> > the email system.
> >
> > Split emails for commits on master to everyone and a new list for other
> > branches.
> >
> > As for Jenkins validating a merge, that's rubbish. A merge, or a rebase,
> is
> > a human operation, even when the tool can do it "cleanly"/automatically.
> To
> > ignore this is to introduce subtle issues and breakages.
> >
>
> How is Jenkins checking that the branch merges cleanly rubbish?
>
> GitHub does that all the time for PRs
>
> Part of the issue I see is that people keep rebasing so that they can be
> sure their changes will merge without conflict.
>
> If Jenkins has tested that the changes will merge without conflict, no need
> to rebase and push the rebase just to get the test status updated...
> because it is updated.
>
> We cannot have Jenkins *push* the merge anywhere it would just be
> verifying that the merge is without conflict and "trivial"... and running
> the tests on the result
>
> >
> > On 20 March 2017 at 10:20, Stephen Connolly <
> > stephen.alan.conno...@gmail.com
> > > wrote:
> >
> > > On Sun 19 Mar 2017 at 20:05, Fred Cooke  wrote:
> > >
> > > > How are branches noisy? Promiscuous automated emails or some such?
> > >
> > >
> > > PMC (and committers too, but the buck stops at the PMC) are supposed to
> > > monitor the commits@m.a.o mailing list.
> > >
> > > Every time a branch is rebased... boom all the commits are emailed
> > *again*
> > >
> > >
> > > >
> > > > Surely you don't need to look at all branches unless you've been
> asked
> > to
> > > > pre-review something prior to fast-forward? Just the ones you're
> > > interested
> > > > in?
> > >
> > >
> > > Need to check for Apache license issues and other ill-defined criteria
> > >
> > >
> > > >
> > > > Naming scheme sounds sensible, however unless everyone is constantly
> > > > rebasing (or making a mess with merge) there's a solid chance they
> > won't
> > > > merge cleanly (which is a human operation).
> > >
> > >
> > > This is why Jenkins will validate the merge cleanly so that the human
> has
> > > an easy merge
> > >
> > >
> > > >
> > > > Also, unless you're talking about maven itself with multiple
> supported
> > > > versions, there should be exactly one target branch for most stuff,
> so
> > > I'd
> > > > say reorder your pattern to reduce base-level "noise", eg
> > > > target/owner/ticket-purpose
> > >
> > >
> > > Perhaps, though then a lot of branches will start with "master/"
> > >
> > > Otoh it does make it easier to find all targeting master...
> > >
> > >
> > > > On 20 March 2017 at 06:34, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com
> > > > > wrote:
> > > >
> > > > > Unlike the other discuss threads, I think I have some extra context
> > > that
> > > > > means I am going to start from my proposal... or rather my
> > requirements
> > > > and
> > > > > then proposal to solve those requirements.
> > > > >
> > > > > Requirements
> > > > > ===
> > > > >
> > > > > As a Release Manager,
> > > > >
> > > > > I cannot tell which branches on the CI server are targeted for the
> > > > release
> > > > > and which are "future work"
> > > > >
> > > > > I cannot tell who is responsible for which branches in order to
> know
> > > who
> > > > to
> > > > > ask w.r.t. their status
> > > > >
> > > > > As a PMC member tasked with reviewing commits
> > > > >
> > > > > I cannot keep track of all the many commits and rebases
> > > > >
> > > > > Proposal
> > > > > 
> > > > >
> > > > > 1. We should use a naming scheme for all branches. I am suggesting
> > > > > owner/targetBranch/mng- - this gives me the information about
> who
> > > > owns
> > > > > the branch and where the branch is targeted for.
> > > > >
> > > > > 2. We should have the Jenkinsfile build not just the head commit
> but
> > > the
> > > > > head commit merged to the target branch for any branch following
> the
> > > > naming
> > > > > scheme. We get the target branch from the naming scheme and by
> having
> > > the
> > > > > build verify that 

Re: [DISCUSS] Towards a common understanding of things

[Hervé BOUTEMY]

ok
there is only one additional point: when things were working previously 
because of special cases that were handled with specific code previously, the 
change has to be done with extra care: that's where the general intent of 
fixing things has the immediate opposite effect

Then always we careful on the idea of "fixing" when it comes to Maven core, 
since the effect is not always limited to the initial intend: there are so 
many plugins, so many situations

Regards,

Hervé

Le lundi 20 mars 2017, 00:20:33 CET Christian Schulte a écrit :
> Am 03/19/17 um 23:32 schrieb Hervé BOUTEMY:
> > for you, documentation is always right?
> > That's the first time I see that documentation is more important and
> > always
> > more accurate than how the tool works
> > 
> > If there is a discrepency between how the tool works and what is written
> > in
> > documentation, there is work to be done to define what part has to be
> > improved to match the other: I don't make any judgement on "fixing", just
> > that the bug is in the discrepency
> 
> That's what I meant with "when there is consensus the
> documentation/specification is stating the intended/correct behaviour"
> First thing to validate is the documentation/specification. If that is
> accurate, work on fixing code can be started. If that is not accurate,
> work on fixing the documentation can be started. Both bugs. Either in
> code or in documentation. That's mainly what I did on the pre-reset
> branches. Make the code match the documentation (site and javadoc) when
> I was sure the documentation is describing the expected behaviour and
> the reports in JIRA were backed by valid analysis or example projects
> demonstrating things are misbehaving.
> 
> Regards,



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

Re: Maven Site / Report Plugins

[Hervé BOUTEMY]

adding a skip parameter to every plugin is a workaround: better than nothing

should that be possible?
as a user, I want everything: I'd like it to be possible, or I'll be 
frustrated because "Maven is inflexible" :)

the big question is more IMHO: is it possible to add this feature in a 
consistent and easy to understand way?

When you say it is feasible with plugins, can you precise how, please?
We'll see if we can adpot the same way of doing with report plugins

Regards,

Hervé

Le lundi 20 mars 2017, 13:54:24 CET Maxim Solodovnik a écrit :
> Hello Karl,
> 
> I guess you can "skip" report for subproject?
> 
> On Mon, Mar 20, 2017 at 1:48 PM, Karl Heinz Marbaise  
wrote:
> > Hi Hervé,
> > 
> > On 19/03/17 23:39, Hervé BOUTEMY wrote:
> >> That's the first time I see this part of the doc: defining an empty
> >> reportSet
> >> could remove a report plugin? I'm not convinced it ever worked.
> > 
> > Me neither and made the experience that this will not work.
> > 
> > But in the end this means a report can not being turned off in a sub
> > project...which in contradiction is possible with plugins..
> > 
> > So the question is: Should that be possible ?
> > 
> > Kind regards
> > Karl Heinz Marbaise
> > 
> >> to me, it is inconsistent with following documentation, associated to an
> >> IT:
> >> http://maven.apache.org/plugins/maven-site-plugin/
> >> maven-3.html#Inheritance_of_reports_for_Maven_3_before_3.0.4
> >> 
> >> Reports are additive: they were not in Maven 3.0 to 3.0.3, and it was
> >> identified as a bug.
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le dimanche 19 mars 2017, 11:28:06 CET Karl Heinz Marbaise a écrit :
> >>> Hi,
> >>> 
> >>> currently I stumbled over a thing which I don't understand.
> >>> 
> >>> I have parent pom[1] which defines several parts of a site including
> >>> some reports for example maven-changes-plugin with github-report..
> >>> 
> >>> Now I inherit from that parent pom and of course I can do a mvn site.
> >>> 
> >>> But now the important part.
> >>> 
> >>> I would like to deactive maven-changes-plugin in particular
> >>> github-report...cause this test project does not has a github repo which
> >>> will fail the mvn site build..
> >>> 
> >>> I have taken a look into the documentation[2] to find a way to deactive
> >>> github-report or maven-changes-plugin at all...I tried to change
> >>> maven-project-info-reports parts etc. but without any luck..
> >>> 
> >>> Does someone has a good hint how to do this ?
> >>> 
> >>> Kind regards
> >>> Karl Heinz Marbaise
> >>> 
> >>> [1]: https://github.com/khmarbaise/smpp/blob/master/pom.xml
> >>> [2]: http://maven.apache.org/pom.html#Reporting
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: [DISCUSS] How to work with branches

[Karl Heinz Marbaise]

Hi,

On 19/03/17 18:34, Stephen Connolly wrote:

Unlike the other discuss threads, I think I have some extra context that
means I am going to start from my proposal... or rather my requirements and
then proposal to solve those requirements.

Requirements
===

As a Release Manager,

I cannot tell which branches on the CI server are targeted for the release
and which are "future work"


This question can simply being answered by using JIRA and see the 
roadmap...there you can see all the issues intended for that particular 
release...


If someone needs some special attention for a particular issue this can 
be done via the mailing listOr if the RM is unsure about the given 
state in JIRA just ask on the mailing list...






I cannot tell who is responsible for which branches in order to know who to
ask w.r.t. their status


I need to repeat this. This is documented in JIRA (assignee)...

Both the status of the branch that's what the issue status is intended 
for...Is it already closed/resolved ?...


It might be usefull to make a separation between closed/resolved for 
this purpose?


Maybe this could be improved to add an appriprate label to JIRA issue 
(something like ready-for-integration)??





As a PMC member tasked with reviewing commits

I cannot keep track of all the many commits and rebases


It is the responsibility of the appropriate owner of the branch 
(assignee) in JIRA...and not the release manager...(from my point of view).


Based on each commit message I get this gives me the opportunity to 
review a commit..


The problem at the moment that the rebased will produce a large number 
of emails.




Proposal


1. We should use a naming scheme for all branches. I am suggesting
owner/targetBranch/mng- - this gives me the information about who owns
the branch and where the branch is targeted for.


This means from my point of view duplicating the information which is 
already maintained in JIRA...





2. We should have the Jenkinsfile build not just the head commit but the
head commit merged to the target branch for any branch following the naming
scheme. We get the target branch from the naming scheme and by having the
build verify that the branch can be merged without conflict onto the target
branch we remove the need for constant rebases


The rebase part has the advantage that you can bring your code in sync 
with Master and in the end put the whole change into a single commit 
which is a very clean way.


Apart from that if you like to merge this change to an other branch a 
single commit can easily being cherry-picked to an other branch..using 
merge commits that is not that easy and a horror to follow such kind of 
history...





3. We merge branches with an explicit merge commit and stop using
fast-forward merging only. Again this makes it easier to review and allows
the noisy branches to be quiet when looked at from the PoV of master


This will produce a large number of merge commits which makes it hard to 
read the history. Just having a single commit (cherry-picked) which 
contains the whole implementation of a ticket/feature is much more cleaner.


So in the end the history will contain informations like this:

"Merge branch MNG-5634"...

and the commits contain:

"[MNG-5634] ..."

So the information about the branch MNG-5634 is useless cause the branch 
does not exist anymore. The information MNG-5634 is important part to 
make a relationship to jira...



A fast forward merge can also be done automatically with Jenkins...This 
can be done fully automatically based on a schema or triggered by a 
person manually...






This will not solve all the issues, but it would solve the pain points I
have currently.

Now if others have a different PoV or a counter-proposal, please speak up!




Kind regards
Karl Heinz Marbaise

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

Re: Maven Site / Report Plugins

[Karl Heinz Marbaise]

Hi,


On 20/03/17 07:54, Maxim Solodovnik wrote:

Hello Karl,

I guess you can "skip" report for subproject?


In this case this is not possible cause I want to have the site except 
for the maven-changes-plugin ...(github-report cause I don't have a 
github project for it).


Kind regards
Karl Heinz Marbaise


On Mon, Mar 20, 2017 at 1:48 PM, Karl Heinz Marbaise  wrote:

Hi Hervé,

On 19/03/17 23:39, Hervé BOUTEMY wrote:


That's the first time I see this part of the doc: defining an empty
reportSet
could remove a report plugin? I'm not convinced it ever worked.



Me neither and made the experience that this will not work.

But in the end this means a report can not being turned off in a sub
project...which in contradiction is possible with plugins..

So the question is: Should that be possible ?

Kind regards
Karl Heinz Marbaise




to me, it is inconsistent with following documentation, associated to an
IT:
http://maven.apache.org/plugins/maven-site-plugin/
maven-3.html#Inheritance_of_reports_for_Maven_3_before_3.0.4

Reports are additive: they were not in Maven 3.0 to 3.0.3, and it was
identified as a bug.

Regards,

Hervé

Le dimanche 19 mars 2017, 11:28:06 CET Karl Heinz Marbaise a écrit :


Hi,

currently I stumbled over a thing which I don't understand.

I have parent pom[1] which defines several parts of a site including
some reports for example maven-changes-plugin with github-report..

Now I inherit from that parent pom and of course I can do a mvn site.

But now the important part.

I would like to deactive maven-changes-plugin in particular
github-report...cause this test project does not has a github repo which
will fail the mvn site build..

I have taken a look into the documentation[2] to find a way to deactive
github-report or maven-changes-plugin at all...I tried to change
maven-project-info-reports parts etc. but without any luck..

Does someone has a good hint how to do this ?

Kind regards
Karl Heinz Marbaise

[1]: https://github.com/khmarbaise/smpp/blob/master/pom.xml
[2]: http://maven.apache.org/pom.html#Reporting



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








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

Re: [DISCUSS] How to work with branches

[Stephen Connolly]

On Mon 20 Mar 2017 at 00:44, Fred Cooke  wrote:

> Sounds like the solution is for people to use a different remote that you
> don't feel personally responsible for checking every commit in. And to fix
> the email system.
>
> Split emails for commits on master to everyone and a new list for other
> branches.
>
> As for Jenkins validating a merge, that's rubbish. A merge, or a rebase, is
> a human operation, even when the tool can do it "cleanly"/automatically. To
> ignore this is to introduce subtle issues and breakages.
>

How is Jenkins checking that the branch merges cleanly rubbish?

GitHub does that all the time for PRs

Part of the issue I see is that people keep rebasing so that they can be
sure their changes will merge without conflict.

If Jenkins has tested that the changes will merge without conflict, no need
to rebase and push the rebase just to get the test status updated...
because it is updated.

We cannot have Jenkins *push* the merge anywhere it would just be
verifying that the merge is without conflict and "trivial"... and running
the tests on the result

>
> On 20 March 2017 at 10:20, Stephen Connolly <
> stephen.alan.conno...@gmail.com
> > wrote:
>
> > On Sun 19 Mar 2017 at 20:05, Fred Cooke  wrote:
> >
> > > How are branches noisy? Promiscuous automated emails or some such?
> >
> >
> > PMC (and committers too, but the buck stops at the PMC) are supposed to
> > monitor the commits@m.a.o mailing list.
> >
> > Every time a branch is rebased... boom all the commits are emailed
> *again*
> >
> >
> > >
> > > Surely you don't need to look at all branches unless you've been asked
> to
> > > pre-review something prior to fast-forward? Just the ones you're
> > interested
> > > in?
> >
> >
> > Need to check for Apache license issues and other ill-defined criteria
> >
> >
> > >
> > > Naming scheme sounds sensible, however unless everyone is constantly
> > > rebasing (or making a mess with merge) there's a solid chance they
> won't
> > > merge cleanly (which is a human operation).
> >
> >
> > This is why Jenkins will validate the merge cleanly so that the human has
> > an easy merge
> >
> >
> > >
> > > Also, unless you're talking about maven itself with multiple supported
> > > versions, there should be exactly one target branch for most stuff, so
> > I'd
> > > say reorder your pattern to reduce base-level "noise", eg
> > > target/owner/ticket-purpose
> >
> >
> > Perhaps, though then a lot of branches will start with "master/"
> >
> > Otoh it does make it easier to find all targeting master...
> >
> >
> > > On 20 March 2017 at 06:34, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com
> > > > wrote:
> > >
> > > > Unlike the other discuss threads, I think I have some extra context
> > that
> > > > means I am going to start from my proposal... or rather my
> requirements
> > > and
> > > > then proposal to solve those requirements.
> > > >
> > > > Requirements
> > > > ===
> > > >
> > > > As a Release Manager,
> > > >
> > > > I cannot tell which branches on the CI server are targeted for the
> > > release
> > > > and which are "future work"
> > > >
> > > > I cannot tell who is responsible for which branches in order to know
> > who
> > > to
> > > > ask w.r.t. their status
> > > >
> > > > As a PMC member tasked with reviewing commits
> > > >
> > > > I cannot keep track of all the many commits and rebases
> > > >
> > > > Proposal
> > > > 
> > > >
> > > > 1. We should use a naming scheme for all branches. I am suggesting
> > > > owner/targetBranch/mng- - this gives me the information about who
> > > owns
> > > > the branch and where the branch is targeted for.
> > > >
> > > > 2. We should have the Jenkinsfile build not just the head commit but
> > the
> > > > head commit merged to the target branch for any branch following the
> > > naming
> > > > scheme. We get the target branch from the naming scheme and by having
> > the
> > > > build verify that the branch can be merged without conflict onto the
> > > target
> > > > branch we remove the need for constant rebases
> > > >
> > > > 3. We merge branches with an explicit merge commit and stop using
> > > > fast-forward merging only. Again this makes it easier to review and
> > > allows
> > > > the noisy branches to be quiet when looked at from the PoV of master
> > > >
> > > > This will not solve all the issues, but it would solve the pain
> points
> > I
> > > > have currently.
> > > >
> > > > Now if others have a different PoV or a counter-proposal, please
> speak
> > > up!
> > > >
> > >
> > --
> > Sent from my phone
> >
>
-- 
Sent from my phone

Re: Maven Site / Report Plugins

[Maxim Solodovnik]

Hello Karl,

I guess you can "skip" report for subproject?

On Mon, Mar 20, 2017 at 1:48 PM, Karl Heinz Marbaise  wrote:
> Hi Hervé,
>
> On 19/03/17 23:39, Hervé BOUTEMY wrote:
>>
>> That's the first time I see this part of the doc: defining an empty
>> reportSet
>> could remove a report plugin? I'm not convinced it ever worked.
>
>
> Me neither and made the experience that this will not work.
>
> But in the end this means a report can not being turned off in a sub
> project...which in contradiction is possible with plugins..
>
> So the question is: Should that be possible ?
>
> Kind regards
> Karl Heinz Marbaise
>
>
>>
>> to me, it is inconsistent with following documentation, associated to an
>> IT:
>> http://maven.apache.org/plugins/maven-site-plugin/
>> maven-3.html#Inheritance_of_reports_for_Maven_3_before_3.0.4
>>
>> Reports are additive: they were not in Maven 3.0 to 3.0.3, and it was
>> identified as a bug.
>>
>> Regards,
>>
>> Hervé
>>
>> Le dimanche 19 mars 2017, 11:28:06 CET Karl Heinz Marbaise a écrit :
>>>
>>> Hi,
>>>
>>> currently I stumbled over a thing which I don't understand.
>>>
>>> I have parent pom[1] which defines several parts of a site including
>>> some reports for example maven-changes-plugin with github-report..
>>>
>>> Now I inherit from that parent pom and of course I can do a mvn site.
>>>
>>> But now the important part.
>>>
>>> I would like to deactive maven-changes-plugin in particular
>>> github-report...cause this test project does not has a github repo which
>>> will fail the mvn site build..
>>>
>>> I have taken a look into the documentation[2] to find a way to deactive
>>> github-report or maven-changes-plugin at all...I tried to change
>>> maven-project-info-reports parts etc. but without any luck..
>>>
>>> Does someone has a good hint how to do this ?
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> [1]: https://github.com/khmarbaise/smpp/blob/master/pom.xml
>>> [2]: http://maven.apache.org/pom.html#Reporting
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



-- 
WBR
Maxim aka solomax

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

Re: Maven Site / Report Plugins

[Karl Heinz Marbaise]

Hi Hervé,

On 19/03/17 23:39, Hervé BOUTEMY wrote:

That's the first time I see this part of the doc: defining an empty reportSet
could remove a report plugin? I'm not convinced it ever worked.


Me neither and made the experience that this will not work.

But in the end this means a report can not being turned off in a sub 
project...which in contradiction is possible with plugins..


So the question is: Should that be possible ?

Kind regards
Karl Heinz Marbaise




to me, it is inconsistent with following documentation, associated to an IT:
http://maven.apache.org/plugins/maven-site-plugin/
maven-3.html#Inheritance_of_reports_for_Maven_3_before_3.0.4

Reports are additive: they were not in Maven 3.0 to 3.0.3, and it was
identified as a bug.

Regards,

Hervé

Le dimanche 19 mars 2017, 11:28:06 CET Karl Heinz Marbaise a écrit :

Hi,

currently I stumbled over a thing which I don't understand.

I have parent pom[1] which defines several parts of a site including
some reports for example maven-changes-plugin with github-report..

Now I inherit from that parent pom and of course I can do a mvn site.

But now the important part.

I would like to deactive maven-changes-plugin in particular
github-report...cause this test project does not has a github repo which
will fail the mvn site build..

I have taken a look into the documentation[2] to find a way to deactive
github-report or maven-changes-plugin at all...I tried to change
maven-project-info-reports parts etc. but without any luck..

Does someone has a good hint how to do this ?

Kind regards
Karl Heinz Marbaise

[1]: https://github.com/khmarbaise/smpp/blob/master/pom.xml
[2]: http://maven.apache.org/pom.html#Reporting



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