maven site generation: mvn clean install site

[Chris Graham]

Hi everyone,

I was doing some work on maven-release and I ran 'mvn clean install site'
on it (as I usually do), and the build fails with a velocity parsing error.

The fix was simple: upgrade fluido-skins from 1.3.1 to 1.7 in site.xml.

Looking at the jenkins build jobs, it looks like the site command is not
being run anymore (and the checkstyle etc reports are also not being run).
Apologies for playing catch up, but, did I miss something?

What is the expected state of the site output?

What is/is not meant to be run and reported upon via the site command?

TIA.

-Chris

Jenkins URL's

[Chris Graham]

Hi Everyone,

I've finally managed to get back to some maven dev work! :)

In looking through the pom's I can see that some of the links for Jira and
Jenkins are broken.

Have the jenkins servers and jobs finally established a final URL?

For example, the maven-release plugin:

current git value:

  
Jenkins
https://builds.apache.org/job/maven-release/
  

current jenkins value (proposed change):

  
Jenkins
https://builds.apache.org/job/maven-box/job/maven-release/
  

Some of the other plugins also use a view as well.

I'm happy to go through them all and update to what is necessary, but I
need to know if the current URL's are going to remain stable.

-Chris

Re: New Committers - community

[Mickael Istria]

On Saturday, December 29, 2018, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
>
> I think we could easily use TravisCI or one of the cloud CI vendors to
> perform trial builds of PRs on GitHub.


Good. So at this point, it's only a matter of writing a .travis.yaml file
in the repo, or is there anything else missing?


> What is of importance to the ASF is
> that the build of ASF hosted code are on ASF hosted hardware... until the
> PR is merged it is not ASF hosted code, it exists only on GitHub.
>

>From contributor and user POV, I think where the software is built and
where the code is hosted isn't important. So no issue if it's on ASF
Jenkins and hardware, but for PR trials, it seems like a constraint it'd be
sane to get rid of.


-- 
Mickael Istria
Eclipse IDE 
developer, for Red Hat Developers 

Re: VOTE] Release Maven Wagon version 3.3.0

[Michael Osipov]

Am 2018-12-27 um 23:21 schrieb Michael Osipov:

Hi,

We solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=12344436 



There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved 



Staging repo:
https://repository.apache.org/content/repositories/maven-1481/
https://repository.apache.org/content/repositories/maven-1481/org/apache/maven/wagon/wagon/3.3.0/wagon-3.3.0-source-release.zip 



Source release checksum(s):
wagon-3.3.0-source-release.zip
sha512: 
c467bf8d9f5b54602f53ed34e117753f48cf25b611c79dbbba55706ce34a6bb0dec65447a84d6dc5122615147fe4ce19102a94a37d4a0b3a15382aa7fdba7560 



Staging site:
https://maven.apache.org/wagon-archives/wagon-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


I'll let the vote open for a couple of more days because I cannot 
reproduce Dan's regression in 
https://jira.apache.org/jira/browse/WAGON-543. Maybe some one else can.


Michael

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

Re: New Committers - community

[Vladimir Sitnikov]

Stephen > Are you sure?

I've just created a dummy account and "approval" does not make merge button
magically appear.

If you have a couple of minutes, please make a PR (I'll approve it shortly)
to https://github.com/vlsi/KE-complex_modifications
Note: you can click "edit" button in GitHub UI for a random file, so you
don't really need to clone the project.

I've attached no_merge.png which is a screenshot of GitHub UI for PR
author. Apparently, there's no merge button.

Vladimir

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

Re: New Committers - community

[Vladimir Sitnikov]

Karl Heinz Marbaise > The user community is very big but unfortunately the
people who are
Karl Heinz Marbaise > willing to help is not that big...

Can I (ab)use the thread a bit?

One of the issues I run into with Maven is "it takes ages for repeated
build when nothing has changed".
Of course there are details, yet the final perception is like that.

I know Apache JMeter team sticks with Ant for a mere reason of fast builds
(even though it is way harder to configure in IDE)

Once upon a time I was bitten hard enough by Maven which always rebuilds
everything even for repeated builds, so I investigated the reason and
created https://issues.apache.org/jira/browse/CALCITE-484
The basic case is "jar is rebuilt due to resource was somehow modified".
Of course there are multiple offenders, however two cases come from
maven-resources-plugin and maven-remote-resources-plugin.

I've created a PR (in December 2014) to fix maven-remote-resources-plugin:
https://github.com/apache/maven-plugins/pull/40 (Avoid overwrite of the
destination file if the produced contents is the same), and it took just
FOUR years to release the new version of the plugin in October 2018.

The second offender is maven-filtering (
https://issues.apache.org/jira/browse/MSHARED-394 )
In a brief, maven-filtering rewrites the file not matter the contents. For
instance, when Maven copies resources, it compares timestamps, so it can
skip copy if the file is good enough.
However maven-filtering always writes the destination file, thus it
triggers jar rebuild, etc.

Frankly speaking, I'm proud of a trick in
https://github.com/apache/maven-plugins/pull/40 which keeps contents in
memory, and if the buffer overflows, then it writes the contents to the
destination file. In other words, no temporary files are required, and it
can skip file overwrites when the produced contents is the same.

I think similar should be done to DefaultMavenFileFilter, however Kristian
suggested he wanted to look on his own:

https://issues.apache.org/jira/browse/MSHARED-394?focusedCommentId=14449864=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14449864

>Kristian Rosenvold added a comment - 16/Dec/2014 12:19
>Haven given this issue some thought I believe I have come up with a
radically better solution than what is suggested here.
>There is no point in working on the changes suggested here,
>at least not until I give up my other plan.
>Since I am currently working on a slightly different task, it will be a
couple of weeks before I'll make any activity on this issue.


Frankly speaking, I'm very puzzled.
The net result is: my first Maven contribution (MRRESOURCES-91) took 4
years to release, and very similar one was rejected with "There is no point
in working on the changes suggested here" comment.
That is quite sad to be honest.

Vladimir

Re: New Committers - community

[Stephen Connolly]

On Sat, 29 Dec 2018 at 20:41, Mickael Istria  wrote:

> I'mglad to see that PR build/merge discussed, it seems to have a good
> potential value for many in simplifying it.
>
> FWIW, at Eclipse Foundation, similar questions were faced and risks
> identified. The result is that at the moment, all PRs from anyone can be
> built on Eclipse infra without much visible restriction. The Foundation
> might have extra guards under the hood but it's not something we developers
> need to care about.
> While this is probably unsafe, it's so far so good. We weren't warned by
> the Foundation about malicious usage of this permissive access to build
> machines.
>

As one of the primary developers of Jenkins and as a member of the Jenkins
CERT team I cannot and do not endorse that viewpoint. Unless and until ASF
infra has throw-away build machines, I do not recommend running CI builds
of PRs from unknown actors (it being trivial to set up a throw-away GitHub
account) on the ASF dedicated build agents. Eclipse is being fools if they
are allowing similar.


> AFAIK, there is no issue from developer POV about GitHub API rates limit.
> I suggest the Apache infra team gets in touch with Eclipse Foundation one
> to sort out whether similar configurations could be implemented in a
> safe-enough way.
>
> The GitHub PR builder plugin already has support for whitelisting users and
> giving them ability to trigger a build from a non-whitelidsted contributor
> with a single «test PR» comment or similar.
> Then build progress and report are reported as expected.
> And, again, TravisCI also does the same in a decent way, with the benefit
> of worrying less about underlying infra and security, and only drawback of
> being discoupled from a specific infra (is it really a drawback?)
>

I think we could easily use TravisCI or one of the cloud CI vendors to
perform trial builds of PRs on GitHub. What is of importance to the ASF is
that the build of ASF hosted code are on ASF hosted hardware... until the
PR is merged it is not ASF hosted code, it exists only on GitHub.


>
> Cheers,
>
>
> --
> Mickael Istria
> Eclipse IDE 
> developer, for Red Hat Developers 
>

Re: New Committers - community

[Stephen Connolly]

On Sat, 29 Dec 2018 at 18:56, Vladimir Sitnikov 
wrote:

> Stephen> Well on other GitHub orgs i’ve seen PR author has Merge
> button once PR is
> Stephen> approved by someone with push rights to the repo... until
> they add a commit
> Stephen> or the merge result changes
>
> It does not work the way you describe.
>
> 1) By default GitHub defaults to "Base permissions" == "read".
> Administrator can set even "base permissions == admin", however that
> is not something that comes by default.
> 2) Repository administrator can configure a branch so it requires a PR
> approval before merge (see
>
> https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
> )
>
> It might happen so that "author has Merge button" is a case when
> repository was configured with "default=write" permissions + "require
> PR approval".
> Indeed that should produce (I have not checked) the behavior you
> describe, however it was never a default mode for GiHub.
>
>
Are you sure? I have lots of repos on different orgs that I am in and for
almost all of them, if the repo is one where I only have read access I can
create the PR but the merge button is unavailable... until the PR is
approved by somebody *who has write permission*... at which point the merge
button magically becomes available to me...

Now you have to know to look out for it, because typically the owner of the
repo approves and then merges the PR in one go... and if I add a new commit
or resolve a merge conflict I lose the merge button until re-approved.

But for some organizations I am involved with, we have the culture of
allowing you to self-merge.

Oh and I know for a fact that these are at least some repos that do not
have branch protection turned on.


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

Re: New Committers - community

[Vladimir Sitnikov]

> And, again, TravisCI also does the same in a decent way, with the benefit
> of worrying less about underlying infra and security, and only drawback of
> being discoupled from a specific infra (is it really a drawback?)

Just in case: Apache Calcite uses both Travis CI and AppVeryor. It just
works.

It does simplify validation of the changes across various Java versions,
javadoc, RAT.
AppVeyor validates Windows builds.

Both results are automatically displayed at GitHub PR (e.g.
https://github.com/apache/calcite/pull/976) with no extra manual actions.

Vladimir

Re: Maven Core Release 3.6.1

[Mark Raynsford]

On 2018-12-29T21:04:33 +0100
Karl Heinz Marbaise  wrote:

> Hi to all,
> 
> I want to cut a Core Release within two weeks (about 14.01.2019) if that 
> is Ok for everyone? If any objections please raise your hand.

One for Hervé: Where did we leave things with MNG-6059? I ran into that
issue a while back where I was unable to deploy to Central with the new
attributes [0]. I've sort of been operating under the vague hope that
3.6.1 will allow me to both have those attributes inherited across all
my POMs from a single ancestor, and also to deploy those POMs to
Central. I'm fairly sure I tested a post-3.6.0 snapshot to verify that
the attributes were inherited (they weren't in 3.6.0), but my memory is
failing me...

[0] http://blog.io7m.com/2018/11/01/you-cannot-put-that-there.xhtml

-- 
Mark Raynsford | http://www.io7m.com



pgpXtivdG_XNi.pgp
Description: OpenPGP digital signature

Re: New Committers - community

[Mickael Istria]

I'mglad to see that PR build/merge discussed, it seems to have a good
potential value for many in simplifying it.

FWIW, at Eclipse Foundation, similar questions were faced and risks
identified. The result is that at the moment, all PRs from anyone can be
built on Eclipse infra without much visible restriction. The Foundation
might have extra guards under the hood but it's not something we developers
need to care about.
While this is probably unsafe, it's so far so good. We weren't warned by
the Foundation about malicious usage of this permissive access to build
machines.
AFAIK, there is no issue from developer POV about GitHub API rates limit.
I suggest the Apache infra team gets in touch with Eclipse Foundation one
to sort out whether similar configurations could be implemented in a
safe-enough way.

The GitHub PR builder plugin already has support for whitelisting users and
giving them ability to trigger a build from a non-whitelidsted contributor
with a single «test PR» comment or similar.
Then build progress and report are reported as expected.
And, again, TravisCI also does the same in a decent way, with the benefit
of worrying less about underlying infra and security, and only drawback of
being discoupled from a specific infra (is it really a drawback?)

Cheers,


-- 
Mickael Istria
Eclipse IDE 
developer, for Red Hat Developers 

Maven Core Release 3.6.1

[Karl Heinz Marbaise]

Hi to all,

I want to cut a Core Release within two weeks (about 14.01.2019) if that 
is Ok for everyone? If any objections please raise your hand.


currently I see in the JIRA the following issues open:

MNG-6530[1] which should be part of it (critical!)
MNG-6533[2]
MNG-6538[3] Upgrade to Maven Resolver version 1.3.2 (which is not yet 
released; I will take care of that)


Do we have other issue which should be made it into the possible new 
release ?


Kind regards
Karl Heinz Marbaise

[1]: https://issues.apache.org/jira/browse/MNG-6530
[2]: https://issues.apache.org/jira/browse/MNG-6533
[3]: https://issues.apache.org/jira/browse/MNG-6538

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

Re: New Committers - community

[Vladimir Sitnikov]

Stephen> Well on other GitHub orgs i’ve seen PR author has Merge
button once PR is
Stephen> approved by someone with push rights to the repo... until
they add a commit
Stephen> or the merge result changes

It does not work the way you describe.

1) By default GitHub defaults to "Base permissions" == "read".
Administrator can set even "base permissions == admin", however that
is not something that comes by default.
2) Repository administrator can configure a branch so it requires a PR
approval before merge (see
https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
)

It might happen so that "author has Merge button" is a case when
repository was configured with "default=write" permissions + "require
PR approval".
Indeed that should produce (I have not checked) the behavior you
describe, however it was never a default mode for GiHub.

Vladimir

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

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 18:19, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
>
> On Sat 29 Dec 2018 at 18:06, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
>> Stephen> Nah. Once committers have approved the PR then the PR can be
>> merged by the
>> Stephen> creator of the PR even if not a committer... at least that’s
>> the default
>> Stephen> way GitHub PRs work
>>
>> By default one needs push rights on the repository to merge PRs.
>> "Approval" changes nothing. "PR approval" does not differ from any
>> other comment.
>> In other words, non-committers can't merge PRs.
>
>
> Well on other GitHub orgs i’ve seen PR author has Merge button once PR is
> approved by someone with push rights to the repo... until they add a commit
> or the merge result changes
>

Gitbox may be configuring synchronised repos differently, but for interop
with the rest of GitHub we shouldn’t assume approval of a PR by committers
will not enable self-merging


>>
>> Vladimir
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> --
> Sent from my phone
>
-- 
Sent from my phone

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 18:06, Vladimir Sitnikov 
wrote:

> Stephen> Nah. Once committers have approved the PR then the PR can be
> merged by the
> Stephen> creator of the PR even if not a committer... at least that’s
> the default
> Stephen> way GitHub PRs work
>
> By default one needs push rights on the repository to merge PRs.
> "Approval" changes nothing. "PR approval" does not differ from any
> other comment.
> In other words, non-committers can't merge PRs.


Well on other GitHub orgs i’ve seen PR author has Merge button once PR is
approved by someone with push rights to the repo... until they add a commit
or the merge result changes

>
>
> Vladimir
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: New Committers - community

[Vladimir Sitnikov]

Stephen> Nah. Once committers have approved the PR then the PR can be
merged by the
Stephen> creator of the PR even if not a committer... at least that’s
the default
Stephen> way GitHub PRs work

By default one needs push rights on the repository to merge PRs.
"Approval" changes nothing. "PR approval" does not differ from any
other comment.
In other words, non-committers can't merge PRs.

Vladimir

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

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 17:16, Enrico Olivelli  wrote:

> Il sab 29 dic 2018, 17:25 Stephen Connolly <
> stephen.alan.conno...@gmail.com>
> ha scritto:
>
> > On Sat 29 Dec 2018 at 16:20, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > >
> > >
> > > On Sat 29 Dec 2018 at 15:18, Enrico Olivelli 
> > wrote:
> > >
> > >> Il sab 29 dic 2018, 15:17 Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com>
> > >> ha scritto:
> > >>
> > >> > There is a security issue with building PRs automatically.
> > >> >
> > >> > I can see about adding PR discovery to the existing ASF gitbox
> plugin,
> > >> but
> > >> > we’d need committers to ok the build and have reviewed the code as
> the
> > >> PR
> > >> > could contain attacks to be run from ASF hardware... which is why we
> > >> don’t
> > >> > build PRs at present.
> > >> >
> > >>
> > >> Now I have to review and then push to ASF repo and I have to tell to
> the
> > >> contributor that I will make CI start.
> > >> IMHO a good tradeoff is:
> > >> - a committer adds a 'test this please' comment, or '@asfbot test this
> > >> please' and then a CI job start
> > >> - this job updates the status line of the PR, with a link to the logs
> > and
> > >> the status of the job
> > >>
> > >> How does it sounds to you?
> > >
> > >
> > > Like it’ll burn through the GitHub api rate limit like crazy.
> >
>
> I did not think we have 100 repos
>
> > >
> > > The committer goes to Jenkins and clicks the build button on the PR job
> > > (which is sitting there ready and waiting), done.
> > >
> >
> > Oh and before I forget, clicking build now I’m Jenkins will update the CI
> > status in GitHub for the PR to say in progress and then provide the
> result
> > when available.
> >
> >
> > > Searching through comments on PRs to find commits with a magic comment
> > > string that haven’t been built by Jenkins is certainly what would be
> > > lovely... but right now it would burn the GitHub rate limit (which is
> > 5,000
> > > requests per hour across the whole ASF) right through.
> > >
> >
> > To be clear, the hard part is efficiently finding “missed” comments and
> > associating with the commit hash they belong to. We don’t want an
> approval
> > to allow attack via an update pushed to the PR. So you have to walk all
> the
> > comments and associate with the commit hash they applied to... gets
> tricky.
> >
>
> Yep, I understand, you are right.
>
> Another option is to have a script to launch:
>
> import-pr maven-assembly-plugin #567
>
> Then the script + Jenkins:
> - bind the pr to a JIRA by scanning git log
> - push to ASF (changing 'committer') with a standard name (JIRA id)
> - start a job
> - add a github status line with a link to the logs
> - bonus: the job will change the status line with green/red light
>
> I already have such kind of script in my company (but for
> bitbucket/JIRA/Jenkins and not for such a complex system like Maven CI),
> but the hard part is the job which has to write the status line
>
> Enrico
>
>
> > We could maybe hijack approval state... but that allows merging by the
> > author.
> >
>
> This part is not clear to me. Only 'commiters' can push to the repo.


Nah. Once committers have approved the PR then the PR can be merged by the
creator of the PR even if not a committer... at least that’s the default
way GitHub PRs work. GitBox *may* be enforcing a stricter permissions
model... but I suspect not (because it makes contributions harder... and
the goal of gitbox was to make working from GitHub a first class experience)




>
>
>
> >
> > >
> > >
> > >>
> > >> Enrico
> > >>
> > >>
> > >> > Other projects at ASF probably missed this point in the video series
> > >> > chronicling the development of the plugin...
> > >> >
> > >> > On Sat 29 Dec 2018 at 13:10, Enrico Olivelli 
> > >> wrote:
> > >> >
> > >> > > Hervè,
> > >> > > This is the plugin
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup
> > >> > >
> > >> > > I see our "maven-box" is using some special "Scan Apache Hosted
> Git
> > >> > > Folder Triggers" source
> > >> > > (https://builds.apache.org/job/maven-box/configure)
> > >> > > In the Jenkins of my company in a "Multibranch Pipeline" I have a
> > >> > > "Branch Sources" box with a "GitHub" option which lets me trigger
> > >> > > builds by using PRs
> > >> > >
> > >> > >
> > >> > > Enrico
> > >> > >
> > >> > > Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
> > >> > >  ha scritto:
> > >> > > >
> > >> > > > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a
> écrit :
> > >> > > > > Il sab 29 dic 2018, 12:37 Mickael Istria 
> > ha
> > >> > > scritto:
> > >> > > > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
> > >> > > herve.bout...@free.fr>
> > >> > > > > >
> > >> > > > > > wrote:
> > >> > > > > > > But in both cases, currently, there is no automatic GitHub
> > PR
> > >> > > > > >
> > >> > > > > > integration:
> > 

Re: New Committers - community

[Karl Heinz Marbaise]

Hi,

On 29/12/18 18:16, Enrico Olivelli wrote:

Il sab 29 dic 2018, 17:25 Stephen Connolly 
ha scritto:


On Sat 29 Dec 2018 at 16:20, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:




On Sat 29 Dec 2018 at 15:18, Enrico Olivelli 

wrote:



Il sab 29 dic 2018, 15:17 Stephen Connolly <
stephen.alan.conno...@gmail.com>
ha scritto:


There is a security issue with building PRs automatically.

I can see about adding PR discovery to the existing ASF gitbox plugin,

but

we’d need committers to ok the build and have reviewed the code as the

PR

could contain attacks to be run from ASF hardware... which is why we

don’t

build PRs at present.



Now I have to review and then push to ASF repo and I have to tell to the
contributor that I will make CI start.
IMHO a good tradeoff is:
- a committer adds a 'test this please' comment, or '@asfbot test this
please' and then a CI job start
- this job updates the status line of the PR, with a link to the logs

and

the status of the job

How does it sounds to you?



Like it’ll burn through the GitHub api rate limit like crazy.




I did not think we have 100 repos


I wouldn't be that sure:

https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
(96 at the moment)..

or https://gitbox.apache.org/repos/asf

search for "Apache Maven"...

Apart from that the GitHub API rate limit is for the whole ASF 
orga...not only for our project...


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: New Committers - community

[Enrico Olivelli]

Il sab 29 dic 2018, 17:25 Stephen Connolly 
ha scritto:

> On Sat 29 Dec 2018 at 16:20, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> >
> >
> > On Sat 29 Dec 2018 at 15:18, Enrico Olivelli 
> wrote:
> >
> >> Il sab 29 dic 2018, 15:17 Stephen Connolly <
> >> stephen.alan.conno...@gmail.com>
> >> ha scritto:
> >>
> >> > There is a security issue with building PRs automatically.
> >> >
> >> > I can see about adding PR discovery to the existing ASF gitbox plugin,
> >> but
> >> > we’d need committers to ok the build and have reviewed the code as the
> >> PR
> >> > could contain attacks to be run from ASF hardware... which is why we
> >> don’t
> >> > build PRs at present.
> >> >
> >>
> >> Now I have to review and then push to ASF repo and I have to tell to the
> >> contributor that I will make CI start.
> >> IMHO a good tradeoff is:
> >> - a committer adds a 'test this please' comment, or '@asfbot test this
> >> please' and then a CI job start
> >> - this job updates the status line of the PR, with a link to the logs
> and
> >> the status of the job
> >>
> >> How does it sounds to you?
> >
> >
> > Like it’ll burn through the GitHub api rate limit like crazy.
>

I did not think we have 100 repos

> >
> > The committer goes to Jenkins and clicks the build button on the PR job
> > (which is sitting there ready and waiting), done.
> >
>
> Oh and before I forget, clicking build now I’m Jenkins will update the CI
> status in GitHub for the PR to say in progress and then provide the result
> when available.
>
>
> > Searching through comments on PRs to find commits with a magic comment
> > string that haven’t been built by Jenkins is certainly what would be
> > lovely... but right now it would burn the GitHub rate limit (which is
> 5,000
> > requests per hour across the whole ASF) right through.
> >
>
> To be clear, the hard part is efficiently finding “missed” comments and
> associating with the commit hash they belong to. We don’t want an approval
> to allow attack via an update pushed to the PR. So you have to walk all the
> comments and associate with the commit hash they applied to... gets tricky.
>

Yep, I understand, you are right.

Another option is to have a script to launch:

import-pr maven-assembly-plugin #567

Then the script + Jenkins:
- bind the pr to a JIRA by scanning git log
- push to ASF (changing 'committer') with a standard name (JIRA id)
- start a job
- add a github status line with a link to the logs
- bonus: the job will change the status line with green/red light

I already have such kind of script in my company (but for
bitbucket/JIRA/Jenkins and not for such a complex system like Maven CI),
but the hard part is the job which has to write the status line

Enrico


> We could maybe hijack approval state... but that allows merging by the
> author.
>

This part is not clear to me. Only 'commiters' can push to the repo.



>
> >
> >
> >>
> >> Enrico
> >>
> >>
> >> > Other projects at ASF probably missed this point in the video series
> >> > chronicling the development of the plugin...
> >> >
> >> > On Sat 29 Dec 2018 at 13:10, Enrico Olivelli 
> >> wrote:
> >> >
> >> > > Hervè,
> >> > > This is the plugin
> >> > >
> >> > >
> >> >
> >>
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup
> >> > >
> >> > > I see our "maven-box" is using some special "Scan Apache Hosted Git
> >> > > Folder Triggers" source
> >> > > (https://builds.apache.org/job/maven-box/configure)
> >> > > In the Jenkins of my company in a "Multibranch Pipeline" I have a
> >> > > "Branch Sources" box with a "GitHub" option which lets me trigger
> >> > > builds by using PRs
> >> > >
> >> > >
> >> > > Enrico
> >> > >
> >> > > Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
> >> > >  ha scritto:
> >> > > >
> >> > > > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
> >> > > > > Il sab 29 dic 2018, 12:37 Mickael Istria 
> ha
> >> > > scritto:
> >> > > > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
> >> > > herve.bout...@free.fr>
> >> > > > > >
> >> > > > > > wrote:
> >> > > > > > > But in both cases, currently, there is no automatic GitHub
> PR
> >> > > > > >
> >> > > > > > integration:
> >> > > > > > > Maven committers need to create a branch in the official
> >> > > repository to
> >> > > > > > > benefit
> >> > > > > > > from ASF Jenkins build
> >> > > > > >
> >> > > > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and
> >> couldn't
> >> > > be
> >> > > > > > used
> >> > > > > > to trigger builds. That sucks...
> >> > > > >
> >> > > > > Maven migrated to gitbox so actually github is an official repo
> >> for
> >> > > Maven.
> >> > > > > I see the same setup in Zookeeper and Bookkeeper and github pr
> >> plugin
> >> > > works
> >> > > > > like a charm (and I partecipated in setting it up)
> >> > > > oh great, that would be nice to have the same setup for Maven
> repos!
> >> > > >
> >> > > > >
> >> > > > > Enrico

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 16:20, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
>
> On Sat 29 Dec 2018 at 15:18, Enrico Olivelli  wrote:
>
>> Il sab 29 dic 2018, 15:17 Stephen Connolly <
>> stephen.alan.conno...@gmail.com>
>> ha scritto:
>>
>> > There is a security issue with building PRs automatically.
>> >
>> > I can see about adding PR discovery to the existing ASF gitbox plugin,
>> but
>> > we’d need committers to ok the build and have reviewed the code as the
>> PR
>> > could contain attacks to be run from ASF hardware... which is why we
>> don’t
>> > build PRs at present.
>> >
>>
>> Now I have to review and then push to ASF repo and I have to tell to the
>> contributor that I will make CI start.
>> IMHO a good tradeoff is:
>> - a committer adds a 'test this please' comment, or '@asfbot test this
>> please' and then a CI job start
>> - this job updates the status line of the PR, with a link to the logs and
>> the status of the job
>>
>> How does it sounds to you?
>
>
> Like it’ll burn through the GitHub api rate limit like crazy.
>
> The committer goes to Jenkins and clicks the build button on the PR job
> (which is sitting there ready and waiting), done.
>

Oh and before I forget, clicking build now I’m Jenkins will update the CI
status in GitHub for the PR to say in progress and then provide the result
when available.


> Searching through comments on PRs to find commits with a magic comment
> string that haven’t been built by Jenkins is certainly what would be
> lovely... but right now it would burn the GitHub rate limit (which is 5,000
> requests per hour across the whole ASF) right through.
>

To be clear, the hard part is efficiently finding “missed” comments and
associating with the commit hash they belong to. We don’t want an approval
to allow attack via an update pushed to the PR. So you have to walk all the
comments and associate with the commit hash they applied to... gets tricky.

We could maybe hijack approval state... but that allows merging by the
author.


>
>
>>
>> Enrico
>>
>>
>> > Other projects at ASF probably missed this point in the video series
>> > chronicling the development of the plugin...
>> >
>> > On Sat 29 Dec 2018 at 13:10, Enrico Olivelli 
>> wrote:
>> >
>> > > Hervè,
>> > > This is the plugin
>> > >
>> > >
>> >
>> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup
>> > >
>> > > I see our "maven-box" is using some special "Scan Apache Hosted Git
>> > > Folder Triggers" source
>> > > (https://builds.apache.org/job/maven-box/configure)
>> > > In the Jenkins of my company in a "Multibranch Pipeline" I have a
>> > > "Branch Sources" box with a "GitHub" option which lets me trigger
>> > > builds by using PRs
>> > >
>> > >
>> > > Enrico
>> > >
>> > > Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
>> > >  ha scritto:
>> > > >
>> > > > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
>> > > > > Il sab 29 dic 2018, 12:37 Mickael Istria  ha
>> > > scritto:
>> > > > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
>> > > herve.bout...@free.fr>
>> > > > > >
>> > > > > > wrote:
>> > > > > > > But in both cases, currently, there is no automatic GitHub PR
>> > > > > >
>> > > > > > integration:
>> > > > > > > Maven committers need to create a branch in the official
>> > > repository to
>> > > > > > > benefit
>> > > > > > > from ASF Jenkins build
>> > > > > >
>> > > > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and
>> couldn't
>> > > be
>> > > > > > used
>> > > > > > to trigger builds. That sucks...
>> > > > >
>> > > > > Maven migrated to gitbox so actually github is an official repo
>> for
>> > > Maven.
>> > > > > I see the same setup in Zookeeper and Bookkeeper and github pr
>> plugin
>> > > works
>> > > > > like a charm (and I partecipated in setting it up)
>> > > > oh great, that would be nice to have the same setup for Maven repos!
>> > > >
>> > > > >
>> > > > > Enrico
>> > > > >
>> > > > > > Any idea how we could have GitHub PR reviews without this branch
>> > > creation
>> > > > > >
>> > > > > > > by
>> > > > > > > committers, be it at ASF or somewhere else?
>> > > > > >
>> > > > > > Using TravisCI could be a solution.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> -
>> > > > 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
>> > >
>> > > --
>> > Sent from my phone
>> >
>> --
>>
>>
>> -- Enrico Olivelli
>>
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 15:18, Enrico Olivelli  wrote:

> Il sab 29 dic 2018, 15:17 Stephen Connolly <
> stephen.alan.conno...@gmail.com>
> ha scritto:
>
> > There is a security issue with building PRs automatically.
> >
> > I can see about adding PR discovery to the existing ASF gitbox plugin,
> but
> > we’d need committers to ok the build and have reviewed the code as the PR
> > could contain attacks to be run from ASF hardware... which is why we
> don’t
> > build PRs at present.
> >
>
> Now I have to review and then push to ASF repo and I have to tell to the
> contributor that I will make CI start.
> IMHO a good tradeoff is:
> - a committer adds a 'test this please' comment, or '@asfbot test this
> please' and then a CI job start
> - this job updates the status line of the PR, with a link to the logs and
> the status of the job
>
> How does it sounds to you?


Like it’ll burn through the GitHub api rate limit like crazy.

The committer goes to Jenkins and clicks the build button on the PR job
(which is sitting there ready and waiting), done.

Searching through comments on PRs to find commits with a magic comment
string that haven’t been built by Jenkins is certainly what would be
lovely... but right now it would burn the GitHub rate limit (which is 5,000
requests per hour across the whole ASF) right through.



>
> Enrico
>
>
> > Other projects at ASF probably missed this point in the video series
> > chronicling the development of the plugin...
> >
> > On Sat 29 Dec 2018 at 13:10, Enrico Olivelli 
> wrote:
> >
> > > Hervè,
> > > This is the plugin
> > >
> > >
> >
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup
> > >
> > > I see our "maven-box" is using some special "Scan Apache Hosted Git
> > > Folder Triggers" source
> > > (https://builds.apache.org/job/maven-box/configure)
> > > In the Jenkins of my company in a "Multibranch Pipeline" I have a
> > > "Branch Sources" box with a "GitHub" option which lets me trigger
> > > builds by using PRs
> > >
> > >
> > > Enrico
> > >
> > > Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
> > >  ha scritto:
> > > >
> > > > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
> > > > > Il sab 29 dic 2018, 12:37 Mickael Istria  ha
> > > scritto:
> > > > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
> > > herve.bout...@free.fr>
> > > > > >
> > > > > > wrote:
> > > > > > > But in both cases, currently, there is no automatic GitHub PR
> > > > > >
> > > > > > integration:
> > > > > > > Maven committers need to create a branch in the official
> > > repository to
> > > > > > > benefit
> > > > > > > from ASF Jenkins build
> > > > > >
> > > > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and
> couldn't
> > > be
> > > > > > used
> > > > > > to trigger builds. That sucks...
> > > > >
> > > > > Maven migrated to gitbox so actually github is an official repo for
> > > Maven.
> > > > > I see the same setup in Zookeeper and Bookkeeper and github pr
> plugin
> > > works
> > > > > like a charm (and I partecipated in setting it up)
> > > > oh great, that would be nice to have the same setup for Maven repos!
> > > >
> > > > >
> > > > > Enrico
> > > > >
> > > > > > Any idea how we could have GitHub PR reviews without this branch
> > > creation
> > > > > >
> > > > > > > by
> > > > > > > committers, be it at ASF or somewhere else?
> > > > > >
> > > > > > Using TravisCI could be a solution.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -
> > > > 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
> > >
> > > --
> > Sent from my phone
> >
> --
>
>
> -- Enrico Olivelli
>
-- 
Sent from my phone

Re: New Committers - community

[Enrico Olivelli]

Il sab 29 dic 2018, 15:17 Stephen Connolly 
ha scritto:

> There is a security issue with building PRs automatically.
>
> I can see about adding PR discovery to the existing ASF gitbox plugin, but
> we’d need committers to ok the build and have reviewed the code as the PR
> could contain attacks to be run from ASF hardware... which is why we don’t
> build PRs at present.
>

Now I have to review and then push to ASF repo and I have to tell to the
contributor that I will make CI start.
IMHO a good tradeoff is:
- a committer adds a 'test this please' comment, or '@asfbot test this
please' and then a CI job start
- this job updates the status line of the PR, with a link to the logs and
the status of the job

How does it sounds to you?

Enrico


> Other projects at ASF probably missed this point in the video series
> chronicling the development of the plugin...
>
> On Sat 29 Dec 2018 at 13:10, Enrico Olivelli  wrote:
>
> > Hervè,
> > This is the plugin
> >
> >
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup
> >
> > I see our "maven-box" is using some special "Scan Apache Hosted Git
> > Folder Triggers" source
> > (https://builds.apache.org/job/maven-box/configure)
> > In the Jenkins of my company in a "Multibranch Pipeline" I have a
> > "Branch Sources" box with a "GitHub" option which lets me trigger
> > builds by using PRs
> >
> >
> > Enrico
> >
> > Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
> >  ha scritto:
> > >
> > > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
> > > > Il sab 29 dic 2018, 12:37 Mickael Istria  ha
> > scritto:
> > > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
> > herve.bout...@free.fr>
> > > > >
> > > > > wrote:
> > > > > > But in both cases, currently, there is no automatic GitHub PR
> > > > >
> > > > > integration:
> > > > > > Maven committers need to create a branch in the official
> > repository to
> > > > > > benefit
> > > > > > from ASF Jenkins build
> > > > >
> > > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't
> > be
> > > > > used
> > > > > to trigger builds. That sucks...
> > > >
> > > > Maven migrated to gitbox so actually github is an official repo for
> > Maven.
> > > > I see the same setup in Zookeeper and Bookkeeper and github pr plugin
> > works
> > > > like a charm (and I partecipated in setting it up)
> > > oh great, that would be nice to have the same setup for Maven repos!
> > >
> > > >
> > > > Enrico
> > > >
> > > > > Any idea how we could have GitHub PR reviews without this branch
> > creation
> > > > >
> > > > > > by
> > > > > > committers, be it at ASF or somewhere else?
> > > > >
> > > > > Using TravisCI could be a solution.
> > >
> > >
> > >
> > >
> > >
> > > -
> > > 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
> >
> > --
> Sent from my phone
>
-- 


-- Enrico Olivelli

[ANN] Apache Maven Shared Component: Maven Dependency Analyzer Version 1.11.1 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the 
Apache Maven Shared Component: Maven Dependency Analyzer Version 1.11.1
 
https://maven.apache.org/shared/maven-dependency-analzyer/

You should specify the version in your project:
 

  org.apache.maven.shared
  maven-dependency-analyzer
  1.11.1


Important Note:
 * JDK 7 minimum requirement.

You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/shared/maven-dependency-analyzer/download.cgi
 
Release Notes Maven Dependency Analyzer 1.11.1

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12344667

Bug:

 * [MSHARED-786] - jdk8 incompatibility at runtime (NoSuchMethodError)


Enjoy,
 
-The Apache Maven team

Karl Heinz Marbaise

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

Re: New Committers - community

[Stephen Connolly]

There is a security issue with building PRs automatically.

I can see about adding PR discovery to the existing ASF gitbox plugin, but
we’d need committers to ok the build and have reviewed the code as the PR
could contain attacks to be run from ASF hardware... which is why we don’t
build PRs at present.

Other projects at ASF probably missed this point in the video series
chronicling the development of the plugin...

On Sat 29 Dec 2018 at 13:10, Enrico Olivelli  wrote:

> Hervè,
> This is the plugin
>
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup
>
> I see our "maven-box" is using some special "Scan Apache Hosted Git
> Folder Triggers" source
> (https://builds.apache.org/job/maven-box/configure)
> In the Jenkins of my company in a "Multibranch Pipeline" I have a
> "Branch Sources" box with a "GitHub" option which lets me trigger
> builds by using PRs
>
>
> Enrico
>
> Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
>  ha scritto:
> >
> > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
> > > Il sab 29 dic 2018, 12:37 Mickael Istria  ha
> scritto:
> > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
> herve.bout...@free.fr>
> > > >
> > > > wrote:
> > > > > But in both cases, currently, there is no automatic GitHub PR
> > > >
> > > > integration:
> > > > > Maven committers need to create a branch in the official
> repository to
> > > > > benefit
> > > > > from ASF Jenkins build
> > > >
> > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't
> be
> > > > used
> > > > to trigger builds. That sucks...
> > >
> > > Maven migrated to gitbox so actually github is an official repo for
> Maven.
> > > I see the same setup in Zookeeper and Bookkeeper and github pr plugin
> works
> > > like a charm (and I partecipated in setting it up)
> > oh great, that would be nice to have the same setup for Maven repos!
> >
> > >
> > > Enrico
> > >
> > > > Any idea how we could have GitHub PR reviews without this branch
> creation
> > > >
> > > > > by
> > > > > committers, be it at ASF or somewhere else?
> > > >
> > > > Using TravisCI could be a solution.
> >
> >
> >
> >
> >
> > -
> > 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
>
> --
Sent from my phone

Re: New Committers - community

[Enrico Olivelli]

Hervè,
This is the plugin
https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup

I see our "maven-box" is using some special "Scan Apache Hosted Git
Folder Triggers" source
(https://builds.apache.org/job/maven-box/configure)
In the Jenkins of my company in a "Multibranch Pipeline" I have a
"Branch Sources" box with a "GitHub" option which lets me trigger
builds by using PRs


Enrico

Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
 ha scritto:
>
> Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
> > Il sab 29 dic 2018, 12:37 Mickael Istria  ha scritto:
> > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY 
> > >
> > > wrote:
> > > > But in both cases, currently, there is no automatic GitHub PR
> > >
> > > integration:
> > > > Maven committers need to create a branch in the official repository to
> > > > benefit
> > > > from ASF Jenkins build
> > >
> > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't be
> > > used
> > > to trigger builds. That sucks...
> >
> > Maven migrated to gitbox so actually github is an official repo for Maven.
> > I see the same setup in Zookeeper and Bookkeeper and github pr plugin works
> > like a charm (and I partecipated in setting it up)
> oh great, that would be nice to have the same setup for Maven repos!
>
> >
> > Enrico
> >
> > > Any idea how we could have GitHub PR reviews without this branch creation
> > >
> > > > by
> > > > committers, be it at ASF or somewhere else?
> > >
> > > Using TravisCI could be a solution.
>
>
>
>
>
> -
> 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: New Committers - community

[Hervé BOUTEMY]

Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
> Il sab 29 dic 2018, 12:37 Mickael Istria  ha scritto:
> > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY 
> > 
> > wrote:
> > > But in both cases, currently, there is no automatic GitHub PR
> > 
> > integration:
> > > Maven committers need to create a branch in the official repository to
> > > benefit
> > > from ASF Jenkins build
> > 
> > Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't be
> > used
> > to trigger builds. That sucks...
> 
> Maven migrated to gitbox so actually github is an official repo for Maven.
> I see the same setup in Zookeeper and Bookkeeper and github pr plugin works
> like a charm (and I partecipated in setting it up)
oh great, that would be nice to have the same setup for Maven repos!

> 
> Enrico
> 
> > Any idea how we could have GitHub PR reviews without this branch creation
> > 
> > > by
> > > committers, be it at ASF or somewhere else?
> > 
> > Using TravisCI could be a solution.





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

Re: New Committers - community

[Hervé BOUTEMY]

Le samedi 29 décembre 2018, 12:37:36 CET Mickael Istria a écrit :
> On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY 
> 
> wrote:
> > But in both cases, currently, there is no automatic GitHub PR integration:
> > Maven committers need to create a branch in the official repository to
> > benefit
> > from ASF Jenkins build
> 
> Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't be used
> to trigger builds. That sucks...
GitHub repo is not unofficial: with GitBox, it's as official as ASF-hosted Git 
repo
it's GitHub PRs that are not real branches of the Git repo, then the 
triggerring has to be different than normal Git branches commits

> 
> Any idea how we could have GitHub PR reviews without this branch creation
> 
> > by
> > committers, be it at ASF or somewhere else?
> 
> Using TravisCI could be a solution.





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

Re: Building Javadocs and site on CI

[Hervé BOUTEMY]

Le samedi 29 décembre 2018, 11:29:53 CET Robert Scholte a écrit :
> I've already introduces the concept of "plans"[1][2], which also include
> 'site' for documentation and 'release' to verify if the project is
> releasable (should probably change that name to prevent confusion).
+1 to change the name of "release" to something like "check-release"

> The jobs are getting more stable, so we might give it a try soon. Just
> need to be aware that the 'site' plan doesn't seem to work for multimodule
> projects yet. Better fix that first.
why doesn't it work? what does "don't work" mean? fail?

I just see "site:stage" missing to have multi-module assembled: would not 
cause any harm for non-multi-modules

additional question: once the site is build on Jenkins, can it be browsed?

Regards,

Hervé

> 
> thanks,
> Robert
> 
> [1]
> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/as
> fMavenTlpPlgnBuild.groovy;h=6502fe80819c873757e339a0f1b3186fd14303b9;hb=HEAD
> #l63 [2]
> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/as
> fMavenTlpPlgnBuild.groovy;h=6502fe80819c873757e339a0f1b3186fd14303b9;hb=HEAD
> #l132
> 
> 
> On Sat, 29 Dec 2018 09:14:27 +0100, Enrico Olivelli 
> 
> wrote:
> > Hi guys,
> > I am trying to release Maven Assembly Plugin and I see that there are
> > a few showstoppers due to javadocs and site generation.
> > Isn't it possible to run  "javadoc:javadoc site" on CI ?
> > 
> > This way we won't commit broken/unreleasable stuff
> > 
> > Enrico
> > 
> > -
> > 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





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

Re: New Committers - community

[Enrico Olivelli]

Il sab 29 dic 2018, 12:37 Mickael Istria  ha scritto:

> On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY 
> wrote:
>
> > But in both cases, currently, there is no automatic GitHub PR
> integration:
> > Maven committers need to create a branch in the official repository to
> > benefit
> > from ASF Jenkins build
> >
>
> Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't be used
> to trigger builds. That sucks...
>

Maven migrated to gitbox so actually github is an official repo for Maven.
I see the same setup in Zookeeper and Bookkeeper and github pr plugin works
like a charm (and I partecipated in setting it up)

Enrico


> Any idea how we could have GitHub PR reviews without this branch creation
> > by
> > committers, be it at ASF or somewhere else?
> >
>
> Using TravisCI could be a solution.
>
-- 


-- Enrico Olivelli

[RESULT] [VOTE] Release Apache Maven Shared Component: Maven Dependecy Analyzer Version 1.11.1

[Karl Heinz Marbaise]

Hi,

The vote has passed with the following result:

+1 : Mark Raynsford, Vidar Breivik, Tibor Digana, Sylwester Lachieweicz, 
Hervé Boutemy, Olivier Lamy, Karl Heinz Marbaise


PMC quorum: reached

I will promote the artifacts to the central repo.

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: New Committers - community

[Mickael Istria]

On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY 
wrote:

> But in both cases, currently, there is no automatic GitHub PR integration:
> Maven committers need to create a branch in the official repository to
> benefit
> from ASF Jenkins build
>

Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't be used
to trigger builds. That sucks...

Any idea how we could have GitHub PR reviews without this branch creation
> by
> committers, be it at ASF or somewhere else?
>

Using TravisCI could be a solution.

Re: [VOTE] Release Apache Maven Shared Component: Maven Dependecy Analyzer Version 1.11.1

[Karl Heinz Marbaise]

Hi,

here is my +1

Kind regards
Karl Heinz Marbaise
On 25/12/18 23:28, Karl Heinz Marbaise wrote:

Hi,

We solved 1 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12344667 



There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC 



Staging repo:
https://repository.apache.org/content/repositories/maven-1480/
https://repository.apache.org/content/repositories/maven-1480/org/apache/maven/shared/maven-dependency-analyzer/1.11.1/maven-dependency-analyzer-1.11.1-source-release.zip 



Source release checksum(s):
maven-dependency-analyzer-1.11.1-source-release.zip sha512: 
7d8880bac7cfb5f9f01f0b82e6d1dc1b9a4e0f79e0c76f9d807182fcad5e3e8c57c0c019cb1177b87a1e85f92aff3770585422be691f5cfafb529e633af35600 



Staging site:
http://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

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



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

Re: New Committers - community

[Enrico Olivelli]

Il sab 29 dic 2018, 12:19 Karl Heinz Marbaise  ha
scritto:

> Hi Mickael,
>
> On 29/12/18 09:57, Mickael Istria wrote:
> > On Mon, Dec 24, 2018 at 5:21 PM Karl Heinz Marbaise 
> > wrote:
> >
> >> Hi Mickael,
> >>
> >
> > Hi,
> >
> > I have to summarize this simply.
> >
> > I was confused about how automated tests are running or not. If I look at
> > https://github.com/apache/maven/pull/194 , I do not see any build/test
> > report on the issue. I imagine this requires someone to manually trigger
> > the tests, doesn't it?
> > If it is so, then it could be one step to remove on the review process,
> and
> > the automated build feedback would allow contributors to fix their PRs by
> > themselves before wasting time of a reviewer.
>
> I have started to discuss this with ASF Infra team ...
>
> Lets see if we find a solution...I see currently the issue in the amount
> of repos we have...but lets see...
>

We could use the github pr builder plugin but without automatic trigger, qe
can enable only the 'trigger phrase' so that is it enough for a commiter to
add a comment like 'test this please' in order to start the build and have
immediate feedback on github

Enrico


> Kind regards
> Karl Heinz Marb aise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --


-- Enrico Olivelli

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.1

[Karl Heinz Marbaise]

Hi,



Tested with a project with dependency to Bouncycastle signed jar - really
faster.
IMHO would be good to release 3.2 not 3.1.1


I don't agree here, cause only Bug fixing, some tasks fixed and 
dependency upgrades...No real functionality enhancements...that I see...


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: New Committers - community

[Karl Heinz Marbaise]

Hi Mickael,

On 29/12/18 09:57, Mickael Istria wrote:

On Mon, Dec 24, 2018 at 5:21 PM Karl Heinz Marbaise 
wrote:


Hi Mickael,



Hi,

I have to summarize this simply.

I was confused about how automated tests are running or not. If I look at
https://github.com/apache/maven/pull/194 , I do not see any build/test
report on the issue. I imagine this requires someone to manually trigger
the tests, doesn't it?
If it is so, then it could be one step to remove on the review process, and
the automated build feedback would allow contributors to fix their PRs by
themselves before wasting time of a reviewer.


I have started to discuss this with ASF Infra team ...

Lets see if we find a solution...I see currently the issue in the amount 
of repos we have...but lets see...


Kind regards
Karl Heinz Marb aise

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

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.1

[Sylwester Lachiewicz]

Hi,
also my +1

Tested with a project with dependency to Bouncycastle signed jar - really
faster.
IMHO would be good to release 3.2 not 3.1.1

BR
Sylwester


sob., 29 gru 2018 o 11:01 Enrico Olivelli  napisał(a):

> Hi,
>
> We solved 17 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220=12341358=text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MASSEMBLY%20AND%20status%20%3D%20Open
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1482
>
> https://repository.apache.org/content/repositories/maven-1482/org/apache/maven/plugins/maven-assembly-plugin/3.1.1/maven-assembly-plugin-3.1.1-source-release.zip
>
>
> Source release checksum(s):
> maven-assembly-plugin-3.1.1-source-release.zip sha512:
>
> 249c65e6d92782ea4440c6a0030bbedb89a9db884286550d9541324a4d667aaaf02778973c5a30ef4dbf566a659c841846fbf8bfc0e1e52fe4bd154ac9f78d1b
>
> Staging site:
>
> https://svn.apache.org/repos/asf/maven/website/components/plugins-archives/maven-assembly-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Kind Regards
> Enrico Olivelli
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: New Committers - community

[Hervé BOUTEMY]

Le samedi 29 décembre 2018, 09:57:30 CET Mickael Istria a écrit :
> On Mon, Dec 24, 2018 at 5:21 PM Karl Heinz Marbaise 
> 
> wrote:
> > Hi Mickael,
> 
> Hi,
> 
> I have to summarize this simply.
> 
> > This is no lack of interest in any kind. It is simply a lack of time of
> > the committers...cause there is very limited number of committers...
> 
> I understand that, and I hope I was explicit enough when I was talking
> about the *perception* of contributions receiving low interest, as opposed
> to the reality you mention which is about lack of resources compared to
> backlog.
> In this case, some time ago, when Eclipse was in a similar position, we did
> collectively decide to make external contributions higher priority than our
> own work for a few months. This did have a very positive impact in growing
> the community, recruiting more developers, more committers, and also
> changing the mindset of most current committers to think more and more
> about incoming contributors and plan some time for the reviews, and
> prioritize community over development in some cases; because ultimately,
> the community makes the project alive more than its feature set.
> 
> > > It also seems like reviewing and testing PRs is not trivial, and that
> > 
> > more
> > 
> > > automation could help developers to trust incoming changes and deal with
> > > reviews.
> > 
> > What kind of ideas do you have? To be honest reviewing a PR takes time
> > and based on my experience no (other) automation will help there..but If
> > you have ideas please share them...
> 
> I was confused about how automated tests are running or not. If I look at
> https://github.com/apache/maven/pull/194 , I do not see any build/test
> report on the issue. I imagine this requires someone to manually trigger
> the tests, doesn't it?

see https://maven.apache.org/guides/development/guide-building-maven.html

for plugins and components, running the ITs is quite easy since it's only 
about activating "run-its" profile, there is no specific setup

for Maven core, it's more complex, because the its are in a separate git repo 
and multiple steps to run the ITs

But in both cases, currently, there is no automatic GitHub PR integration: 
Maven committers need to create a branch in the official repository to benefit 
from ASF Jenkins build

Any idea how we could have GitHub PR reviews without this branch creation by 
committers, be it at ASF or somewhere else?

> If it is so, then it could be one step to remove on the review process, and
> the automated build feedback would allow contributors to fix their PRs by
> themselves before wasting time of a reviewer.
> 
> > > This goes by having a mindset that makes core developers main task to
> > 
> > grow
> > 
> > > the community rather than fixing bugs or adding features.
> > 
> > That contradicts some of the feedback we got, cause we get feedback
> > saying why does it take so long to fix a bug etc...
> 
> I know that. It's also something we hear often in Eclipse and I guess
> something the majority of serious OSS projects face often.
> But it's OSS, people who need a fix should be ready to invest in it; and
> someone who's finding a bug long to fix is actually someone that can be
> turned as a contributor for their own bug ;)
> 
> The user community is very big but unfortunately the people who are
> 
> > willing to help is not that big...
> 
> Same as above ;)
> 
> > That said, I think Maven already enables some important success criteria,
> > 
> > > like being on GitHub. So I'm confident things can and will improve to
> > 
> > grow
> > 
> > > the community.
> > 
> > Over the time it already evolved/grown in several aspects. Maybe not in
> > the speed we wish it had...
> > But it takes time...
> 
> I have good hope it's worth it ;)





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

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.1

[Karl Heinz Marbaise]

Hi,

here is my +1

Checked on Mac OS / JDK 11  / Maven 3.6.0 without any issue.

Kind regards
Karl Heinz Marbaise


On 29/12/18 11:01, Enrico Olivelli wrote:

Hi,

We solved 17 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220=12341358=text

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MASSEMBLY%20AND%20status%20%3D%20Open

Staging repo:
https://repository.apache.org/content/repositories/maven-1482
https://repository.apache.org/content/repositories/maven-1482/org/apache/maven/plugins/maven-assembly-plugin/3.1.1/maven-assembly-plugin-3.1.1-source-release.zip


Source release checksum(s):
maven-assembly-plugin-3.1.1-source-release.zip sha512:
249c65e6d92782ea4440c6a0030bbedb89a9db884286550d9541324a4d667aaaf02778973c5a30ef4dbf566a659c841846fbf8bfc0e1e52fe4bd154ac9f78d1b

Staging site:
https://svn.apache.org/repos/asf/maven/website/components/plugins-archives/maven-assembly-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

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



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

Re: Building Javadocs and site on CI

[Robert Scholte]

I've already introduces the concept of "plans"[1][2], which also include  
'site' for documentation and 'release' to verify if the project is  
releasable (should probably change that name to prevent confusion).
The jobs are getting more stable, so we might give it a try soon. Just  
need to be aware that the 'site' plan doesn't seem to work for multimodule  
projects yet. Better fix that first.


thanks,
Robert

[1]  
https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpPlgnBuild.groovy;h=6502fe80819c873757e339a0f1b3186fd14303b9;hb=HEAD#l63
[2]  
https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpPlgnBuild.groovy;h=6502fe80819c873757e339a0f1b3186fd14303b9;hb=HEAD#l132



On Sat, 29 Dec 2018 09:14:27 +0100, Enrico Olivelli   
wrote:



Hi guys,
I am trying to release Maven Assembly Plugin and I see that there are
a few showstoppers due to javadocs and site generation.
Isn't it possible to run  "javadoc:javadoc site" on CI ?

This way we won't commit broken/unreleasable stuff

Enrico

-
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: Building Javadocs and site on CI

[Karl Heinz Marbaise]

Hi Enrico,

On 29/12/18 09:53, Enrico Olivelli wrote:

Karl,


Il giorno sab 29 dic 2018 alle ore 09:41 Karl Heinz Marbaise
 ha scritto:


Hi Enrico,

On 29/12/18 09:14, Enrico Olivelli wrote:

Hi guys,
I am trying to release Maven Assembly Plugin and I see that there are
a few showstoppers due to javadocs and site generation.



Can you report which one?


this is the fix, mostly about  tags
https://github.com/apache/maven-assembly-plugin/commit/a97fbb304d1924426f3e3137ba42de0f3d9ec6a0

I had errors like:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site)
on project maven-assembly-plugin: Error parsing
'/home/eolivelli/dev/maven-assembly-plugin/target/generated-site/xdoc/assembly.xml':
line [1511] Error parsing the model: end tag name  must match
start tag name  from line 1508 (position: TEXT seen ...om the
central repository\nare allowed.\n\n  ...
@1511:11)  -> [Help 1]







Isn't it possible to run  "javadoc:javadoc site" on CI ?

This way we won't commit broken/unreleasable stuff



Usually the sites will be generated via:

mvn -Preporting site site:stage

That's how I got the errors



if ready than
mvn scm-publish:publish-scm

See also the deploySite.sh script...

Furthermore you have to do the release via

mvn release:prepare release:perform -Dgpg.keyname=...

first and afterwards you can change into the target/checkout
directory and make the sites via the above commands...


good
I am following this guide
https://maven.apache.org/developers/release/maven-project-release-procedure.html
which points to:
https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
and
https://maven.apache.org/developers/website/deploy-component-reference-documentation.html

I guess the part "Publishing versioned component reference
documentation" is to be done AFTER the VOTE as passed


I'm a little bit late but it looks you did it the right way



And yes the publishing is done after the VOTE is successful.


So now master branch is stable, site is building correctly, PGP works
as expected, I will prepare the release.

Let me try to summarize the guide and your answer:

mvn release:clean
mvn release:prepare
mvn release:perform


Usually you can clean up via:

git clean -fdx
and simple continue:

mvn release:prepare release:perform

in one go...


cd target/checkout
mvn -Preporting site site:stage
mvn scm-publish:publish-scm

call for VOTE
hopefully get 3 +1 from PMCs


That what you need at least...;-)...



finalize the release
https://maven.apache.org/developers/release/maven-project-release-procedure.html

then update the website:
https://maven.apache.org/developers/website/component-reference-documentation-helper.html?plugins

Is this correct ?


Published site looks ok so far...

Kind regards
Karl Heinz Marbaise


Thank you
Enrico





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

Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.1

[Karl Heinz Marbaise]

Hi Enrico,

On 29/12/18 11:01, Enrico Olivelli wrote:

Hi,

We solved 17 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220=12341358=text

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MASSEMBLY%20AND%20status%20%3D%20Open

Staging repo:
https://repository.apache.org/content/repositories/maven-1482
https://repository.apache.org/content/repositories/maven-1482/org/apache/maven/plugins/maven-assembly-plugin/3.1.1/maven-assembly-plugin-3.1.1-source-release.zip


Source release checksum(s):
maven-assembly-plugin-3.1.1-source-release.zip sha512:
249c65e6d92782ea4440c6a0030bbedb89a9db884286550d9541324a4d667aaaf02778973c5a30ef4dbf566a659c841846fbf8bfc0e1e52fe4bd154ac9f78d1b

Staging site:
https://svn.apache.org/repos/asf/maven/website/components/plugins-archives/maven-assembly-plugin-LATEST/


this should be:

https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/

Kind regards
Karl Heinz Marbaise

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

[VOTE] Release Apache Maven Assembly Plugin version 3.1.1

[Enrico Olivelli]

Hi,

We solved 17 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220=12341358=text

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MASSEMBLY%20AND%20status%20%3D%20Open

Staging repo:
https://repository.apache.org/content/repositories/maven-1482
https://repository.apache.org/content/repositories/maven-1482/org/apache/maven/plugins/maven-assembly-plugin/3.1.1/maven-assembly-plugin-3.1.1-source-release.zip


Source release checksum(s):
maven-assembly-plugin-3.1.1-source-release.zip sha512:
249c65e6d92782ea4440c6a0030bbedb89a9db884286550d9541324a4d667aaaf02778973c5a30ef4dbf566a659c841846fbf8bfc0e1e52fe4bd154ac9f78d1b

Staging site:
https://svn.apache.org/repos/asf/maven/website/components/plugins-archives/maven-assembly-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

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

Kind Regards
Enrico Olivelli

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

Re: New Committers - community

[Mickael Istria]

On Mon, Dec 24, 2018 at 5:21 PM Karl Heinz Marbaise 
wrote:

> Hi Mickael,
>

Hi,

I have to summarize this simply.
> This is no lack of interest in any kind. It is simply a lack of time of
> the committers...cause there is very limited number of committers...
>

I understand that, and I hope I was explicit enough when I was talking
about the *perception* of contributions receiving low interest, as opposed
to the reality you mention which is about lack of resources compared to
backlog.
In this case, some time ago, when Eclipse was in a similar position, we did
collectively decide to make external contributions higher priority than our
own work for a few months. This did have a very positive impact in growing
the community, recruiting more developers, more committers, and also
changing the mindset of most current committers to think more and more
about incoming contributors and plan some time for the reviews, and
prioritize community over development in some cases; because ultimately,
the community makes the project alive more than its feature set.



> > It also seems like reviewing and testing PRs is not trivial, and that
> more
> > automation could help developers to trust incoming changes and deal with
> > reviews.
>
> What kind of ideas do you have? To be honest reviewing a PR takes time
> and based on my experience no (other) automation will help there..but If
> you have ideas please share them...
>

I was confused about how automated tests are running or not. If I look at
https://github.com/apache/maven/pull/194 , I do not see any build/test
report on the issue. I imagine this requires someone to manually trigger
the tests, doesn't it?
If it is so, then it could be one step to remove on the review process, and
the automated build feedback would allow contributors to fix their PRs by
themselves before wasting time of a reviewer.


> > This goes by having a mindset that makes core developers main task to
> grow
> > the community rather than fixing bugs or adding features.
>
> That contradicts some of the feedback we got, cause we get feedback
> saying why does it take so long to fix a bug etc...
>

I know that. It's also something we hear often in Eclipse and I guess
something the majority of serious OSS projects face often.
But it's OSS, people who need a fix should be ready to invest in it; and
someone who's finding a bug long to fix is actually someone that can be
turned as a contributor for their own bug ;)

The user community is very big but unfortunately the people who are
> willing to help is not that big...
>

Same as above ;)

> That said, I think Maven already enables some important success criteria,
> > like being on GitHub. So I'm confident things can and will improve to
> grow
> > the community.
>
> Over the time it already evolved/grown in several aspects. Maybe not in
> the speed we wish it had...
> But it takes time...
>

I have good hope it's worth it ;)
-- 
Mickael Istria
Eclipse IDE 
developer, for Red Hat Developers 

Re: Building Javadocs and site on CI

[Enrico Olivelli]

Karl,


Il giorno sab 29 dic 2018 alle ore 09:41 Karl Heinz Marbaise
 ha scritto:
>
> Hi Enrico,
>
> On 29/12/18 09:14, Enrico Olivelli wrote:
> > Hi guys,
> > I am trying to release Maven Assembly Plugin and I see that there are
> > a few showstoppers due to javadocs and site generation.
>
>
> Can you report which one?

this is the fix, mostly about  tags
https://github.com/apache/maven-assembly-plugin/commit/a97fbb304d1924426f3e3137ba42de0f3d9ec6a0

I had errors like:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site)
on project maven-assembly-plugin: Error parsing
'/home/eolivelli/dev/maven-assembly-plugin/target/generated-site/xdoc/assembly.xml':
line [1511] Error parsing the model: end tag name  must match
start tag name  from line 1508 (position: TEXT seen ...om the
central repository\nare allowed.\n\n  ...
@1511:11)  -> [Help 1]



>
>
> > Isn't it possible to run  "javadoc:javadoc site" on CI ?
> >
> > This way we won't commit broken/unreleasable stuff
> >
>
> Usually the sites will be generated via:
>
> mvn -Preporting site site:stage
That's how I got the errors

>
> if ready than
> mvn scm-publish:publish-scm
>
> See also the deploySite.sh script...
>
> Furthermore you have to do the release via
>
> mvn release:prepare release:perform -Dgpg.keyname=...
>
> first and afterwards you can change into the target/checkout
> directory and make the sites via the above commands...

good
I am following this guide
https://maven.apache.org/developers/release/maven-project-release-procedure.html
which points to:
https://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven
and
https://maven.apache.org/developers/website/deploy-component-reference-documentation.html

I guess the part "Publishing versioned component reference
documentation" is to be done AFTER the VOTE as passed

So now master branch is stable, site is building correctly, PGP works
as expected, I will prepare the release.

Let me try to summarize the guide and your answer:

mvn release:clean
mvn release:prepare
mvn release:perform
cd target/checkout
mvn -Preporting site site:stage
mvn scm-publish:publish-scm

call for VOTE
hopefully get 3 +1 from PMCs

finalize the release
https://maven.apache.org/developers/release/maven-project-release-procedure.html

then update the website:
https://maven.apache.org/developers/website/component-reference-documentation-helper.html?plugins

Is this correct ?

Thank you
Enrico

>
> 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: Building Javadocs and site on CI

[Karl Heinz Marbaise]

Hi Enrico,

On 29/12/18 09:14, Enrico Olivelli wrote:

Hi guys,
I am trying to release Maven Assembly Plugin and I see that there are
a few showstoppers due to javadocs and site generation.



Can you report which one?



Isn't it possible to run  "javadoc:javadoc site" on CI ?

This way we won't commit broken/unreleasable stuff



Usually the sites will be generated via:

mvn -Preporting site site:stage

if ready than
mvn scm-publish:publish-scm

See also the deploySite.sh script...

Furthermore you have to do the release via

mvn release:prepare release:perform -Dgpg.keyname=...

first and afterwards you can change into the target/checkout
directory and make the sites via the above commands...

Kind regards
Karl Heinz Marbaise

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

Building Javadocs and site on CI

[Enrico Olivelli]

Hi guys,
I am trying to release Maven Assembly Plugin and I see that there are
a few showstoppers due to javadocs and site generation.
Isn't it possible to run  "javadoc:javadoc site" on CI ?

This way we won't commit broken/unreleasable stuff

Enrico

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