Please write proper JIRA-descriptions

[Matthias Bünger]

Hey all,

when I started to read through the Maven JIRA issues I noticed that
there are many without a description that people, who were not involved
in discussions / coding in where an issues raised from, can hardly
understand the issue and therefore also can't get their hands on or
contribute (ofc Maven is a huge and complex system where some issue are
only understandable when you know how certain things work).

Sometimes the PR gives more information, but sometimes the information
there are different from the issue.

To top this, there are sometimes issues that don't have a single
character as a description, e.g. this one from the fresh beta-2 releases
notes:

https://issues.apache.org/jira/browse/MNG-8089

Ofc an empty issue might be better than no issue to documentation the
need of something at least with a title and yes I'm a person who thinks
that proper documentation and descriptions of apps/issues/etc are
important and I like writing documentation. As this (and as a person who
tries to get deeper into Maven) I kindly ask everyone to spent some time
when creating an issue and not leave it empty or only put a short
sentences in it. I'm convinced that proper descriptions help everybody
to understand the WHAT and WHY not only for a short moment but for a
long time.

Thank you very much!

Matthias



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

Re: Releases notes ... Jira, GitHub

[Slawomir Jaranowski]

wt., 8 lis 2022 o 01:16 Olivier Lamy  napisał(a):

> well I just see GH release note as a cherry on the cake.
> as long as the rest is done.



Just compare the result of generated dependabot PRs
> no GH release notes
> https://github.com/eclipse/jetty.project/pull/8853
> with GH release notes
> https://github.com/eclipse/jetty.project/pull/7727
> I tend to find the second (e.g with GH release note auto generated)
> more human readable and directly accessible (no need to go somewhere
> else and there is even a link to the PR of the changelog entry). but
> yeah maybe it's only me
>
>
Yes, you are right.
To be honest I also like GH release notes, and I think that is more
readable.
It is also used by other tools like dependabot.
Moreover, I think that most users can not reach release notes in Jira - it
is visible for logged users.

But we should have a fresh cherry with a new cake :-)

For me the biggest issue is that we can have slightly different release
notes for the same version,
or missing release notes on GitHub for the new version.


 Regarding "each change must be done by PR", for some reasons we can’t
> really make it mandatory but let's be honest in real life everybody
> does it :)
> At the end, if release drafter is configured it's just one click, and
> if not it's 2 clicks or one command line if using github cli tool gh
>
>
I did an experiment for Plugin Tools -
https://github.com/apache/maven-plugin-tools/releases/tag/maven-plugin-tools-3.7.0

- Copy release notes in html from jira
- use online html to markdown converter
- paste to GitHub
 so also not many "clicks"


On a more general discussion, we are a very large project with plenty
> of sub projects (maintained by different people who are not
> maintaining every project) and we can be happy having few people
> maintaining those during their spare time. So not sure it's  a very
> good idea to have too strict policies/procedures especially when it
> comes to adding a nice to have cherry on the top for users
> Especially when the rest of our long procedure has been done.
>
>
I'm not for strict procedure - rather discussion is about good practices


>
>
> On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski 
> wrote:
> >
> > Hi,
> > I start a discussion ... as beginning - some my loose thoughts
> >
> > We use Jira (for most of) as our primary issues management system.
> > We manage release notes in Jira - it is the source for announcements.
> >
> > In some projects we have  GitHub releases notes.
> > In some cases we use release-drafter for preparing GitHub releases notes.
> > Some of release  notes on GH - it is not actual
> >
> > Challenge:
> >  -  make both release notes to have the same information
> >  - minimal additional manual work
> >
> > Release - drafter is fine, but
> >  - requires correct labeling on PR
> >  - eache change must be done by PR
> >  - each PR must be merged on GH with merged status
> >  - no additional issues
> >
> >
> > --
> > Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Releases notes ... Jira, GitHub

[Olivier Lamy]

You can find the list here
https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls

On Tue, 8 Nov 2022 at 12:55 pm, Gary Gregory  wrote:

> What countries are those BTW?
>
> Gary
>
> On Mon, Nov 7, 2022, 21:52 Gary Gregory  wrote:
>
> >
> >
> > On Mon, Nov 7, 2022, 20:05 Olivier Lamy  wrote:
> >
> >> On Tue, 8 Nov 2022 at 10:59, Gary Gregory 
> wrote:
> >> >
> >> > FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for
> >> issues,
> >> > and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628
> >> >
> >>
> >> So you mean using ONLY gh for issues?
> >> So by doing this, you will exclude people living in countries banned
> >> from Github.
> >> Is it acceptable from an Apache Foundation POV?
> >>
> >
> > I don't know if this was considered. It must be an issue for other
> > projects as well.
> >
> > Gary
> >
> >
> >> argghhh only 2 answers and the thread is already forking 藍
> >>
> >>
> >> > Gary
> >> >
> >> > On Mon, Nov 7, 2022, 19:16 Olivier Lamy  wrote:
> >> >
> >> > > well I just see GH release note as a cherry on the cake.
> >> > > as long as the rest is done.
> >> > > Just compare the result of generated dependabot PRs
> >> > > no GH release notes
> >> > > https://github.com/eclipse/jetty.project/pull/8853
> >> > > with GH release notes
> >> > > https://github.com/eclipse/jetty.project/pull/7727
> >> > > I tend to find the second (e.g with GH release note auto generated)
> >> > > more human readable and directly accessible (no need to go somewhere
> >> > > else and there is even a link to the PR of the changelog entry). but
> >> > > yeah maybe it's only me
> >> > >
> >> > > Regarding "each change must be done by PR", for some reasons we
> can’t
> >> > > really make it mandatory but let's be honest in real life everybody
> >> > > does it :)
> >> > > At the end, if release drafter is configured it's just one click,
> and
> >> > > if not it's 2 clicks or one command line if using github cli tool gh
> >> > >
> >> > > On a more general discussion, we are a very large project with
> plenty
> >> > > of sub projects (maintained by different people who are not
> >> > > maintaining every project) and we can be happy having few people
> >> > > maintaining those during their spare time. So not sure it's  a very
> >> > > good idea to have too strict policies/procedures especially when it
> >> > > comes to adding a nice to have cherry on the top for users
> >> > > Especially when the rest of our long procedure has been done.
> >> > >
> >> > >
> >> > >
> >> > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski <
> >> s.jaranow...@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > Hi,
> >> > > > I start a discussion ... as beginning - some my loose thoughts
> >> > > >
> >> > > > We use Jira (for most of) as our primary issues management system.
> >> > > > We manage release notes in Jira - it is the source for
> >> announcements.
> >> > > >
> >> > > > In some projects we have  GitHub releases notes.
> >> > > > In some cases we use release-drafter for preparing GitHub releases
> >> notes.
> >> > > > Some of release  notes on GH - it is not actual
> >> > > >
> >> > > > Challenge:
> >> > > >  -  make both release notes to have the same information
> >> > > >  - minimal additional manual work
> >> > > >
> >> > > > Release - drafter is fine, but
> >> > > >  - requires correct labeling on PR
> >> > > >  - eache change must be done by PR
> >> > > >  - each PR must be merged on GH with merged status
> >> > > >  - no additional issues
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Sławomir Jaranowski
> >> > >
> >> > >
> -
> >> > > 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: Releases notes ... Jira, GitHub

[Gary Gregory]

What countries are those BTW?

Gary

On Mon, Nov 7, 2022, 21:52 Gary Gregory  wrote:

>
>
> On Mon, Nov 7, 2022, 20:05 Olivier Lamy  wrote:
>
>> On Tue, 8 Nov 2022 at 10:59, Gary Gregory  wrote:
>> >
>> > FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for
>> issues,
>> > and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628
>> >
>>
>> So you mean using ONLY gh for issues?
>> So by doing this, you will exclude people living in countries banned
>> from Github.
>> Is it acceptable from an Apache Foundation POV?
>>
>
> I don't know if this was considered. It must be an issue for other
> projects as well.
>
> Gary
>
>
>> argghhh only 2 answers and the thread is already forking 藍
>>
>>
>> > Gary
>> >
>> > On Mon, Nov 7, 2022, 19:16 Olivier Lamy  wrote:
>> >
>> > > well I just see GH release note as a cherry on the cake.
>> > > as long as the rest is done.
>> > > Just compare the result of generated dependabot PRs
>> > > no GH release notes
>> > > https://github.com/eclipse/jetty.project/pull/8853
>> > > with GH release notes
>> > > https://github.com/eclipse/jetty.project/pull/7727
>> > > I tend to find the second (e.g with GH release note auto generated)
>> > > more human readable and directly accessible (no need to go somewhere
>> > > else and there is even a link to the PR of the changelog entry). but
>> > > yeah maybe it's only me
>> > >
>> > > Regarding "each change must be done by PR", for some reasons we can’t
>> > > really make it mandatory but let's be honest in real life everybody
>> > > does it :)
>> > > At the end, if release drafter is configured it's just one click, and
>> > > if not it's 2 clicks or one command line if using github cli tool gh
>> > >
>> > > On a more general discussion, we are a very large project with plenty
>> > > of sub projects (maintained by different people who are not
>> > > maintaining every project) and we can be happy having few people
>> > > maintaining those during their spare time. So not sure it's  a very
>> > > good idea to have too strict policies/procedures especially when it
>> > > comes to adding a nice to have cherry on the top for users
>> > > Especially when the rest of our long procedure has been done.
>> > >
>> > >
>> > >
>> > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski <
>> s.jaranow...@gmail.com>
>> > > wrote:
>> > > >
>> > > > Hi,
>> > > > I start a discussion ... as beginning - some my loose thoughts
>> > > >
>> > > > We use Jira (for most of) as our primary issues management system.
>> > > > We manage release notes in Jira - it is the source for
>> announcements.
>> > > >
>> > > > In some projects we have  GitHub releases notes.
>> > > > In some cases we use release-drafter for preparing GitHub releases
>> notes.
>> > > > Some of release  notes on GH - it is not actual
>> > > >
>> > > > Challenge:
>> > > >  -  make both release notes to have the same information
>> > > >  - minimal additional manual work
>> > > >
>> > > > Release - drafter is fine, but
>> > > >  - requires correct labeling on PR
>> > > >  - eache change must be done by PR
>> > > >  - each PR must be merged on GH with merged status
>> > > >  - no additional issues
>> > > >
>> > > >
>> > > > --
>> > > > Sławomir Jaranowski
>> > >
>> > > -
>> > > 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: Releases notes ... Jira, GitHub

[Gary Gregory]

On Mon, Nov 7, 2022, 20:05 Olivier Lamy  wrote:

> On Tue, 8 Nov 2022 at 10:59, Gary Gregory  wrote:
> >
> > FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for
> issues,
> > and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628
> >
>
> So you mean using ONLY gh for issues?
> So by doing this, you will exclude people living in countries banned
> from Github.
> Is it acceptable from an Apache Foundation POV?
>

I don't know if this was considered. It must be an issue for other projects
as well.

Gary


> argghhh only 2 answers and the thread is already forking 藍
>
>
> > Gary
> >
> > On Mon, Nov 7, 2022, 19:16 Olivier Lamy  wrote:
> >
> > > well I just see GH release note as a cherry on the cake.
> > > as long as the rest is done.
> > > Just compare the result of generated dependabot PRs
> > > no GH release notes
> > > https://github.com/eclipse/jetty.project/pull/8853
> > > with GH release notes
> > > https://github.com/eclipse/jetty.project/pull/7727
> > > I tend to find the second (e.g with GH release note auto generated)
> > > more human readable and directly accessible (no need to go somewhere
> > > else and there is even a link to the PR of the changelog entry). but
> > > yeah maybe it's only me
> > >
> > > Regarding "each change must be done by PR", for some reasons we can’t
> > > really make it mandatory but let's be honest in real life everybody
> > > does it :)
> > > At the end, if release drafter is configured it's just one click, and
> > > if not it's 2 clicks or one command line if using github cli tool gh
> > >
> > > On a more general discussion, we are a very large project with plenty
> > > of sub projects (maintained by different people who are not
> > > maintaining every project) and we can be happy having few people
> > > maintaining those during their spare time. So not sure it's  a very
> > > good idea to have too strict policies/procedures especially when it
> > > comes to adding a nice to have cherry on the top for users
> > > Especially when the rest of our long procedure has been done.
> > >
> > >
> > >
> > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > > wrote:
> > > >
> > > > Hi,
> > > > I start a discussion ... as beginning - some my loose thoughts
> > > >
> > > > We use Jira (for most of) as our primary issues management system.
> > > > We manage release notes in Jira - it is the source for announcements.
> > > >
> > > > In some projects we have  GitHub releases notes.
> > > > In some cases we use release-drafter for preparing GitHub releases
> notes.
> > > > Some of release  notes on GH - it is not actual
> > > >
> > > > Challenge:
> > > >  -  make both release notes to have the same information
> > > >  - minimal additional manual work
> > > >
> > > > Release - drafter is fine, but
> > > >  - requires correct labeling on PR
> > > >  - eache change must be done by PR
> > > >  - each PR must be merged on GH with merged status
> > > >  - no additional issues
> > > >
> > > >
> > > > --
> > > > Sławomir Jaranowski
> > >
> > > -
> > > 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: Releases notes ... Jira, GitHub

[Olivier Lamy]

On Tue, 8 Nov 2022 at 10:59, Gary Gregory  wrote:
>
> FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for issues,
> and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628
>

So you mean using ONLY gh for issues?
So by doing this, you will exclude people living in countries banned
from Github.
Is it acceptable from an Apache Foundation POV?

argghhh only 2 answers and the thread is already forking 藍


> Gary
>
> On Mon, Nov 7, 2022, 19:16 Olivier Lamy  wrote:
>
> > well I just see GH release note as a cherry on the cake.
> > as long as the rest is done.
> > Just compare the result of generated dependabot PRs
> > no GH release notes
> > https://github.com/eclipse/jetty.project/pull/8853
> > with GH release notes
> > https://github.com/eclipse/jetty.project/pull/7727
> > I tend to find the second (e.g with GH release note auto generated)
> > more human readable and directly accessible (no need to go somewhere
> > else and there is even a link to the PR of the changelog entry). but
> > yeah maybe it's only me
> >
> > Regarding "each change must be done by PR", for some reasons we can’t
> > really make it mandatory but let's be honest in real life everybody
> > does it :)
> > At the end, if release drafter is configured it's just one click, and
> > if not it's 2 clicks or one command line if using github cli tool gh
> >
> > On a more general discussion, we are a very large project with plenty
> > of sub projects (maintained by different people who are not
> > maintaining every project) and we can be happy having few people
> > maintaining those during their spare time. So not sure it's  a very
> > good idea to have too strict policies/procedures especially when it
> > comes to adding a nice to have cherry on the top for users
> > Especially when the rest of our long procedure has been done.
> >
> >
> >
> > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski 
> > wrote:
> > >
> > > Hi,
> > > I start a discussion ... as beginning - some my loose thoughts
> > >
> > > We use Jira (for most of) as our primary issues management system.
> > > We manage release notes in Jira - it is the source for announcements.
> > >
> > > In some projects we have  GitHub releases notes.
> > > In some cases we use release-drafter for preparing GitHub releases notes.
> > > Some of release  notes on GH - it is not actual
> > >
> > > Challenge:
> > >  -  make both release notes to have the same information
> > >  - minimal additional manual work
> > >
> > > Release - drafter is fine, but
> > >  - requires correct labeling on PR
> > >  - eache change must be done by PR
> > >  - each PR must be merged on GH with merged status
> > >  - no additional issues
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> >
> > -
> > 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: Releases notes ... Jira, GitHub

[Gary Gregory]

FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for issues,
and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628

Gary

On Mon, Nov 7, 2022, 19:16 Olivier Lamy  wrote:

> well I just see GH release note as a cherry on the cake.
> as long as the rest is done.
> Just compare the result of generated dependabot PRs
> no GH release notes
> https://github.com/eclipse/jetty.project/pull/8853
> with GH release notes
> https://github.com/eclipse/jetty.project/pull/7727
> I tend to find the second (e.g with GH release note auto generated)
> more human readable and directly accessible (no need to go somewhere
> else and there is even a link to the PR of the changelog entry). but
> yeah maybe it's only me
>
> Regarding "each change must be done by PR", for some reasons we can’t
> really make it mandatory but let's be honest in real life everybody
> does it :)
> At the end, if release drafter is configured it's just one click, and
> if not it's 2 clicks or one command line if using github cli tool gh
>
> On a more general discussion, we are a very large project with plenty
> of sub projects (maintained by different people who are not
> maintaining every project) and we can be happy having few people
> maintaining those during their spare time. So not sure it's  a very
> good idea to have too strict policies/procedures especially when it
> comes to adding a nice to have cherry on the top for users
> Especially when the rest of our long procedure has been done.
>
>
>
> On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski 
> wrote:
> >
> > Hi,
> > I start a discussion ... as beginning - some my loose thoughts
> >
> > We use Jira (for most of) as our primary issues management system.
> > We manage release notes in Jira - it is the source for announcements.
> >
> > In some projects we have  GitHub releases notes.
> > In some cases we use release-drafter for preparing GitHub releases notes.
> > Some of release  notes on GH - it is not actual
> >
> > Challenge:
> >  -  make both release notes to have the same information
> >  - minimal additional manual work
> >
> > Release - drafter is fine, but
> >  - requires correct labeling on PR
> >  - eache change must be done by PR
> >  - each PR must be merged on GH with merged status
> >  - no additional issues
> >
> >
> > --
> > Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Releases notes ... Jira, GitHub

[Olivier Lamy]

well I just see GH release note as a cherry on the cake.
as long as the rest is done.
Just compare the result of generated dependabot PRs
no GH release notes
https://github.com/eclipse/jetty.project/pull/8853
with GH release notes
https://github.com/eclipse/jetty.project/pull/7727
I tend to find the second (e.g with GH release note auto generated)
more human readable and directly accessible (no need to go somewhere
else and there is even a link to the PR of the changelog entry). but
yeah maybe it's only me

Regarding "each change must be done by PR", for some reasons we can’t
really make it mandatory but let's be honest in real life everybody
does it :)
At the end, if release drafter is configured it's just one click, and
if not it's 2 clicks or one command line if using github cli tool gh

On a more general discussion, we are a very large project with plenty
of sub projects (maintained by different people who are not
maintaining every project) and we can be happy having few people
maintaining those during their spare time. So not sure it's  a very
good idea to have too strict policies/procedures especially when it
comes to adding a nice to have cherry on the top for users
Especially when the rest of our long procedure has been done.



On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski  wrote:
>
> Hi,
> I start a discussion ... as beginning - some my loose thoughts
>
> We use Jira (for most of) as our primary issues management system.
> We manage release notes in Jira - it is the source for announcements.
>
> In some projects we have  GitHub releases notes.
> In some cases we use release-drafter for preparing GitHub releases notes.
> Some of release  notes on GH - it is not actual
>
> Challenge:
>  -  make both release notes to have the same information
>  - minimal additional manual work
>
> Release - drafter is fine, but
>  - requires correct labeling on PR
>  - eache change must be done by PR
>  - each PR must be merged on GH with merged status
>  - no additional issues
>
>
> --
> Sławomir Jaranowski

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

Releases notes ... Jira, GitHub

[Slawomir Jaranowski]

Hi,
I start a discussion ... as beginning - some my loose thoughts

We use Jira (for most of) as our primary issues management system.
We manage release notes in Jira - it is the source for announcements.

In some projects we have  GitHub releases notes.
In some cases we use release-drafter for preparing GitHub releases notes.
Some of release  notes on GH - it is not actual

Challenge:
 -  make both release notes to have the same information
 - minimal additional manual work

Release - drafter is fine, but
 - requires correct labeling on PR
 - eache change must be done by PR
 - each PR must be merged on GH with merged status
 - no additional issues


-- 
Sławomir Jaranowski

Dependabot and jira issues

[Slawomir Jaranowski]

Hi,

Dependabot is a very useful tool as we know.

Most of (probably all) Maven / ASF projects have dedicated jira projects to
track changes.

When we create PR with  jira issue reference in the PR title then "ASF
GitHub Bot" links PR with jira issue.

Maybe it will be useful (posible) when Dependabot create PR with dependency
updates "ASF GitHub Bot" can create corresponding issue for it and link
with PR?

Sometime issue about dependency updates is created manually and it can
happen that can be resolved by Dependabot PR, eg: [1]
But in most of situations we have updated project dependency without jira
tracking, eg: [2]

What do you think about such automatically possibility,
manually creating issue for each Dependabot PR can not works as we see.

[1] https://issues.apache.org/jira/browse/MPOM-267
[2] https://github.com/apache/maven-apache-parent/pull/54


-- 
Sławomir Jaranowski

https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski

Follow up on https://issues.apache.org/jira/browse/MNG-6354

[Romain Manni-Bucau]

Hi all,

Now that CDI is gone we still have some leaking packages not in a (almost)
pure maven ecosystem:
https://github.com/apache/maven/blob/406c525ec45da466387dbf19f7fd8ed1d9885e66/maven-core/src/main/resources/META-INF/maven/extension.xml#L98

(pure kind of means plexus/maven/sonatype/aether even if not 100% accurate
but conflicts there are very very rare)

We keep javax annotation, inject and slf4j exported.

I fully understand dropping them would break a lot of apps without some
careness but I think, due to our architecture and plugin/ext system, it
would be sane for maven to never export something not considered internal
since we take the risk to conflict or limit plugins with the related
packages (ex slf4 event was not exported at some point or newer version
usages will have issues).

I assume we'll not target it for 3.x but it sounds a good design fix for
4.x.

One option to not break is to rewrite the related classes/annotations with
asm - at build time for mojo if possible and inject in plugin.xml a flag
saying "it is done" - or at run time - with a ClassFileTransformer in the
ClassRealm - for existing instances.

I'm not yet 100% sure which path is the sanest but hope the issue, at
least, is clear.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

Superfluous build notifications in JIRA

[Maarten Mulders]

Hi all,

Last Thursday and Friday, I've received well over 400 notifications from 
Apache JIRA, all by the "Hudson" user (now Jenkins). They notified me of 
a failed job regarding a ticket I was watching. Not only does it annoy 
me, it also annoys people who reported a ticket [1].


As far as I can see, there can be two reasons why this is happening.

1. Jenkins builds old branches that still exist in ASF Git, even when 
that branch is no longer relevant. I think that this a relatively small 
contribution to the problem, but it's an easy one to address - by 
cleaning up old branches.


2. Many long-living branches are sooner or later outdated compared to 
the master branch. In order to make sure they still work as expected 
with the latest changes from master, people merge the master branch into 
their feature branch. This introduces many commits in that feature 
branch with references to JIRA tickets that have already been resolved 
and closed. Those tickets will then also receive a notification from 
Jenkins when a build of that branch fails.


The second one is more of an hypothesis. I saw a lot of false build 
notifications among those 400+ on JIRA tickets that are closed for a 
long time. Inspecting those builds and the respective branches shows 
that there are commits on those branches with the closed JIRA ticket in 
their title.


What do you think? Does this line of thought make sense? If it does, we 
might need to (re)consider whether we use merge or rebase for 
long-living branches in order to reduce those superfluous notifications.


Thanks,


Maarten



[1] 
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17267910#comment-17267910




OpenPGP_signature
Description: OpenPGP digital signature

Re: [RESULT][DISCUSS] Make Jira issues viewable.

[Maxim Solodovnik]

The filter is private actually

On Fri, 11 Sep 2020 at 17:50, Arnaud Héritier  wrote:

> It's not a blocker if it works without the filter parameter but the
> behavior is strange (I never saw this myself)
>
> On Fri, Sep 11, 2020 at 12:25 PM Robert Scholte 
> wrote:
>
> > Clear, it is not an issue, just a matter of using the correct URL.
> >
> > Robert
> >
> > On 11-9-2020 11:18:45, Enrico Olivelli  wrote:
> > I agree with Bindul
> >
> > I have never seen such blocks
> >
> > Enrico
> >
> > Il Ven 11 Set 2020, 10:38 Bindul Bhowmik ha
> > scritto:
> >
> > > Hi,
> > >
> > > If I may chime in, the Maven (and most Apache) JIRA issues don't
> > > require a login to view. I believe the issue is that Amelia added a
> > > filter to the URL pasted in the tweet, and the filter requires a
> > > login.
> > > So: https://issues.apache.org/jira/browse/MNG-6928 is viewable without
> > > a login https://issues.apache.org/jira/browse/MNG-6928?filter=-2 is
> > > not.
> > >
> > > Bindul
> > >
> > > On Fri, Sep 11, 2020 at 12:54 AM Maarten Mulders
> > > wrote:
> > > >
> > > > Agreed. If there's anything that is too deliberate to discuss in the
> > > > open, there's the mailing list, direct email or what not.
> > > >
> > > > Maarten
> > > >
> > > > On 11/09/2020 09:51, Robert Scholte wrote:
> > > > > Based on the
> > > https://twitter.com/ameliaeiras/status/1303815661307613184 and the
> > > responses of Marten Deinum I agree that it makes sense to make issues
> > > viewable for all.
> > > > >
> > > > > If there is no strong reason to keep it as it is, I'll ask our Jira
> > > administrator if our scheme can be updated.
> > > > > (looks like the Maven projects are missing an explicit Issue
> Security
> > > scheme)
> > > > >
> > > > > thanks,
> > > > > Robert
> > > > >
> > > >
> > > > -
> > > > 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
> > >
> > >
> >
>
>
> --
> Arnaud Héritier
> Twitter/Skype : aheritier
>


-- 
Best regards,
Maxim

Re: [RESULT][DISCUSS] Make Jira issues viewable.

[Arnaud Héritier]

It's not a blocker if it works without the filter parameter but the
behavior is strange (I never saw this myself)

On Fri, Sep 11, 2020 at 12:25 PM Robert Scholte 
wrote:

> Clear, it is not an issue, just a matter of using the correct URL.
>
> Robert
>
> On 11-9-2020 11:18:45, Enrico Olivelli  wrote:
> I agree with Bindul
>
> I have never seen such blocks
>
> Enrico
>
> Il Ven 11 Set 2020, 10:38 Bindul Bhowmik ha
> scritto:
>
> > Hi,
> >
> > If I may chime in, the Maven (and most Apache) JIRA issues don't
> > require a login to view. I believe the issue is that Amelia added a
> > filter to the URL pasted in the tweet, and the filter requires a
> > login.
> > So: https://issues.apache.org/jira/browse/MNG-6928 is viewable without
> > a login https://issues.apache.org/jira/browse/MNG-6928?filter=-2 is
> > not.
> >
> > Bindul
> >
> > On Fri, Sep 11, 2020 at 12:54 AM Maarten Mulders
> > wrote:
> > >
> > > Agreed. If there's anything that is too deliberate to discuss in the
> > > open, there's the mailing list, direct email or what not.
> > >
> > > Maarten
> > >
> > > On 11/09/2020 09:51, Robert Scholte wrote:
> > > > Based on the
> > https://twitter.com/ameliaeiras/status/1303815661307613184 and the
> > responses of Marten Deinum I agree that it makes sense to make issues
> > viewable for all.
> > > >
> > > > If there is no strong reason to keep it as it is, I'll ask our Jira
> > administrator if our scheme can be updated.
> > > > (looks like the Maven projects are missing an explicit Issue Security
> > scheme)
> > > >
> > > > thanks,
> > > > Robert
> > > >
> > >
> > > -
> > > 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
> >
> >
>


-- 
Arnaud Héritier
Twitter/Skype : aheritier

[RESULT][DISCUSS] Make Jira issues viewable.

[Robert Scholte]

Clear, it is not an issue, just a matter of using the correct URL.

Robert

On 11-9-2020 11:18:45, Enrico Olivelli  wrote:
I agree with Bindul

I have never seen such blocks

Enrico

Il Ven 11 Set 2020, 10:38 Bindul Bhowmik ha
scritto:

> Hi,
>
> If I may chime in, the Maven (and most Apache) JIRA issues don't
> require a login to view. I believe the issue is that Amelia added a
> filter to the URL pasted in the tweet, and the filter requires a
> login.
> So: https://issues.apache.org/jira/browse/MNG-6928 is viewable without
> a login https://issues.apache.org/jira/browse/MNG-6928?filter=-2 is
> not.
>
> Bindul
>
> On Fri, Sep 11, 2020 at 12:54 AM Maarten Mulders
> wrote:
> >
> > Agreed. If there's anything that is too deliberate to discuss in the
> > open, there's the mailing list, direct email or what not.
> >
> > Maarten
> >
> > On 11/09/2020 09:51, Robert Scholte wrote:
> > > Based on the
> https://twitter.com/ameliaeiras/status/1303815661307613184 and the
> responses of Marten Deinum I agree that it makes sense to make issues
> viewable for all.
> > >
> > > If there is no strong reason to keep it as it is, I'll ask our Jira
> administrator if our scheme can be updated.
> > > (looks like the Maven projects are missing an explicit Issue Security
> scheme)
> > >
> > > thanks,
> > > Robert
> > >
> >
> > -
> > 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] Make Jira issues viewable.

[Enrico Olivelli]

I agree with Bindul

I have never seen such blocks

Enrico

Il Ven 11 Set 2020, 10:38 Bindul Bhowmik  ha
scritto:

> Hi,
>
> If I may chime in, the Maven (and most Apache) JIRA issues don't
> require a login to view. I believe the issue is that Amelia added a
> filter to the URL pasted in the tweet, and the filter requires a
> login.
> So: https://issues.apache.org/jira/browse/MNG-6928 is viewable without
> a login https://issues.apache.org/jira/browse/MNG-6928?filter=-2 is
> not.
>
> Bindul
>
> On Fri, Sep 11, 2020 at 12:54 AM Maarten Mulders 
> wrote:
> >
> > Agreed. If there's anything that is too deliberate to discuss in the
> > open, there's the mailing list, direct email or what not.
> >
> > Maarten
> >
> > On 11/09/2020 09:51, Robert Scholte wrote:
> > > Based on the
> https://twitter.com/ameliaeiras/status/1303815661307613184 and the
> responses of Marten Deinum I agree that it makes sense to make issues
> viewable for all.
> > >
> > > If there is no strong reason to keep it as it is, I'll ask our Jira
> administrator if our scheme can be updated.
> > > (looks like the Maven projects are missing an explicit Issue Security
> scheme)
> > >
> > > thanks,
> > > Robert
> > >
> >
> > -
> > 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] Make Jira issues viewable.

[Bindul Bhowmik]

Hi,

If I may chime in, the Maven (and most Apache) JIRA issues don't
require a login to view. I believe the issue is that Amelia added a
filter to the URL pasted in the tweet, and the filter requires a
login.
So: https://issues.apache.org/jira/browse/MNG-6928 is viewable without
a login https://issues.apache.org/jira/browse/MNG-6928?filter=-2 is
not.

Bindul

On Fri, Sep 11, 2020 at 12:54 AM Maarten Mulders  wrote:
>
> Agreed. If there's anything that is too deliberate to discuss in the
> open, there's the mailing list, direct email or what not.
>
> Maarten
>
> On 11/09/2020 09:51, Robert Scholte wrote:
> > Based on the https://twitter.com/ameliaeiras/status/1303815661307613184 and 
> > the responses of Marten Deinum I agree that it makes sense to make issues 
> > viewable for all.
> >
> > If there is no strong reason to keep it as it is, I'll ask our Jira 
> > administrator if our scheme can be updated.
> > (looks like the Maven projects are missing an explicit Issue Security 
> > scheme)
> >
> > thanks,
> > Robert
> >
>
> -
> 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] Make Jira issues viewable.

[Maarten Mulders]

Agreed. If there's anything that is too deliberate to discuss in the 
open, there's the mailing list, direct email or what not.


Maarten

On 11/09/2020 09:51, Robert Scholte wrote:

Based on the https://twitter.com/ameliaeiras/status/1303815661307613184 and the 
responses of Marten Deinum I agree that it makes sense to make issues viewable 
for all.

If there is no strong reason to keep it as it is, I'll ask our Jira 
administrator if our scheme can be updated.
(looks like the Maven projects are missing an explicit Issue Security scheme)

thanks,
Robert



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

[DISCUSS] Make Jira issues viewable.

[Robert Scholte]

Based on the https://twitter.com/ameliaeiras/status/1303815661307613184 and the 
responses of Marten Deinum I agree that it makes sense to make issues viewable 
for all.

If there is no strong reason to keep it as it is, I'll ask our Jira 
administrator if our scheme can be updated.
(looks like the Maven projects are missing an explicit Issue Security scheme)

thanks,
Robert

[GitHub] [maven-project-utils] pzygielo commented on a change in pull request #3: update JIRA URL

[GitBox]

pzygielo commented on a change in pull request #3:
URL: https://github.com/apache/maven-project-utils/pull/3#discussion_r453213245



##
File path: pom.xml
##
@@ -46,7 +46,7 @@ under the License.
   
   
 jira
-https://issues.apache.org/jira/browse/MSHARED/component/12329913
+
https://issues.apache.org/jira/browse/MSHARED-933?jql=project%20%3D%20MSHARED%20AND%20component%20%3D%20maven-project-utils

Review comment:
   IMO it would be better without reference to specific issue, ie. 
`https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20component%20%3D%20maven-project-utils`.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-project-utils] slachiewicz merged pull request #3: update JIRA URL

[GitBox]

slachiewicz merged pull request #3:
URL: https://github.com/apache/maven-project-utils/pull/3


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-project-utils] elharo opened a new pull request #3: update JIRA URL

[GitBox]

elharo opened a new pull request #3:
URL: https://github.com/apache/maven-project-utils/pull/3


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

https://issues.apache.org/jira/browse/MDEP-480

[Benson Margulies]

I'm helping someone dust this off as a warm up to development in the
plugin. Could folks have a look at the JIRA and see if the feature makes
sense?

Re: JIRA issues for dependency upgrades

[Karl Heinz Marbaise]

Hi,

On 27.04.20 17:10, Michael Osipov wrote:

Am 2020-04-27 um 16:20 schrieb Elliotte Rusty Harold:

Does the community have an consensus on whether to file JIRA tickets
for minor dependency upgrades that don't require large code changes?
I've been getting conflicting advice about this in code reviews.

Here's what our docs currently say, but you'll notice that dependency
upgrades fall somewhere in between the two cases mentioned:

When To Create a JIRA Issue?

This section discusses when to create a JIRA issue versus just
committing a change in Git (eventually through a PR).

Minor changes such as code reformatting, documentation fixes, etc.
that aren’t going to impact other users can be committed without a
JIRA issue.

Larger changes such as bug fixes, API changes, significant
refactoring, new classes, and pretty much any change of more than 100
lines, should have JIRA tickets.


My opinion is clearly, yes. There must be a ticket for dep upgrades. You
have seen recently where a patch update of a Plexus Component has caused
a regression and you have spent time to track it down. Such changes
should be user visible.

The reason my I prefer JIRA issues for almost everything is that I don't
want to maintain a changelog manually. In case of a regression one can
always refer to the JIRA issue.


+1 from me for that approach

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: JIRA issues for dependency upgrades

[Michael Osipov]

Am 2020-04-27 um 16:20 schrieb Elliotte Rusty Harold:

Does the community have an consensus on whether to file JIRA tickets
for minor dependency upgrades that don't require large code changes?
I've been getting conflicting advice about this in code reviews.

Here's what our docs currently say, but you'll notice that dependency
upgrades fall somewhere in between the two cases mentioned:

When To Create a JIRA Issue?

This section discusses when to create a JIRA issue versus just
committing a change in Git (eventually through a PR).

Minor changes such as code reformatting, documentation fixes, etc.
that aren’t going to impact other users can be committed without a
JIRA issue.

Larger changes such as bug fixes, API changes, significant
refactoring, new classes, and pretty much any change of more than 100
lines, should have JIRA tickets.


My opinion is clearly, yes. There must be a ticket for dep upgrades. You 
have seen recently where a patch update of a Plexus Component has caused 
a regression and you have spent time to track it down. Such changes 
should be user visible.


The reason my I prefer JIRA issues for almost everything is that I don't 
want to maintain a changelog manually. In case of a regression one can 
always refer to the JIRA issue.


M


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

JIRA issues for dependency upgrades

[Elliotte Rusty Harold]

Does the community have an consensus on whether to file JIRA tickets
for minor dependency upgrades that don't require large code changes?
I've been getting conflicting advice about this in code reviews.

Here's what our docs currently say, but you'll notice that dependency
upgrades fall somewhere in between the two cases mentioned:

When To Create a JIRA Issue?

This section discusses when to create a JIRA issue versus just
committing a change in Git (eventually through a PR).

Minor changes such as code reformatting, documentation fixes, etc.
that aren’t going to impact other users can be committed without a
JIRA issue.

Larger changes such as bug fixes, API changes, significant
refactoring, new classes, and pretty much any change of more than 100
lines, should have JIRA tickets.






-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

[Elliotte Rusty Harold]

This morning I finished reviewing the last of these issues. Only four
remain untouched, all of which were previously autoclosed and
reopened, so we shouldn't autoclose them again.

I didn't keep track of exact numbers of how many I closed,
reprioritized, duped, marked abandoned etc. There were a number of
issues that had long comment threads related to proposed fixes and
changes, indicating that a lot of work and thought had gone into them
but ultimately didn't lead anywhere. In these cases, I tried to make
my best judgement based on the thread as to whether the issue deserved
to stay open or not. Since everything in the list was already
scheduled for closure, I was more aggressive than usual about "Won't
Fixing" and closing issues. If any seem to you to be closed in error,
you're probably right. Please reopen them.

There were a lot of new feature requests that were incomplete and hard
to follow. There were also many patches submitted by non-committers
that had never been reviewed. We might want to rethink how we accept
new feature and model change requests. Filing such a request in Jira
seems likely to lead to a frustrating experience for contributors and
reviewers alike. Perhaps we can ask for more formal design proposals
in a doc outside of Jira that is discussed on the dev mailing list
first before it gets added to the Jira and reserve Jira only for new
features we actively want to do. I'm not sure. But I would prefer not
to be back in this place five years from now.

On Fri, Dec 20, 2019 at 7:14 AM Tibor Digana  wrote:
>
> sorry for typo, in the backlog they should not be closed because they are
> serious bugs and need to be fixed.
>
> On Fri, Dec 20, 2019 at 1:11 PM Tibor Digana  wrote:
>
> > I want to review the closed issues as well i would like to come up with
> > those which should be reopened to a certain release version.
> > I guess the release version should be set in such case.
> > We have also backlog version and that's the place where the issues should
> > be closed be the version has not been proposed yet.
> >
> > On Fri, Dec 20, 2019 at 12:49 PM Elliotte Rusty Harold 
> > wrote:
> >
> >> One thing we should try going forward is be more ready to won't fix
> >> and close bugs and RFEs we disagree with. I've seen several examples
> >> where the comments indicate the maintainers did not agree with the
> >> issue, but it still wasn't closed. E.g.
> >>
> >> https://issues.apache.org/jira/browse/SUREFIRE-1227
> >>
> >> Closing an issue is not irrevocable. Issues can always be reopened, if
> >> the reporter or anyone else disagrees. Indeed it is more respectful to
> >> reporters to be politely honest with them about our true objections,
> >> rather than simply ignoring the issue and not responding.
> >>
> >> On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold
> >>  wrote:
> >> >
> >> > While working through the bugs I found this interesting bit of history:
> >> >
> >> >
> >> https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
> >> >
> >> > It seems like we've been here before. Some of the bugs that were
> >> > autoclosed then were reopened and are now scheduled for autoclose
> >> > again. Any thoughts about how we might update our processes to avoid
> >> > getting into this situation again?
> >> >
> >> > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov 
> >> wrote:
> >> > >
> >> > > Hi folks,
> >> > >
> >> > > after at least one year of silence, I'd like to perform another JIRA
> >> > > issue cleanup for issues which have been not touched for more than
> >> three
> >> > > years.
> >> > >
> >> > > Query:
> >> > >
> >> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> >> > >
> >> > > Stats:
> >> > >
> >> > > 567 issues not touched for more than three years
> >> > > of which
> >> > > * 68 have fix version set
> >> > > * 36 were already reopened, should they be excluded?
> >> > > * 1 in progress by Karl
> >> > >
> >> > > Type breakdown:
> >> > > * 200 bugs
> >> > > * 164 improvements
> >> > > * 72 new features
> >> > > * 6 subtasks
> >> > > * 13 tasks
> >> > > * 12 wishes
>

Re: Yearly JIRA cleanup

[Tibor Digana]

sorry for typo, in the backlog they should not be closed because they are
serious bugs and need to be fixed.

On Fri, Dec 20, 2019 at 1:11 PM Tibor Digana  wrote:

> I want to review the closed issues as well i would like to come up with
> those which should be reopened to a certain release version.
> I guess the release version should be set in such case.
> We have also backlog version and that's the place where the issues should
> be closed be the version has not been proposed yet.
>
> On Fri, Dec 20, 2019 at 12:49 PM Elliotte Rusty Harold 
> wrote:
>
>> One thing we should try going forward is be more ready to won't fix
>> and close bugs and RFEs we disagree with. I've seen several examples
>> where the comments indicate the maintainers did not agree with the
>> issue, but it still wasn't closed. E.g.
>>
>> https://issues.apache.org/jira/browse/SUREFIRE-1227
>>
>> Closing an issue is not irrevocable. Issues can always be reopened, if
>> the reporter or anyone else disagrees. Indeed it is more respectful to
>> reporters to be politely honest with them about our true objections,
>> rather than simply ignoring the issue and not responding.
>>
>> On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold
>>  wrote:
>> >
>> > While working through the bugs I found this interesting bit of history:
>> >
>> >
>> https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
>> >
>> > It seems like we've been here before. Some of the bugs that were
>> > autoclosed then were reopened and are now scheduled for autoclose
>> > again. Any thoughts about how we might update our processes to avoid
>> > getting into this situation again?
>> >
>> > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov 
>> wrote:
>> > >
>> > > Hi folks,
>> > >
>> > > after at least one year of silence, I'd like to perform another JIRA
>> > > issue cleanup for issues which have been not touched for more than
>> three
>> > > years.
>> > >
>> > > Query:
>> > >
>> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
>> > >
>> > > Stats:
>> > >
>> > > 567 issues not touched for more than three years
>> > > of which
>> > > * 68 have fix version set
>> > > * 36 were already reopened, should they be excluded?
>> > > * 1 in progress by Karl
>> > >
>> > > Type breakdown:
>> > > * 200 bugs
>> > > * 164 improvements
>> > > * 72 new features
>> > > * 6 subtasks
>> > > * 13 tasks
>> > > * 12 wishes
>> > >
>> > > If there are issues still valid for you please leave a comment on the
>> > > issue and they will not appear in the query anymore.
>> > > Please also raise your voice if you have anything to discuss.
>> > >
>> > > If the issue is not modified or no objection has been raised, I will
>> > > autoclose those issues with a comment by 2019-12-30.
>> > >
>> > > Michael
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> >
>> >
>> > --
>> > Elliotte Rusty Harold
>> > elh...@ibiblio.org
>>
>>
>>
>> --
>> Elliotte Rusty Harold
>> elh...@ibiblio.org
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: Yearly JIRA cleanup

[Tibor Digana]

I want to review the closed issues as well i would like to come up with
those which should be reopened to a certain release version.
I guess the release version should be set in such case.
We have also backlog version and that's the place where the issues should
be closed be the version has not been proposed yet.

On Fri, Dec 20, 2019 at 12:49 PM Elliotte Rusty Harold 
wrote:

> One thing we should try going forward is be more ready to won't fix
> and close bugs and RFEs we disagree with. I've seen several examples
> where the comments indicate the maintainers did not agree with the
> issue, but it still wasn't closed. E.g.
>
> https://issues.apache.org/jira/browse/SUREFIRE-1227
>
> Closing an issue is not irrevocable. Issues can always be reopened, if
> the reporter or anyone else disagrees. Indeed it is more respectful to
> reporters to be politely honest with them about our true objections,
> rather than simply ignoring the issue and not responding.
>
> On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold
>  wrote:
> >
> > While working through the bugs I found this interesting bit of history:
> >
> >
> https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
> >
> > It seems like we've been here before. Some of the bugs that were
> > autoclosed then were reopened and are now scheduled for autoclose
> > again. Any thoughts about how we might update our processes to avoid
> > getting into this situation again?
> >
> > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov 
> wrote:
> > >
> > > Hi folks,
> > >
> > > after at least one year of silence, I'd like to perform another JIRA
> > > issue cleanup for issues which have been not touched for more than
> three
> > > years.
> > >
> > > Query:
> > >
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> > >
> > > Stats:
> > >
> > > 567 issues not touched for more than three years
> > > of which
> > > * 68 have fix version set
> > > * 36 were already reopened, should they be excluded?
> > > * 1 in progress by Karl
> > >
> > > Type breakdown:
> > > * 200 bugs
> > > * 164 improvements
> > > * 72 new features
> > > * 6 subtasks
> > > * 13 tasks
> > > * 12 wishes
> > >
> > > If there are issues still valid for you please leave a comment on the
> > > issue and they will not appear in the query anymore.
> > > Please also raise your voice if you have anything to discuss.
> > >
> > > If the issue is not modified or no objection has been raised, I will
> > > autoclose those issues with a comment by 2019-12-30.
> > >
> > > Michael
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Yearly JIRA cleanup

[Elliotte Rusty Harold]

Please share the new query for this. It would give me fewer issues to look at.

By the way, I've chopped the original list from over four hundred to
just over two hundred, learned a lot about Maven in the process, found
one or two gems that have serious impact at my day job, and identified
one truly scary security issue someone badly needs to look at.

On Fri, Dec 20, 2019 at 6:42 AM Michael Osipov  wrote:
>
> I will exlude those. It does not makes sense to close/reopen again.
>
> Am 2019-12-20 um 12:29 schrieb Elliotte Rusty Harold:
> > While working through the bugs I found this interesting bit of history:
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
> >
> > It seems like we've been here before. Some of the bugs that were
> > autoclosed then were reopened and are now scheduled for autoclose
> > again. Any thoughts about how we might update our processes to avoid
> > getting into this situation again?
> >
> > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
> >>
> >> Hi folks,
> >>
> >> after at least one year of silence, I'd like to perform another JIRA
> >> issue cleanup for issues which have been not touched for more than three
> >> years.
> >>
> >> Query:
> >> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> >>
> >> Stats:
> >>
> >> 567 issues not touched for more than three years
> >> of which
> >> * 68 have fix version set
> >> * 36 were already reopened, should they be excluded?
> >> * 1 in progress by Karl
> >>
> >> Type breakdown:
> >> * 200 bugs
> >> * 164 improvements
> >> * 72 new features
> >> * 6 subtasks
> >> * 13 tasks
> >> * 12 wishes
> >>
> >> If there are issues still valid for you please leave a comment on the
> >> issue and they will not appear in the query anymore.
> >> Please also raise your voice if you have anything to discuss.
> >>
> >> If the issue is not modified or no objection has been raised, I will
> >> autoclose those issues with a comment by 2019-12-30.
> >>
> >> Michael
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> >
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

[Elliotte Rusty Harold]

One thing we should try going forward is be more ready to won't fix
and close bugs and RFEs we disagree with. I've seen several examples
where the comments indicate the maintainers did not agree with the
issue, but it still wasn't closed. E.g.

https://issues.apache.org/jira/browse/SUREFIRE-1227

Closing an issue is not irrevocable. Issues can always be reopened, if
the reporter or anyone else disagrees. Indeed it is more respectful to
reporters to be politely honest with them about our true objections,
rather than simply ignoring the issue and not responding.

On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold
 wrote:
>
> While working through the bugs I found this interesting bit of history:
>
> https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
>
> It seems like we've been here before. Some of the bugs that were
> autoclosed then were reopened and are now scheduled for autoclose
> again. Any thoughts about how we might update our processes to avoid
> getting into this situation again?
>
> On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
> >
> > Hi folks,
> >
> > after at least one year of silence, I'd like to perform another JIRA
> > issue cleanup for issues which have been not touched for more than three
> > years.
> >
> > Query:
> > https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> >
> > Stats:
> >
> > 567 issues not touched for more than three years
> > of which
> > * 68 have fix version set
> > * 36 were already reopened, should they be excluded?
> > * 1 in progress by Karl
> >
> > Type breakdown:
> > * 200 bugs
> > * 164 improvements
> > * 72 new features
> > * 6 subtasks
> > * 13 tasks
> > * 12 wishes
> >
> > If there are issues still valid for you please leave a comment on the
> > issue and they will not appear in the query anymore.
> > Please also raise your voice if you have anything to discuss.
> >
> > If the issue is not modified or no objection has been raised, I will
> > autoclose those issues with a comment by 2019-12-30.
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

[Michael Osipov]

I will exlude those. It does not makes sense to close/reopen again.

Am 2019-12-20 um 12:29 schrieb Elliotte Rusty Harold:

While working through the bugs I found this interesting bit of history:

https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014

It seems like we've been here before. Some of the bugs that were
autoclosed then were reopened and are now scheduled for autoclose
again. Any thoughts about how we might update our processes to avoid
getting into this situation again?

On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:


Hi folks,

after at least one year of silence, I'd like to perform another JIRA
issue cleanup for issues which have been not touched for more than three
years.

Query:
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC

Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the
issue and they will not appear in the query anymore.
Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will
autoclose those issues with a comment by 2019-12-30.

Michael

-
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: Yearly JIRA cleanup

[Elliotte Rusty Harold]

While working through the bugs I found this interesting bit of history:

https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014

It seems like we've been here before. Some of the bugs that were
autoclosed then were reopened and are now scheduled for autoclose
again. Any thoughts about how we might update our processes to avoid
getting into this situation again?

On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
>
> Hi folks,
>
> after at least one year of silence, I'd like to perform another JIRA
> issue cleanup for issues which have been not touched for more than three
> years.
>
> Query:
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
>
> Stats:
>
> 567 issues not touched for more than three years
> of which
> * 68 have fix version set
> * 36 were already reopened, should they be excluded?
> * 1 in progress by Karl
>
> Type breakdown:
> * 200 bugs
> * 164 improvements
> * 72 new features
> * 6 subtasks
> * 13 tasks
> * 12 wishes
>
> If there are issues still valid for you please leave a comment on the
> issue and they will not appear in the query anymore.
> Please also raise your voice if you have anything to discuss.
>
> If the issue is not modified or no objection has been raised, I will
> autoclose those issues with a comment by 2019-12-30.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Release 3.6.0 - cleaning up JIRA

[Karl Heinz Marbaise]

Ah sorry...

now I'm not able to read...

everything fine...

Kind regards
Karl Heinz Marbaise

On 15.12.19 22:58, Karl Heinz Marbaise wrote:

Hi,

to be honest I'm confused as well?

Have we decided to do a another 3.6.X release? Did I miss something?

Kind regards
Karl Heinz Marbaise
On 15.12.19 12:07, Elliotte Rusty Harold wrote:

I notice I'm confused. Wasn't Maven 3.6.0-3.6.3 already released?

On Sat, Dec 14, 2019 at 2:28 PM Enrico Olivelli 
wrote:


HI,
I have moved to fixversion=3.7.0 all of the issues with fixversion =
3.6.0
and resolution = empty.

Please add the '3.6.0' label to the issues that should go into 3.6.0.

Candidates are:
- blocker issues (regressions)
- build environment issues
- flaky tests
- patches that are really ready for commit, just last round of
review/comment resolution (we have a few)
- missing documentation for new important features
- license files related issues (we are now adding OpenSSL for instance)
- upgrade of dependencies flagged by OWASP or any other public directory
.

As soon as I create the branch-3.6 please ping me on every patch you
want
to cherry pick




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

Re: Release 3.6.0 - cleaning up JIRA

[Karl Heinz Marbaise]

Hi,

to be honest I'm confused as well?

Have we decided to do a another 3.6.X release? Did I miss something?

Kind regards
Karl Heinz Marbaise
On 15.12.19 12:07, Elliotte Rusty Harold wrote:

I notice I'm confused. Wasn't Maven 3.6.0-3.6.3 already released?

On Sat, Dec 14, 2019 at 2:28 PM Enrico Olivelli  wrote:


HI,
I have moved to fixversion=3.7.0 all of the issues with fixversion = 3.6.0
and resolution = empty.

Please add the '3.6.0' label to the issues that should go into 3.6.0.

Candidates are:
- blocker issues (regressions)
- build environment issues
- flaky tests
- patches that are really ready for commit, just last round of
review/comment resolution (we have a few)
- missing documentation for new important features
- license files related issues (we are now adding OpenSSL for instance)
- upgrade of dependencies flagged by OWASP or any other public directory
.

As soon as I create the branch-3.6 please ping me on every patch you want
to cherry pick


Best regards
Enrico


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

Re: Release 3.6.0 - cleaning up JIRA

[Enrico Olivelli]

@Elliotte
I am so sorry
I meant to send that email to d...@zookeeper.apache.org
Gmail autopletion changed that address

I apologize for the inconvenience

Enrico

Il giorno dom 15 dic 2019 alle ore 12:08 Elliotte Rusty Harold <
elh...@ibiblio.org> ha scritto:

> I notice I'm confused. Wasn't Maven 3.6.0-3.6.3 already released?
>
> On Sat, Dec 14, 2019 at 2:28 PM Enrico Olivelli 
> wrote:
> >
> > HI,
> > I have moved to fixversion=3.7.0 all of the issues with fixversion =
> 3.6.0
> > and resolution = empty.
> >
> > Please add the '3.6.0' label to the issues that should go into 3.6.0.
> >
> > Candidates are:
> > - blocker issues (regressions)
> > - build environment issues
> > - flaky tests
> > - patches that are really ready for commit, just last round of
> > review/comment resolution (we have a few)
> > - missing documentation for new important features
> > - license files related issues (we are now adding OpenSSL for instance)
> > - upgrade of dependencies flagged by OWASP or any other public directory
> > .
> >
> > As soon as I create the branch-3.6 please ping me on every patch you want
> > to cherry pick
> >
> >
> > Best regards
> > Enrico
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Release 3.6.0 - cleaning up JIRA

[Elliotte Rusty Harold]

I notice I'm confused. Wasn't Maven 3.6.0-3.6.3 already released?

On Sat, Dec 14, 2019 at 2:28 PM Enrico Olivelli  wrote:
>
> HI,
> I have moved to fixversion=3.7.0 all of the issues with fixversion = 3.6.0
> and resolution = empty.
>
> Please add the '3.6.0' label to the issues that should go into 3.6.0.
>
> Candidates are:
> - blocker issues (regressions)
> - build environment issues
> - flaky tests
> - patches that are really ready for commit, just last round of
> review/comment resolution (we have a few)
> - missing documentation for new important features
> - license files related issues (we are now adding OpenSSL for instance)
> - upgrade of dependencies flagged by OWASP or any other public directory
> .
>
> As soon as I create the branch-3.6 please ping me on every patch you want
> to cherry pick
>
>
> Best regards
> Enrico



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Release 3.6.0 - cleaning up JIRA

[Enrico Olivelli]

HI,
I have moved to fixversion=3.7.0 all of the issues with fixversion = 3.6.0
and resolution = empty.

Please add the '3.6.0' label to the issues that should go into 3.6.0.

Candidates are:
- blocker issues (regressions)
- build environment issues
- flaky tests
- patches that are really ready for commit, just last round of
review/comment resolution (we have a few)
- missing documentation for new important features
- license files related issues (we are now adding OpenSSL for instance)
- upgrade of dependencies flagged by OWASP or any other public directory
.

As soon as I create the branch-3.6 please ping me on every patch you want
to cherry pick


Best regards
Enrico

Re: Yearly JIRA cleanup

[Michael Osipov]

Am 2019-12-13 um 16:08 schrieb Elliotte Rusty Harold:

NVM, I seem to have access now. I think I just needed to logout with
my old credentials and back in with the new ones.


Elliotte,

please go through the list and update those tickets you seen to be 
addressible within a decent timeframe.


Michael

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

Re: Yearly JIRA cleanup

[Elliotte Rusty Harold]

NVM, I seem to have access now. I think I just needed to logout with
my old credentials and back in with the new ones.

On Fri, Dec 13, 2019 at 9:56 AM Elliotte Rusty Harold
 wrote:
>
> On Thu, Dec 12, 2019 at 6:56 PM Stephen Connolly
>  wrote:
> > I think we have some crazy permissions that Brian manages. Ldap just fixes
> > the account name to match across systems AIUI
> >
>
> That's probably true. As of an hour ago, I did not seem able to close issues.
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

[Elliotte Rusty Harold]

On Thu, Dec 12, 2019 at 6:56 PM Stephen Connolly
 wrote:
> I think we have some crazy permissions that Brian manages. Ldap just fixes
> the account name to match across systems AIUI
>

That's probably true. As of an hour ago, I did not seem able to close issues.


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

[Stephen Connolly]

On Thu 12 Dec 2019 at 17:31, Robert Scholte  wrote:

> IIUC since Jira uses the ASF LDAP, there's no extra need for Brian to do
> this anymore. All should be in place by now.
>

I think we have some crazy permissions that Brian manages. Ldap just fixes
the account name to match across systems AIUI

>
> thanks,
> Robert
> On 12-12-2019 15:20:24, Stephen Connolly 
> wrote:
> On Mon 9 Dec 2019 at 20:53, Elliotte Rusty Harold
> wrote:
>
> > On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov wrote:
> > >
> > > Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > > > Please don't. There are certainly some real and important issues in
> > > > there. More importantly, users spent a great deal of effort and time
> > > > to file those. Bulk closing them tells those users we don't value
> > > > their feedback or effort. It is useful to triage these issues and
> > > > consider them individually. Doubtless many of these issues are
> already
> > > > fixed, moot, or things we expressly chose not to do. However this
> > > > should be decided case by case. We can't simply close our eyes and
> > > > pretend they're all irrelevant.
> > >
> > > Hi Elliotte,
> >
> > > We have almost 2000 open issues. How would you reasonably sieve between
> > > them? even if you allocate 10 min per ticket, you would need two months
> > > of work to triage them.
> > >
> >
> > Use the time we have to fix as much as we can. Leave the rest open.
> > Some will never be touched but some will be when someone encounters
> > the same problem and finds the bug again. It's better to leave it open
> > and unaddressed than to close it without giving it a fair look.
> >
> > As to time spent triaging, it's worth considering whether permissions
> > could be opened up further. Right now, almost anyone can file a bug
> > but few people can resolve and close them. I can't, for example, even
> > when I see one that's clearly no longer relevant. :-(
>
>
> As soon as Brian fixes your JIRA permissions you’ll be able too... your
> committer status is only freshly minted! (welcome/congrats)
>
> Another issue is the lack of a clearly defined process for triage. We
> should document what we mean by triage and what outcomes we expect. That
> could even include closing stale issues after a check for active reporters
>
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > 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: Yearly JIRA cleanup

[Robert Scholte]

IIUC since Jira uses the ASF LDAP, there's no extra need for Brian to do this 
anymore. All should be in place by now.

thanks,
Robert
On 12-12-2019 15:20:24, Stephen Connolly  
wrote:
On Mon 9 Dec 2019 at 20:53, Elliotte Rusty Harold
wrote:

> On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov wrote:
> >
> > Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > > Please don't. There are certainly some real and important issues in
> > > there. More importantly, users spent a great deal of effort and time
> > > to file those. Bulk closing them tells those users we don't value
> > > their feedback or effort. It is useful to triage these issues and
> > > consider them individually. Doubtless many of these issues are already
> > > fixed, moot, or things we expressly chose not to do. However this
> > > should be decided case by case. We can't simply close our eyes and
> > > pretend they're all irrelevant.
> >
> > Hi Elliotte,
>
> > We have almost 2000 open issues. How would you reasonably sieve between
> > them? even if you allocate 10 min per ticket, you would need two months
> > of work to triage them.
> >
>
> Use the time we have to fix as much as we can. Leave the rest open.
> Some will never be touched but some will be when someone encounters
> the same problem and finds the bug again. It's better to leave it open
> and unaddressed than to close it without giving it a fair look.
>
> As to time spent triaging, it's worth considering whether permissions
> could be opened up further. Right now, almost anyone can file a bug
> but few people can resolve and close them. I can't, for example, even
> when I see one that's clearly no longer relevant. :-(


As soon as Brian fixes your JIRA permissions you’ll be able too... your
committer status is only freshly minted! (welcome/congrats)

Another issue is the lack of a clearly defined process for triage. We
should document what we mean by triage and what outcomes we expect. That
could even include closing stale issues after a check for active reporters

>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.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: Yearly JIRA cleanup

[Stephen Connolly]

On Mon 9 Dec 2019 at 20:53, Elliotte Rusty Harold 
wrote:

> On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov  wrote:
> >
> > Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > > Please don't. There are certainly some real and important issues in
> > > there. More importantly, users spent a great deal of effort and time
> > > to file those. Bulk closing them tells those users we don't value
> > > their feedback or effort. It is useful to triage these issues and
> > > consider them individually. Doubtless many of these issues are already
> > > fixed, moot, or things we expressly chose not to do. However this
> > > should be decided case by case. We can't simply close our eyes and
> > > pretend they're all irrelevant.
> >
> > Hi Elliotte,
>
> > We have almost 2000 open issues. How would you reasonably sieve between
> > them? even if you allocate 10 min per ticket, you would need two months
> > of work to triage them.
> >
>
> Use the time we have to fix as much as we can. Leave the rest open.
> Some will never be touched but some will be when someone encounters
> the same problem and finds the bug again. It's better to leave it open
> and unaddressed than to close it without giving it a fair look.
>
> As to time spent triaging, it's worth considering whether permissions
> could be opened up further. Right now, almost anyone can file a bug
> but few people can resolve and close them. I can't, for example, even
> when I see one that's clearly no longer relevant. :-(


As soon as Brian fixes your JIRA permissions you’ll be able too... your
committer status is only freshly minted! (welcome/congrats)

Another issue is the lack of a clearly defined process for triage. We
should document what we mean by triage and what outcomes we expect. That
could even include closing stale issues after a check for active reporters

>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.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: Yearly JIRA cleanup

[Elliotte Rusty Harold]

On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov  wrote:
>
> Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > Please don't. There are certainly some real and important issues in
> > there. More importantly, users spent a great deal of effort and time
> > to file those. Bulk closing them tells those users we don't value
> > their feedback or effort. It is useful to triage these issues and
> > consider them individually. Doubtless many of these issues are already
> > fixed, moot, or things we expressly chose not to do. However this
> > should be decided case by case. We can't simply close our eyes and
> > pretend they're all irrelevant.
>
> Hi Elliotte,

> We have almost 2000 open issues. How would you reasonably sieve between
> them? even if you allocate 10 min per ticket, you would need two months
> of work to triage them.
>

Use the time we have to fix as much as we can. Leave the rest open.
Some will never be touched but some will be when someone encounters
the same problem and finds the bug again. It's better to leave it open
and unaddressed than to close it without giving it a fair look.

As to time spent triaging, it's worth considering whether permissions
could be opened up further. Right now, almost anyone can file a bug
but few people can resolve and close them. I can't, for example, even
when I see one that's clearly no longer relevant. :-(

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

[Michael Osipov]

Take your time, you have at least three weeks.

Am 2019-12-08 um 18:23 schrieb Tibor Digana:

Hi Michael,

What's up :-)
Thx for making the list of issues.
Pls give me one day to see it completely. I will get back to you tomorrow.

Cheers
Tibor17

On Sun, Dec 8, 2019 at 6:08 PM Elliotte Rusty Harold 
wrote:


Please don't. There are certainly some real and important issues in
there. More importantly, users spent a great deal of effort and time
to file those. Bulk closing them tells those users we don't value
their feedback or effort. It is useful to triage these issues and
consider them individually. Doubtless many of these issues are already
fixed, moot, or things we expressly chose not to do. However this
should be decided case by case. We can't simply close our eyes and
pretend they're all irrelevant.

On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:


Hi folks,

after at least one year of silence, I'd like to perform another JIRA
issue cleanup for issues which have been not touched for more than three
years.

Query:


https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC


Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the
issue and they will not appear in the query anymore.
Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will
autoclose those issues with a comment by 2019-12-30.

Michael

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




--
Elliotte Rusty Harold
elh...@ibiblio.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: Yearly JIRA cleanup

[Michael Osipov]

Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:

Please don't. There are certainly some real and important issues in
there. More importantly, users spent a great deal of effort and time
to file those. Bulk closing them tells those users we don't value
their feedback or effort. It is useful to triage these issues and
consider them individually. Doubtless many of these issues are already
fixed, moot, or things we expressly chose not to do. However this
should be decided case by case. We can't simply close our eyes and
pretend they're all irrelevant.


Hi Elliotte,

I share your concerns. I do traverse through tickets once in a while and 
check for samples projects. Please also feel free to go through the list 
and update them.
At the end we need to be honest. I.e., if we weren't to triage them 
within three years, we likely never won't. We honestly tell that we 
acknowledge the issue, but are simply unable to do anything fruitful.


We have almost 2000 open issues. How would you reasonably sieve between 
them? even if you allocate 10 min per ticket, you would need two months 
of work to triage them.


Regards,

Michael


On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:


Hi folks,

after at least one year of silence, I'd like to perform another JIRA
issue cleanup for issues which have been not touched for more than three
years.

Query:
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC

Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the
issue and they will not appear in the query anymore.
Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will
autoclose those issues with a comment by 2019-12-30.

Michael

-
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: Yearly JIRA cleanup

[Tibor Digana]

Hi Michael,

What's up :-)
Thx for making the list of issues.
Pls give me one day to see it completely. I will get back to you tomorrow.

Cheers
Tibor17

On Sun, Dec 8, 2019 at 6:08 PM Elliotte Rusty Harold 
wrote:

> Please don't. There are certainly some real and important issues in
> there. More importantly, users spent a great deal of effort and time
> to file those. Bulk closing them tells those users we don't value
> their feedback or effort. It is useful to triage these issues and
> consider them individually. Doubtless many of these issues are already
> fixed, moot, or things we expressly chose not to do. However this
> should be decided case by case. We can't simply close our eyes and
> pretend they're all irrelevant.
>
> On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
> >
> > Hi folks,
> >
> > after at least one year of silence, I'd like to perform another JIRA
> > issue cleanup for issues which have been not touched for more than three
> > years.
> >
> > Query:
> >
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> >
> > Stats:
> >
> > 567 issues not touched for more than three years
> > of which
> > * 68 have fix version set
> > * 36 were already reopened, should they be excluded?
> > * 1 in progress by Karl
> >
> > Type breakdown:
> > * 200 bugs
> > * 164 improvements
> > * 72 new features
> > * 6 subtasks
> > * 13 tasks
> > * 12 wishes
> >
> > If there are issues still valid for you please leave a comment on the
> > issue and they will not appear in the query anymore.
> > Please also raise your voice if you have anything to discuss.
> >
> > If the issue is not modified or no objection has been raised, I will
> > autoclose those issues with a comment by 2019-12-30.
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Yearly JIRA cleanup

[Elliotte Rusty Harold]

Please don't. There are certainly some real and important issues in
there. More importantly, users spent a great deal of effort and time
to file those. Bulk closing them tells those users we don't value
their feedback or effort. It is useful to triage these issues and
consider them individually. Doubtless many of these issues are already
fixed, moot, or things we expressly chose not to do. However this
should be decided case by case. We can't simply close our eyes and
pretend they're all irrelevant.

On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
>
> Hi folks,
>
> after at least one year of silence, I'd like to perform another JIRA
> issue cleanup for issues which have been not touched for more than three
> years.
>
> Query:
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
>
> Stats:
>
> 567 issues not touched for more than three years
> of which
> * 68 have fix version set
> * 36 were already reopened, should they be excluded?
> * 1 in progress by Karl
>
> Type breakdown:
> * 200 bugs
> * 164 improvements
> * 72 new features
> * 6 subtasks
> * 13 tasks
> * 12 wishes
>
> If there are issues still valid for you please leave a comment on the
> issue and they will not appear in the query anymore.
> Please also raise your voice if you have anything to discuss.
>
> If the issue is not modified or no objection has been raised, I will
> autoclose those issues with a comment by 2019-12-30.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

[Michael Osipov]

Am 2019-12-08 um 13:55 schrieb Maarten Mulders:

Hi Michael,

Great initiative. After logging in to JIRA, accessing your link shows 
"The requested filter doesn't exist or is private."
This means I'm not able to verify whether there are issues in that list 
that are valid for me.

Is there another way to find those issues?


Apologies, here is the proper filter: 
https://issues.apache.org/jira/issues/?jql=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC


I forgot to remove the filter id for my custom saved search.

Michael


On December 8, 2019 at 13:50, Michael Osipov wrote:


Hi folks,

after at least one year of silence, I'd like to perform another JIRA 
issue cleanup for issues which have been not touched for more than 
three years.


Query: 
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC 



Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the 
issue and they will not appear in the query anymore.

Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will 
autoclose those issues with a comment by 2019-12-30.


Michael

-
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: Yearly JIRA cleanup

[Maarten Mulders]

Hi Michael,

Great initiative. After logging in to JIRA, accessing your link shows 
"The requested filter doesn't exist or is private."
This means I'm not able to verify whether there are issues in that list 
that are valid for me.

Is there another way to find those issues?

Cheers,

Maarten

On December 8, 2019 at 13:50, Michael Osipov wrote:


Hi folks,

after at least one year of silence, I'd like to perform another JIRA 
issue cleanup for issues which have been not touched for more than 
three years.


Query: 
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC


Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the 
issue and they will not appear in the query anymore.

Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will 
autoclose those issues with a comment by 2019-12-30.


Michael

-
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

Yearly JIRA cleanup

[Michael Osipov]

Hi folks,

after at least one year of silence, I'd like to perform another JIRA 
issue cleanup for issues which have been not touched for more than three 
years.


Query: 
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC


Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the 
issue and they will not appear in the query anymore.

Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will 
autoclose those issues with a comment by 2019-12-30.


Michael

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

Re: [jira] [Updated] (MSHARED-841) Upgrade Commons Collections to 4.2

[Eric Lilja]

On 2019-10-19 23:55, Sylwester Lachiewicz wrote:

I always read the release notes very carefully and I don't mind seeing 
individual JIRA's per upgrade, even if does increase the length of the 
release notes. I guess others only want to see features and possibly bug 
fixes. Personally I like details. And if there is one JIRA per upgrade, 
it maps better to the git log because I don't think people are bumping 
unrelated dependencies in the same commit, right?


However, my question is why version 4.2 was selected. 4.4 is out, is 
there something broken in versions > 4.2?


- Eric L


Yes Robert, thank you for the suggestions - more changes of this type will
be combined.
Sylwester

sob., 19 paź 2019 o 22:32 Robert Scholte  napisał(a):


Maybe it is me, be I don't think having a separate jira issue for every
updated dependency adds value.
It makes the release notes unnecessary long (in a time where people
already are bad readers).
As a user I expect dependency updates to be part of every release.
1 Jira item would be good enough for me, where you sum up all dependency
changes.
Different commits can refer to the same Jira if you want.

Robert

On Sat, 19 Oct 2019 22:15:00 +0200, Sylwester Lachiewicz (Jira)
 wrote:


  [


https://issues.apache.org/jira/browse/MSHARED-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel


]

Sylwester Lachiewicz updated MSHARED-841:
-
 Fix Version/s: maven-shared-jar-3.0.0


Upgrade Commons Collections to 4.2
--

 Key: MSHARED-841
 URL: https://issues.apache.org/jira/browse/MSHARED-841
 Project: Maven Shared Components
  Issue Type: Dependency upgrade
  Components: maven-shared-jar
Reporter: Sylwester Lachiewicz
Priority: Minor
 Fix For: maven-shared-jar-3.0.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)




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

Re: [jira] [Updated] (MSHARED-841) Upgrade Commons Collections to 4.2

[Sylwester Lachiewicz]

Yes Robert, thank you for the suggestions - more changes of this type will
be combined.
Sylwester

sob., 19 paź 2019 o 22:32 Robert Scholte  napisał(a):

> Maybe it is me, be I don't think having a separate jira issue for every
> updated dependency adds value.
> It makes the release notes unnecessary long (in a time where people
> already are bad readers).
> As a user I expect dependency updates to be part of every release.
> 1 Jira item would be good enough for me, where you sum up all dependency
> changes.
> Different commits can refer to the same Jira if you want.
>
> Robert
>
> On Sat, 19 Oct 2019 22:15:00 +0200, Sylwester Lachiewicz (Jira)
>  wrote:
>
> >
> >  [
> >
> https://issues.apache.org/jira/browse/MSHARED-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>
> > ]
> >
> > Sylwester Lachiewicz updated MSHARED-841:
> > -
> > Fix Version/s: maven-shared-jar-3.0.0
> >
> >> Upgrade Commons Collections to 4.2
> >> --
> >>
> >> Key: MSHARED-841
> >> URL: https://issues.apache.org/jira/browse/MSHARED-841
> >> Project: Maven Shared Components
> >>  Issue Type: Dependency upgrade
> >>  Components: maven-shared-jar
> >>Reporter: Sylwester Lachiewicz
> >>Priority: Minor
> >> Fix For: maven-shared-jar-3.0.0
> >>
> >>
> >
> >
> >
> >
> > --
> > This message was sent by Atlassian Jira
> > (v8.3.4#803005)
>

Re: [jira] [Updated] (MSHARED-841) Upgrade Commons Collections to 4.2

[Robert Scholte]

Maybe it is me, be I don't think having a separate jira issue for every  
updated dependency adds value.
It makes the release notes unnecessary long (in a time where people  
already are bad readers).

As a user I expect dependency updates to be part of every release.
1 Jira item would be good enough for me, where you sum up all dependency  
changes.

Different commits can refer to the same Jira if you want.

Robert

On Sat, 19 Oct 2019 22:15:00 +0200, Sylwester Lachiewicz (Jira)  
 wrote:




 [  
https://issues.apache.org/jira/browse/MSHARED-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel  
]


Sylwester Lachiewicz updated MSHARED-841:
-
Fix Version/s: maven-shared-jar-3.0.0


Upgrade Commons Collections to 4.2
--

Key: MSHARED-841
URL: https://issues.apache.org/jira/browse/MSHARED-841
Project: Maven Shared Components
 Issue Type: Dependency upgrade
 Components: maven-shared-jar
   Reporter: Sylwester Lachiewicz
   Priority: Minor
Fix For: maven-shared-jar-3.0.0







--
This message was sent by Atlassian Jira
(v8.3.4#803005)


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

Re: when will the maven jira be ok

[Eric Lilja]

On 2019-08-22 04:39,  wrote:

Works fine for me, are you logged in?

https://issues.apache.org/jira/projects/MNG/summary

- Eric L


when will the maven jira be ok?
it has been down for several days.




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

when will the maven jira be ok

[????]

when will the maven jira be ok?
it has been down for several days.

Re: [jira] [Commented] (MNG-6691) Maven protocol specification

[Tamás Cservenák]

Just fyi, am aware of 3+2 oss solutions out there (the +2 are the trimmed
ones)

On Sat, Jul 6, 2019, 00:26 dzikoysk (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/MNG-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879546#comment-16879546
> ]
>
> dzikoysk commented on MNG-6691:
> ---
>
> Yeah, it's what we need to do now and it's why I'm loking for something
> better. At this moment, we have only 3 open source repository managers
> where 2 of them are just trimmed-down versions of pro (commercial) software
> that is huge and heavy - honestly, I don't think that `yet another` phrase
> just fits here. Also, in our case it's not just Maven support, we're also
> targeting our language and related stuff, nvm, but it is not an option. It
> looks like there is no other resources than sources and we have to stay
> with our present methods. Thanks for your answers, just consider simple
> specification for future users :)
>
> > Maven protocol specification
> > 
> >
> > Key: MNG-6691
> > URL: https://issues.apache.org/jira/browse/MNG-6691
> > Project: Maven
> >  Issue Type: Wish
> >  Components: Documentation:  General
> >Reporter: dzikoysk
> >Priority: Trivial
> >  Labels: documentation
> >
> > There is a lot of guides and docs about "How to start" on [
> maven.apache.org|https://maven.apache.org/] with maven as developer who
> wants to use maven in a project, but I'm not able to find something for
> people working with repository managers. Is there any technical
> specification of maven http/protocol specification/rest api and what's
> required from a custom repository manager to serve requests properly or the
> only way is to search in maven/other repositories like nexus, artifcatory
> sources?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>

Re: Releasing Surefire 2.22.2 - JIRA ?

[Enrico Olivelli]

Il ven 26 apr 2019, 08:50 Olivier Lamy  ha scritto:

> version created
>

Thanks!

Enrico

>
> On Fri, 26 Apr 2019 at 03:12, Enrico Olivelli  wrote:
>
> > Hi,
> > I am cutting release 2.22.2 for surefire.
> > Can any JIRA admin create the 2.22.2 version ?
> >
> > I am also sseing a 2.22.1 version, this is to be closed, isn't it ?
> >
> > Thanks
> > Enrico
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Releasing Surefire 2.22.2 - JIRA ?

[Olivier Lamy]

version created

On Fri, 26 Apr 2019 at 03:12, Enrico Olivelli  wrote:

> Hi,
> I am cutting release 2.22.2 for surefire.
> Can any JIRA admin create the 2.22.2 version ?
>
> I am also sseing a 2.22.1 version, this is to be closed, isn't it ?
>
> Thanks
> Enrico
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Releasing Surefire 2.22.2 - JIRA ?

[Enrico Olivelli]

Hi,
I am cutting release 2.22.2 for surefire.
Can any JIRA admin create the 2.22.2 version ?

I am also sseing a 2.22.1 version, this is to be closed, isn't it ?

Thanks
Enrico

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

Re: Create JIRA project for Maven Scripting Plugin

[Enrico Olivelli]

Ping

Enrico

Il giorno sab 26 gen 2019, 14:56 Enrico Olivelli  ha
scritto:

> Hi Brian,
> can you pick up this activity ?
>
> The plugin is at the very beginning but we already have a contributor
> and I would like to cut the first release soon
>
> Thank you
> Enrico
>
> Il giorno gio 10 gen 2019 alle ore 20:14 Enrico Olivelli
>  ha scritto:
> >
> > Ping
> >
> > Il dom 6 gen 2019, 13:27 Robert Scholte  ha
> scritto:
> >>
> >> Brian,
> >>
> >> can you pick this up?
> >>
> >> thanks,
> >> Robert
> >>
> >> On Sat, 05 Jan 2019 12:11:41 +0100, Enrico Olivelli <
> eolive...@gmail.com>
> >> wrote:
> >>
> >> > Can any admin create this project ?
> >> > for Maven Scripting Plugin
> >> > https://issues.apache.org/jira/browse/MSCRIPTING
> >> >
> >> > Regards
> >> >
> >> > Enrico
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> >
> >
> > -- Enrico Olivelli
>

Re: Create JIRA project for Maven Scripting Plugin

[Enrico Olivelli]

Hi Brian,
can you pick up this activity ?

The plugin is at the very beginning but we already have a contributor
and I would like to cut the first release soon

Thank you
Enrico

Il giorno gio 10 gen 2019 alle ore 20:14 Enrico Olivelli
 ha scritto:
>
> Ping
>
> Il dom 6 gen 2019, 13:27 Robert Scholte  ha scritto:
>>
>> Brian,
>>
>> can you pick this up?
>>
>> thanks,
>> Robert
>>
>> On Sat, 05 Jan 2019 12:11:41 +0100, Enrico Olivelli 
>> wrote:
>>
>> > Can any admin create this project ?
>> > for Maven Scripting Plugin
>> > https://issues.apache.org/jira/browse/MSCRIPTING
>> >
>> > Regards
>> >
>> > Enrico
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
>
>
> -- Enrico Olivelli

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

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

[Hervé BOUTEMY]

work done: you can see the SNAPSHOT result at
https://maven.apache.org/pom-archives/default-plugins-LATEST/

the source is currently in a maven-studies branch:
https://github.com/apache/maven-studies/tree/maven-default-plugins


The is the question of what version to choose and when to release this POM?
I had a new idea: why not make this POM part of Maven core release?
This would clearly show that Apache Maven is not only core but also the 
plugins. And this would give a natural rhythm to releases, that people would 
understand. Last but not least: this would remove the release configuration 
that was not really leaking, but at least was visible

This idea is implemented in MPOM-215 branch of Maven core.
The only issue I found is how to publish the documentation site: I suppose 
we'll find a solution.

WDYT?

Regards,

Hervé

Le mardi 15 janvier 2019, 17:04:27 CET Hervé BOUTEMY a écrit :
> initial content published, as a branch in maven-studies [1]
> 
> I have a few issues that currently will block any release:
> 1. how to configure release plugin without leaking into future projects that
> will inherit?
> 2. how to configure invoker also to be able to create ITs to check that it
> works as expected?
> 
> On documenting, I started the index.apt.
> Currently, packaging plugins do nothing in general, since it's Maven core
> that does the job: I'm curious to see how archetype-packaging is injected
> when configured as extension [2]. But I'm sure that we could override Maven
> core's default bindings: the only requirement will be to make the effort to
> create dedicated packaging artifacts, to avoid putting the whole plugin's
> dependencies in core classloader
> 
> feedback welcome
> 
> Regards,
> 
> Hervé
> 
> [1] https://github.com/apache/maven-studies/tree/maven-default-plugins
> 
> [2] https://maven.apache.org/archetype/archetype-packaging/
> 
> Le lundi 14 janvier 2019, 23:21:05 CET Robert Scholte a écrit :
> > Introducing a new parent might help for some, but not for everybody.
> > If you already have a parent specified, you can't use this.
> > And Maven doesn't support mixins (yet).
> > 
> > We need to document how plugins are controlled.
> > These are probably all variants I can think of
> > - pom.xml
> > - via packaging-plugin
> > - parent (custom or new maven-defaults-plugins)
> > - super pom
> > - maven core
> > 
> > thanks,
> > Robert
> > 
> > On Mon, 14 Jan 2019 12:01:00 +0100, Hervé Boutemy (JIRA) 
> > 
> > wrote:
> > > Hervé Boutemy created MPOM-215:
> > > --
> > > 
> > >  Summary: Create a new parent POM to lock down plugins
> > > 
> > > versions of default lifecycle bindings
> > > 
> > >  Key: MPOM-215
> > >  URL: https://issues.apache.org/jira/browse/MPOM-215
> > >  
> > >  Project: Maven POMs
> > >   
> > >   Issue Type: New Feature
> > >   
> > > Reporter: Hervé Boutemy
> > > 
> > > while working on version upgrade of default plugin bindings, we found
> > > that:
> > > 1. a warning should be displayed MNG-6562
> > > 2. a parent POM would be the easiest solution to lock down every plugins
> > > at once, instead of letting users lock down each plugin separately
> > > 
> > > let's create this parent POM
> > > 
> > > 
> > > 
> > > --
> > > This message was sent by Atlassian JIRA
> > > (v7.6.3#76005)
> > 
> > -
> > 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

[GitHub] maven-pom pull request #4: [MPOM-209] correct jira component url.

[ofarganc]

Github user ofarganc closed the pull request at:

https://github.com/apache/maven-pom/pull/4


---

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

[GitHub] maven-pom pull request #4: [MPOM-209] correct jira component url.

[ofarganc]

GitHub user ofarganc opened a pull request:

https://github.com/apache/maven-pom/pull/4

[MPOM-209] correct jira component url.

The Jira URL with the component Id was not valid id so  changed it to

https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPOM%20AND%20component%20%3D%20asf

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

$ git pull https://github.com/ofarganc/maven-pom 
bugfix/MPOM-209-correct-jira-component-url

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

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


commit 37418b13f4d72960fb4c51a357b3ad9b57e0696f
Author: Oscar Farga 
Date:   2019-01-19T20:17:49Z

[MPOM-209] correct jira component url.

commit d5a68a11879e11e2ff66077246ad34cb0a599d92
Author: Oscar Farga 
Date:   2019-01-19T20:25:24Z

[MPOM-209] Added missing slash.




---

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

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

[Hervé BOUTEMY]

ok ok, stupid me :)

Le mardi 15 janvier 2019, 17:16:57 CET Stephen Connolly a écrit :
> false in the executions?
> 
> On Tue, 15 Jan 2019 at 16:04, Hervé BOUTEMY  wrote:
> > initial content published, as a branch in maven-studies [1]
> > 
> > I have a few issues that currently will block any release:
> > 1. how to configure release plugin without leaking into future projects
> > that
> > will inherit?
> > 2. how to configure invoker also to be able to create ITs to check that it
> > works as expected?
> > 
> > On documenting, I started the index.apt.
> > Currently, packaging plugins do nothing in general, since it's Maven core
> > that
> > does the job: I'm curious to see how archetype-packaging is injected when
> > configured as extension [2]. But I'm sure that we could override Maven
> > core's
> > default bindings: the only requirement will be to make the effort to
> > create
> > dedicated packaging artifacts, to avoid putting the whole plugin's
> > dependencies in core classloader
> > 
> > feedback welcome
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1] https://github.com/apache/maven-studies/tree/maven-default-plugins
> > 
> > [2] https://maven.apache.org/archetype/archetype-packaging/
> > 
> > Le lundi 14 janvier 2019, 23:21:05 CET Robert Scholte a écrit :
> > > Introducing a new parent might help for some, but not for everybody.
> > > If you already have a parent specified, you can't use this.
> > > And Maven doesn't support mixins (yet).
> > > 
> > > We need to document how plugins are controlled.
> > > These are probably all variants I can think of
> > > - pom.xml
> > > - via packaging-plugin
> > > - parent (custom or new maven-defaults-plugins)
> > > - super pom
> > > - maven core
> > > 
> > > thanks,
> > > Robert
> > > 
> > > On Mon, 14 Jan 2019 12:01:00 +0100, Hervé Boutemy (JIRA) <
> > 
> > j...@apache.org>
> > 
> > > wrote:
> > > > Hervé Boutemy created MPOM-215:
> > > > --
> > > > 
> > > >  Summary: Create a new parent POM to lock down plugins
> > > > 
> > > > versions of default lifecycle bindings
> > > > 
> > > >  Key: MPOM-215
> > > >  URL: https://issues.apache.org/jira/browse/MPOM-215
> > > >  
> > > >  Project: Maven POMs
> > > >   
> > > >   Issue Type: New Feature
> > > >   
> > > > Reporter: Hervé Boutemy
> > > > 
> > > > while working on version upgrade of default plugin bindings, we found
> > > > that:
> > > > 1. a warning should be displayed MNG-6562
> > > > 2. a parent POM would be the easiest solution to lock down every
> > 
> > plugins
> > 
> > > > at once, instead of letting users lock down each plugin separately
> > > > 
> > > > let's create this parent POM
> > > > 
> > > > 
> > > > 
> > > > --
> > > > This message was sent by Atlassian JIRA
> > > > (v7.6.3#76005)
> > > 
> > > -
> > > 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: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

[Robert Scholte]

On Tue, 15 Jan 2019 17:04:27 +0100, Hervé BOUTEMY   
wrote:


Currently, packaging plugins do nothing in general, since it's Maven  
core that

does the job:


It was a long time ago that we started this. So I guess that we started  
moving the configuration to the packaging-plugins, in order to make it  
possible to remove it from core somewhere in the future.


I just verified that the effect is already visible now.
If you put the packaging-plugin under plugins (not pluginManagement) and  
set extensions to true, you'll see that the embedded configured plugins  
are used.


This is in line with how custom packaging types work (which was one of my  
goals: no difference between known and custom packaging types), but would  
be nice if this could be made easier.


thanks,
Robert

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

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

[Stephen Connolly]

false in the executions?

On Tue, 15 Jan 2019 at 16:04, Hervé BOUTEMY  wrote:

> initial content published, as a branch in maven-studies [1]
>
> I have a few issues that currently will block any release:
> 1. how to configure release plugin without leaking into future projects
> that
> will inherit?
> 2. how to configure invoker also to be able to create ITs to check that it
> works as expected?
>
> On documenting, I started the index.apt.
> Currently, packaging plugins do nothing in general, since it's Maven core
> that
> does the job: I'm curious to see how archetype-packaging is injected when
> configured as extension [2]. But I'm sure that we could override Maven
> core's
> default bindings: the only requirement will be to make the effort to
> create
> dedicated packaging artifacts, to avoid putting the whole plugin's
> dependencies in core classloader
>
> feedback welcome
>
> Regards,
>
> Hervé
>
> [1] https://github.com/apache/maven-studies/tree/maven-default-plugins
>
> [2] https://maven.apache.org/archetype/archetype-packaging/
>
> Le lundi 14 janvier 2019, 23:21:05 CET Robert Scholte a écrit :
> > Introducing a new parent might help for some, but not for everybody.
> > If you already have a parent specified, you can't use this.
> > And Maven doesn't support mixins (yet).
> >
> > We need to document how plugins are controlled.
> > These are probably all variants I can think of
> > - pom.xml
> > - via packaging-plugin
> > - parent (custom or new maven-defaults-plugins)
> > - super pom
> > - maven core
> >
> > thanks,
> > Robert
> >
> > On Mon, 14 Jan 2019 12:01:00 +0100, Hervé Boutemy (JIRA) <
> j...@apache.org>
> >
> > wrote:
> > > Hervé Boutemy created MPOM-215:
> > > --
> > >
> > >  Summary: Create a new parent POM to lock down plugins
> > >
> > > versions of default lifecycle bindings
> > >
> > >  Key: MPOM-215
> > >  URL: https://issues.apache.org/jira/browse/MPOM-215
> > >
> > >  Project: Maven POMs
> > >
> > >   Issue Type: New Feature
> > >
> > > Reporter: Hervé Boutemy
> > >
> > > while working on version upgrade of default plugin bindings, we found
> > > that:
> > > 1. a warning should be displayed MNG-6562
> > > 2. a parent POM would be the easiest solution to lock down every
> plugins
> > > at once, instead of letting users lock down each plugin separately
> > >
> > > let's create this parent POM
> > >
> > >
> > >
> > > --
> > > This message was sent by Atlassian JIRA
> > > (v7.6.3#76005)
> >
> > -
> > 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: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

[Hervé BOUTEMY]

initial content published, as a branch in maven-studies [1]

I have a few issues that currently will block any release:
1. how to configure release plugin without leaking into future projects that 
will inherit?
2. how to configure invoker also to be able to create ITs to check that it 
works as expected?

On documenting, I started the index.apt.
Currently, packaging plugins do nothing in general, since it's Maven core that 
does the job: I'm curious to see how archetype-packaging is injected when 
configured as extension [2]. But I'm sure that we could override Maven core's 
default bindings: the only requirement will be to make the effort to create 
dedicated packaging artifacts, to avoid putting the whole plugin's 
dependencies in core classloader

feedback welcome

Regards,

Hervé

[1] https://github.com/apache/maven-studies/tree/maven-default-plugins

[2] https://maven.apache.org/archetype/archetype-packaging/

Le lundi 14 janvier 2019, 23:21:05 CET Robert Scholte a écrit :
> Introducing a new parent might help for some, but not for everybody.
> If you already have a parent specified, you can't use this.
> And Maven doesn't support mixins (yet).
> 
> We need to document how plugins are controlled.
> These are probably all variants I can think of
> - pom.xml
> - via packaging-plugin
> - parent (custom or new maven-defaults-plugins)
> - super pom
> - maven core
> 
> thanks,
> Robert
> 
> On Mon, 14 Jan 2019 12:01:00 +0100, Hervé Boutemy (JIRA) 
> 
> wrote:
> > Hervé Boutemy created MPOM-215:
> > --
> > 
> >  Summary: Create a new parent POM to lock down plugins
> > 
> > versions of default lifecycle bindings
> > 
> >  Key: MPOM-215
> >  URL: https://issues.apache.org/jira/browse/MPOM-215
> >  
> >  Project: Maven POMs
> >   
> >   Issue Type: New Feature
> >   
> > Reporter: Hervé Boutemy
> > 
> > while working on version upgrade of default plugin bindings, we found
> > that:
> > 1. a warning should be displayed MNG-6562
> > 2. a parent POM would be the easiest solution to lock down every plugins
> > at once, instead of letting users lock down each plugin separately
> > 
> > let's create this parent POM
> > 
> > 
> > 
> > --
> > This message was sent by Atlassian JIRA
> > (v7.6.3#76005)
> 
> -
> 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: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

[Robert Scholte]

Introducing a new parent might help for some, but not for everybody.
If you already have a parent specified, you can't use this.
And Maven doesn't support mixins (yet).

We need to document how plugins are controlled.
These are probably all variants I can think of
- pom.xml
- via packaging-plugin
- parent (custom or new maven-defaults-plugins)
- super pom
- maven core

thanks,
Robert

On Mon, 14 Jan 2019 12:01:00 +0100, Hervé Boutemy (JIRA)   
wrote:



Hervé Boutemy created MPOM-215:
--

 Summary: Create a new parent POM to lock down plugins  
versions of default lifecycle bindings

 Key: MPOM-215
 URL: https://issues.apache.org/jira/browse/MPOM-215
 Project: Maven POMs
  Issue Type: New Feature
Reporter: Hervé Boutemy


while working on version upgrade of default plugin bindings, we found  
that:

1. a warning should be displayed MNG-6562
2. a parent POM would be the easiest solution to lock down every plugins  
at once, instead of letting users lock down each plugin separately


let's create this parent POM



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


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

Re: Create JIRA project for Maven Scripting Plugin

[Enrico Olivelli]

Ping

Il dom 6 gen 2019, 13:27 Robert Scholte  ha scritto:

> Brian,
>
> can you pick this up?
>
> thanks,
> Robert
>
> On Sat, 05 Jan 2019 12:11:41 +0100, Enrico Olivelli 
>
> wrote:
>
> > Can any admin create this project ?
> > for Maven Scripting Plugin
> > https://issues.apache.org/jira/browse/MSCRIPTING
> >
> > Regards
> >
> > Enrico
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
-- 


-- Enrico Olivelli

Re: Create JIRA project for Maven Scripting Plugin

[Robert Scholte]

Brian,

can you pick this up?

thanks,
Robert

On Sat, 05 Jan 2019 12:11:41 +0100, Enrico Olivelli   
wrote:



Can any admin create this project ?
for Maven Scripting Plugin
https://issues.apache.org/jira/browse/MSCRIPTING

Regards

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

Create JIRA project for Maven Scripting Plugin

[Enrico Olivelli]

Can any admin create this project ?
for Maven Scripting Plugin
https://issues.apache.org/jira/browse/MSCRIPTING

Regards

Enrico

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

Re: https://issues.apache.org/jira/browse/MNG-6311

[Sylwester Lachiewicz]

First merge, and first failed build ;-)

Jenkins - Run ITs Linux Java 8 :
remote file operation failed:
/home/jenkins/jenkins-slave/workspace/maven-box_maven_master-DVEN5KAF4FLE3WDK7SWFNYUY4YZ7X45JVWYY6FZT5ZEB3CLWABVQ/test
at hudson.remoting.Channel@f03fce5:H27: java.nio.file.FileSystemException:
/home/jenkins/jenkins-slave/workspace/maven-box_maven_master-DVEN5KAF4FLE3WDK7SWFNYUY4YZ7X45JVWYY6FZT5ZEB3CLWABVQ/test:
No space left on device

Another thing about build - I see errors like: [windows-jdk8]
java.lang.IllegalArgumentException: Cannot relativize
'C:\mvn-it-0.tmp\core-it-support\core-it-plugins\maven-it-plugin-plexus-utils-new\target\maven-it-plugin-plexus-utils-new-2.1-SNAPSHOT.jar'
relatively to '/mvn-it-0.tmp'

If all Jenkins Windows workspaces are on disk C, I think that change [1]
can solve the problem. Can anyone check?

Best regards,
Sylwester

[1]
https://github.com/apache/maven/commit/0e7a8531ddc77a4b85ada49a74092c68b1a46f8f


pt., 14 wrz 2018 o 07:40 użytkownik Karl Heinz Marbaise 
napisał:

> Hi Sylwester,
>
> as you wrote the IT's are fine and now you can merge that branch back to
> master. Just to be sure check the master if something has came into
> master ...and make a rebase against master...(I expect that you don't
> get something).
>
> If you get something new to the rebase and make a push with a
> --force-with-lease to your branch and let the CI check this new
> state..afterwards redo the loop from the beginning...
>
> And finally you should get a simple fast forward while merging into
> master...
>
> And afterwards you can close the ticket as done (delete the remote
> branch and your local one). Best would be to add the reference to the
> git commit within the ticket.
>
> Kind regards
> Karl Heinz Marbaise
>

https://issues.apache.org/jira/browse/MNG-6311

[Karl Heinz Marbaise]

Hi Sylwester,

as you wrote the IT's are fine and now you can merge that branch back to 
master. Just to be sure check the master if something has came into 
master ...and make a rebase against master...(I expect that you don't 
get something).


If you get something new to the rebase and make a push with a 
--force-with-lease to your branch and let the CI check this new 
state..afterwards redo the loop from the beginning...


And finally you should get a simple fast forward while merging into 
master...


And afterwards you can close the ticket as done (delete the remote 
branch and your local one). Best would be to add the reference to the 
git commit within the ticket.


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: Spring cleanup JIRA

[Michael Osipov]

Am 2018-03-07 um 23:31 schrieb Michael Osipov:

Folks,

I did yet another analysis on open issues. We have currently more than 
400 open issues which haven't been touched for more than three (3) years.


The last two times I autoclosed them with a message. People could 
request a reopen, very little did.


Should we do this again? The list won't get shorter and a lot of them do 
not even contain a sample project.


JIRA query: 
https://issues.apache.org/jira/issues/?jql=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC 



Please comment!


Note: if you see an issue which worth keeping, just add a comment to the 
issue: "still valid"


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

Re: Spring cleanup JIRA

[Robert Scholte]

100 for the whole Maven project? Luckily we have ~85 projects, so the  
damage looks manageable.
However, with a total of 2000+ open issues and with the current active  
resources it is impossible to fix them all.
So yes, close them as Auto-Close with a clear message. I sometimes look at  
auto-closed issues, sometimes  they are indeed interesting to add even  
though the reporter didn't ask to reopen such issue.


thanks,
Robert

[1]  
https://cwiki.apache.org/confluence/display/MAVEN/Maven+JIRA+issues+overview



On Thu, 08 Mar 2018 11:16:57 +0100, Martijn Verburg  
<martijnverb...@gmail.com> wrote:


Non binding but agreed - once an issue list gets beyond 50 it's hard to  
see

the forest, once it's beyond 100 you can pretty much guarantee that
everyone is lost.

Cheers,
Martijn

On 8 March 2018 at 07:45, Anders Hammar <and...@hammar.net> wrote:


+1 for the same process as last time.

/Anders

On Wed, Mar 7, 2018 at 11:31 PM, Michael Osipov <micha...@apache.org>
wrote:

> Folks,
>
> I did yet another analysis on open issues. We have currently more than
400
> open issues which haven't been touched for more than three (3) years.
>
> The last two times I autoclosed them with a message. People could  
request

> a reopen, very little did.
>
> Should we do this again? The list won't get shorter and a lot of them  
do

> not even contain a sample project.
>
> JIRA query: https://issues.apache.org/jira/issues/?jql=category%20%3D%
> 20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%
> 20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
>
> Please comment!
>
> Michael
>
> -
> 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: Spring cleanup JIRA

[Martijn Verburg]

Non binding but agreed - once an issue list gets beyond 50 it's hard to see
the forest, once it's beyond 100 you can pretty much guarantee that
everyone is lost.

Cheers,
Martijn

On 8 March 2018 at 07:45, Anders Hammar <and...@hammar.net> wrote:

> +1 for the same process as last time.
>
> /Anders
>
> On Wed, Mar 7, 2018 at 11:31 PM, Michael Osipov <micha...@apache.org>
> wrote:
>
> > Folks,
> >
> > I did yet another analysis on open issues. We have currently more than
> 400
> > open issues which haven't been touched for more than three (3) years.
> >
> > The last two times I autoclosed them with a message. People could request
> > a reopen, very little did.
> >
> > Should we do this again? The list won't get shorter and a lot of them do
> > not even contain a sample project.
> >
> > JIRA query: https://issues.apache.org/jira/issues/?jql=category%20%3D%
> > 20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%
> > 20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
> >
> > Please comment!
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Spring cleanup JIRA

[Anders Hammar]

+1 for the same process as last time.

/Anders

On Wed, Mar 7, 2018 at 11:31 PM, Michael Osipov <micha...@apache.org> wrote:

> Folks,
>
> I did yet another analysis on open issues. We have currently more than 400
> open issues which haven't been touched for more than three (3) years.
>
> The last two times I autoclosed them with a message. People could request
> a reopen, very little did.
>
> Should we do this again? The list won't get shorter and a lot of them do
> not even contain a sample project.
>
> JIRA query: https://issues.apache.org/jira/issues/?jql=category%20%3D%
> 20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%
> 20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
>
> Please comment!
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Spring cleanup JIRA

[Michael Osipov]

Folks,

I did yet another analysis on open issues. We have currently more than 
400 open issues which haven't been touched for more than three (3) years.


The last two times I autoclosed them with a message. People could 
request a reopen, very little did.


Should we do this again? The list won't get shorter and a lot of them do 
not even contain a sample project.


JIRA query: 
https://issues.apache.org/jira/issues/?jql=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC


Please comment!

Michael

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

Re: jira contributor status?

[Sean Busbey]

Hi Robert!

Would you mind if we continue the review on MJAVADOC-444?

Per the guidance on that page you mentioned, I'd like to avoid sending multiple 
messages here and I have questions about the need and form for tests in this 
specific case. If you don't mind, I'd quote your response from here on the jira 
and then provide follow up.

One small matter of clarification, I was talking specifically about the JIRA 
project role of contributor (or its equivalent if the Maven project uses some 
bespoke set of jira project configurations). I'm not looking to apply the 
patch, merely place the jira into the common status used to indicate "there's a 
patch here that should be looked at"; often times such status also triggers 
automated testing that's needed prior to formal review. Apologies if the Maven 
project does not use such status or tooling.


On 2018/03/02 15:32:20, "Robert Scholte" <rfscho...@apache.org> wrote: 
> hi Sean,
> 
> thank you for the patch, which already makes you a contributor.
> To be able to apply patches you need to be a Maven committer.
> If you want to become a committer, please read the Guide Commmitter  
> School[1]
> In case of your patch for MJAVADOC-444, you have to focus on #2 and  
> further.
> 
> thanks,
> Robert
> 
> [1] https://maven.apache.org/guides/development/guide-committer-school
> 
> On Fri, 02 Mar 2018 15:36:15 +0100, Sean Busbey <bus...@apache.org> wrote:
> 
> > Hi!
> >
> > Could someone give me contributor status in jira so I can assign  
> > MJAVADOC-444 to myself and put it in patch available status?
> >
> > -
> > 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: jira contributor status?

[Robert Scholte]

hi Sean,

thank you for the patch, which already makes you a contributor.
To be able to apply patches you need to be a Maven committer.
If you want to become a committer, please read the Guide Commmitter  
School[1]
In case of your patch for MJAVADOC-444, you have to focus on #2 and  
further.


thanks,
Robert

[1] https://maven.apache.org/guides/development/guide-committer-school

On Fri, 02 Mar 2018 15:36:15 +0100, Sean Busbey <bus...@apache.org> wrote:


Hi!

Could someone give me contributor status in jira so I can assign  
MJAVADOC-444 to myself and put it in patch available status?


-
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

jira contributor status?

[Sean Busbey]

Hi!

Could someone give me contributor status in jira so I can assign MJAVADOC-444 
to myself and put it in patch available status?

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

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Russell Gold]

Is there a way to disable this hack? 

I am trying to build the glassfish-corba project 
<https://github.com/javaee/glassfish-corba>, which defines its own version of 
classes in the javax.rmi.CORBA package, and having --add-modules java.se.ee on 
the command line means that those classes aren’t found during unit tests.

- Russ

> On Sep 29, 2017, at 4:55 AM, Enrico Olivelli <eolive...@gmail.com> wrote:
> 
> 2017-09-29 10:41 GMT+02:00 Alan Bateman <alan.bate...@oracle.com>:
> 
>> On 29/09/2017 08:57, Enrico Olivelli wrote:
>> 
>>> :
>>> 
>>> 2) dealing with modules like java.sql which as not in java.base (
>>> http://download.java.net/java/jdk9/docs/api/java.base-summary.html)
>>> Currently I have no solution as there is no official maven dependency for
>>> java.sql package
>>> 
>>> You shouldn't need to be concerned with the java.sql module.
> 
> 
> From the point of view of a developer which uses Maven there is no Maven
> style way to use java.sql module, like "adding a dependency"
> The hack on surefire tried to solve this problem.
> 
> Using JDK_JAVA_OPTIONS is an option, but as it is a env entry it must be
> set externally to the maven pom.xml or config
> Using .mvn/jvm.config will prevent the build to work on java8 (except from
> using -XX:+IgnoreUnrecognizedVMOptions which will be dropped in java11 ??)
> 
> Which is the best suggestion to give to maven users ?
> 
> -- Enrico
> 
> 
> 
>> The only modules that you need to be concerned about are:
>> 
>> java.corba
>> java.transaction
>> java.activation
>> java.xml.bind
>> java.xml.ws
>> java.xml.ws.annotation
>> 
>> and the java.se.ee aggregator.
>> 
>> These modules are deprecated in Java SE and are proposed to be removed in
>> a future release.
>> 
>> Aside from java.corba, the 5 modules shared with Java EE are standalone
>> technologies, each with one or more JSRs and its own download. Each of
>> these projects used to be on java.net but moved to the Java EE github
>> project recently. I don't know if the move to Eclipse will change anything
>> there.
>> 
>> In any case, each of the standalone versions can be deployed on the class
>> path with JDK 9.
>> 
>> In time they will be deployable as modules too and this will allow them to
>> be deployed on the upgrade module path (--upgrade-module-path) to
>> upgrade/override the module in the run-time image with the standalone or
>> Java EE module. This will actually work with all except for the transaction
>> API as there are a couple of issues to sort out there before it can be
>> deployed as a module.
>> 
>> As I understand it, the Spring folks in the JIRA issue are deploying the
>> JTA JAR file on the class path. That should just work but is complicated by
>> `--add-module=java.se.ee` as that will cause the java.transaction module
>> to be resolved. You can't split the javax.transaction package between a
>> module and the class path.
>> 
>> For the surefire plugin then dropping the --add-modules should be looked
>> at. You'll need to do that anyway once java.se.ee goes away. If the
>> plugin relies on JAXB then adding a dependency on the standalone version
>> should work.
>> 
>> -Alan
>> 
>> 
>> 
>> 
>> 

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Enrico Olivelli]

2017-09-29 10:41 GMT+02:00 Alan Bateman <alan.bate...@oracle.com>:

> On 29/09/2017 08:57, Enrico Olivelli wrote:
>
>> :
>>
>> 2) dealing with modules like java.sql which as not in java.base (
>> http://download.java.net/java/jdk9/docs/api/java.base-summary.html)
>> Currently I have no solution as there is no official maven dependency for
>> java.sql package
>>
>> You shouldn't need to be concerned with the java.sql module.


>From the point of view of a developer which uses Maven there is no Maven
style way to use java.sql module, like "adding a dependency"
The hack on surefire tried to solve this problem.

Using JDK_JAVA_OPTIONS is an option, but as it is a env entry it must be
set externally to the maven pom.xml or config
Using .mvn/jvm.config will prevent the build to work on java8 (except from
using -XX:+IgnoreUnrecognizedVMOptions which will be dropped in java11 ??)

Which is the best suggestion to give to maven users ?

-- Enrico



> The only modules that you need to be concerned about are:
>
> java.corba
> java.transaction
> java.activation
> java.xml.bind
> java.xml.ws
> java.xml.ws.annotation
>
> and the java.se.ee aggregator.
>
> These modules are deprecated in Java SE and are proposed to be removed in
> a future release.
>
> Aside from java.corba, the 5 modules shared with Java EE are standalone
> technologies, each with one or more JSRs and its own download. Each of
> these projects used to be on java.net but moved to the Java EE github
> project recently. I don't know if the move to Eclipse will change anything
> there.
>
> In any case, each of the standalone versions can be deployed on the class
> path with JDK 9.
>
> In time they will be deployable as modules too and this will allow them to
> be deployed on the upgrade module path (--upgrade-module-path) to
> upgrade/override the module in the run-time image with the standalone or
> Java EE module. This will actually work with all except for the transaction
> API as there are a couple of issues to sort out there before it can be
> deployed as a module.
>
> As I understand it, the Spring folks in the JIRA issue are deploying the
> JTA JAR file on the class path. That should just work but is complicated by
> `--add-module=java.se.ee` as that will cause the java.transaction module
> to be resolved. You can't split the javax.transaction package between a
> module and the class path.
>
> For the surefire plugin then dropping the --add-modules should be looked
> at. You'll need to do that anyway once java.se.ee goes away. If the
> plugin relies on JAXB then adding a dependency on the standalone version
> should work.
>
> -Alan
>
>
>
>
>

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Alan Bateman]

On 29/09/2017 08:57, Enrico Olivelli wrote:

:

2) dealing with modules like java.sql which as not in java.base 
(http://download.java.net/java/jdk9/docs/api/java.base-summary.html)
Currently I have no solution as there is no official maven dependency 
for java.sql package


You shouldn't need to be concerned with the java.sql module. The only 
modules that you need to be concerned about are:


java.corba
java.transaction
java.activation
java.xml.bind
java.xml.ws
java.xml.ws.annotation

and the java.se.ee aggregator.

These modules are deprecated in Java SE and are proposed to be removed 
in a future release.


Aside from java.corba, the 5 modules shared with Java EE are standalone 
technologies, each with one or more JSRs and its own download. Each of 
these projects used to be on java.net but moved to the Java EE github 
project recently. I don't know if the move to Eclipse will change 
anything there.


In any case, each of the standalone versions can be deployed on the 
class path with JDK 9.


In time they will be deployable as modules too and this will allow them 
to be deployed on the upgrade module path (--upgrade-module-path) to 
upgrade/override the module in the run-time image with the standalone or 
Java EE module. This will actually work with all except for the 
transaction API as there are a couple of issues to sort out there before 
it can be deployed as a module.


As I understand it, the Spring folks in the JIRA issue are deploying the 
JTA JAR file on the class path. That should just work but is complicated 
by `--add-module=java.se.ee` as that will cause the java.transaction 
module to be resolved. You can't split the javax.transaction package 
between a module and the class path.


For the surefire plugin then dropping the --add-modules should be looked 
at. You'll need to do that anyway once java.se.ee goes away. If the 
plugin relies on JAXB then adding a dependency on the standalone version 
should work.


-Alan





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

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Enrico Olivelli]

Robert, Tibor,
I agree with Robert that the tweak about adding --add-modules java.se.ee
has really limited effect as I pointed out in another private email thread,
actually the hack does not work with more than one forked JVM.

My proposal is to drop that fix and document how to deal with changes in
java9, most of the tricks are:
- using JDK_JAVA_OPTIONS=--add-modules=java.se.ee
- using .mvn/jvm.config
- using profiles activated on java version >= 9
- adding explicit dependencies for APIs dropped by default (non included in
java.base)

I have some issues which I cannot resolve:
1) licensing about those new dependencies
if you load javax.xml. from the JDK you do not have to redistribute it,
but if you bundle those jars within your app maybe you will not be happy
about the CCDL license

2) dealing with modules like java.sql which as not in java.base (
http://download.java.net/java/jdk9/docs/api/java.base-summary.html)
Currently I have no solution as there is no official maven dependency for
java.sql package

Enrico


2017-09-29 9:35 GMT+02:00 Robert Scholte <rfscho...@apache.org>:

> Hi Tibor,
>
> moving this to the dev-list, I don't think JIRA is the right place for
> this kind of discussions.
>
> bq. This is not a regression and not a bug in Surefire.
>
> Sorry, I don't agree with you. The Java8 project provided by Stéphane
> works with 2.20.0, but not with 2.20.1, so for me this is clearly a
> regression in surefire.
>
> We are all aware that the modularization in Java 9 can break things, and
> yes sometimes that can be quite frustrating. I think it is the task of
> Maven to solve these kind of issues where possible. Maven should solve the
> hard parts for using Java to let users experience a great way to develop
> with Java.
>
> I don't mind picking this issue up and try to get rid of the
> "--add-modules java.se.ee" (this issue just confirms to me it is indeed a
> hack). Alan pointed me to some dependencies we should add, which should
> solve this issue.
>
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Robert Scholte]

Hi Tibor,

moving this to the dev-list, I don't think JIRA is the right place for  
this kind of discussions.


bq. This is not a regression and not a bug in Surefire.

Sorry, I don't agree with you. The Java8 project provided by Stéphane  
works with 2.20.0, but not with 2.20.1, so for me this is clearly a  
regression in surefire.


We are all aware that the modularization in Java 9 can break things, and  
yes sometimes that can be quite frustrating. I think it is the task of  
Maven to solve these kind of issues where possible. Maven should solve the  
hard parts for using Java to let users experience a great way to develop  
with Java.


I don't mind picking this issue up and try to get rid of the  
"--add-modules java.se.ee" (this issue just confirms to me it is indeed a  
hack). Alan pointed me to some dependencies we should add, which should  
solve this issue.


Robert

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

Re: Users can assign Fix Version/s in Jira

[Karl Heinz Marbaise]

Hi,

based on my earlier request in INFRA ticket[1] a new schema is already 
there cause there were things not the best for example having an entry 
"Question" which often lead people to use JIRA as a user forum..which is 
now no possible anymore...


From my point of view this schema only needs to be enhanced for the 
requested part assigning a version to a ticket...


Kind regards
Karl Heinz Marbaise

[1]: https://issues.apache.org/jira/browse/INFRA-14898

On 08/09/17 18:20, Robert Scholte wrote:
AFAIK the scheme still has to be created and verified, this is just 
another part of that.
I don't think it's worth voting for every (little) change, especially 
not now there's no final scheme yet.


Robert

On Fri, 08 Sep 2017 17:46:13 +0200, Tibor Digana 
<tibor.dig...@googlemail.com> wrote:


Does it mean that we have to post new Vote on separate Maven Scheme?

On Fri, Sep 8, 2017 at 10:05 AM, Robert Scholte
<rfscho...@apache.org <mailto:rfscho...@apache.org>> wrote:

This is part of the scheme in Jira.
Since there's a proposal to make a separate Maven Scheme, this
request should be added as well.

Robert



On Fri, 08 Sep 2017 08:53:31 +0200, Anders Hammar
<and...@hammar.net <mailto:and...@hammar.net>> wrote:

I agree, it's for us as committers to decide.

/Anders

On Fri, Sep 8, 2017 at 8:51 AM, Michael Osipov
<micha...@apache.org <mailto:micha...@apache.org>> wrote:

Am 2017-09-08 um 00:42 schrieb Tibor Digana:

    I found out that users create an issue in Jira and
*assign version* [1].
    I remember this did not happen in old Jira.
So I decide to report a ticket in INFRA.

Do you have the same experiences?
What's your opinion about it?

    [1]: https://issues.apache.org/jira/browse/INFRA-15047


This is an annoying bug. I constantly remove
user-assigned version when I
see it, because this decision should only be upto us,
not them.

Michael


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

Re: Users can assign Fix Version/s in Jira

[Robert Scholte]

AFAIK the scheme still has to be created and verified, this is just  
another part of that.
I don't think it's worth voting for every (little) change, especially not  
now there's no final scheme yet.


Robert

On Fri, 08 Sep 2017 17:46:13 +0200, Tibor Digana  
<tibor.dig...@googlemail.com> wrote:



Does it mean that we have to post new Vote on separate Maven Scheme?

On Fri, Sep 8, 2017 at 10:05 AM, Robert Scholte <rfscho...@apache.org>  
wrote:

This is part of the scheme in Jira.
Since there's a proposal to make a separate Maven Scheme, this request  
should be added as well.


Robert



On Fri, 08 Sep 2017 08:53:31 +0200, Anders Hammar <and...@hammar.net>  
wrote:



I agree, it's for us as committers to decide.

/Anders

On Fri, Sep 8, 2017 at 8:51 AM, Michael Osipov <micha...@apache.org>  
wrote:



Am 2017-09-08 um 00:42 schrieb Tibor Digana:

I found out that users create an issue in Jira and *assign version*  
[1].

I remember this did not happen in old Jira.
So I decide to report a ticket in INFRA.

Do you have the same experiences?
What's your opinion about it?

[1]: https://issues.apache.org/jira/browse/INFRA-15047



This is an annoying bug. I constantly remove user-assigned version  
when I

see it, because this decision should only be upto us, not them.

Michael

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





--Cheers
Tibor

Re: Users can assign Fix Version/s in Jira

[Tibor Digana]

Does it mean that we have to post new Vote on separate Maven Scheme?

On Fri, Sep 8, 2017 at 10:05 AM, Robert Scholte <rfscho...@apache.org>
wrote:

> This is part of the scheme in Jira.
> Since there's a proposal to make a separate Maven Scheme, this request
> should be added as well.
>
> Robert
>
>
>
> On Fri, 08 Sep 2017 08:53:31 +0200, Anders Hammar <and...@hammar.net>
> wrote:
>
> I agree, it's for us as committers to decide.
>>
>> /Anders
>>
>> On Fri, Sep 8, 2017 at 8:51 AM, Michael Osipov <micha...@apache.org>
>> wrote:
>>
>> Am 2017-09-08 um 00:42 schrieb Tibor Digana:
>>>
>>> I found out that users create an issue in Jira and *assign version* [1].
>>>> I remember this did not happen in old Jira.
>>>> So I decide to report a ticket in INFRA.
>>>>
>>>> Do you have the same experiences?
>>>> What's your opinion about it?
>>>>
>>>> [1]: https://issues.apache.org/jira/browse/INFRA-15047
>>>>
>>>>
>>> This is an annoying bug. I constantly remove user-assigned version when I
>>> see it, because this decision should only be upto us, not them.
>>>
>>> Michael
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>


-- 
Cheers
Tibor

Re: Users can assign Fix Version/s in Jira

[Robert Scholte]

This is part of the scheme in Jira.
Since there's a proposal to make a separate Maven Scheme, this request  
should be added as well.


Robert


On Fri, 08 Sep 2017 08:53:31 +0200, Anders Hammar <and...@hammar.net>  
wrote:



I agree, it's for us as committers to decide.

/Anders

On Fri, Sep 8, 2017 at 8:51 AM, Michael Osipov <micha...@apache.org>  
wrote:



Am 2017-09-08 um 00:42 schrieb Tibor Digana:

I found out that users create an issue in Jira and *assign version*  
[1].

I remember this did not happen in old Jira.
So I decide to report a ticket in INFRA.

Do you have the same experiences?
What's your opinion about it?

[1]: https://issues.apache.org/jira/browse/INFRA-15047



This is an annoying bug. I constantly remove user-assigned version when  
I

see it, because this decision should only be upto us, not them.

Michael

-
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: Users can assign Fix Version/s in Jira

[Anders Hammar]

I agree, it's for us as committers to decide.

/Anders

On Fri, Sep 8, 2017 at 8:51 AM, Michael Osipov <micha...@apache.org> wrote:

> Am 2017-09-08 um 00:42 schrieb Tibor Digana:
>
>> I found out that users create an issue in Jira and *assign version* [1].
>> I remember this did not happen in old Jira.
>> So I decide to report a ticket in INFRA.
>>
>> Do you have the same experiences?
>> What's your opinion about it?
>>
>> [1]: https://issues.apache.org/jira/browse/INFRA-15047
>>
>
> This is an annoying bug. I constantly remove user-assigned version when I
> see it, because this decision should only be upto us, not them.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Users can assign Fix Version/s in Jira

[Michael Osipov]

Am 2017-09-08 um 00:42 schrieb Tibor Digana:

I found out that users create an issue in Jira and *assign version* [1].
I remember this did not happen in old Jira.
So I decide to report a ticket in INFRA.

Do you have the same experiences?
What's your opinion about it?

[1]: https://issues.apache.org/jira/browse/INFRA-15047


This is an annoying bug. I constantly remove user-assigned version when 
I see it, because this decision should only be upto us, not them.


Michael

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

Users can assign Fix Version/s in Jira

[Tibor Digana]

I found out that users create an issue in Jira and *assign version* [1].
I remember this did not happen in old Jira.
So I decide to report a ticket in INFRA.

Do you have the same experiences?
What's your opinion about it?

[1]: https://issues.apache.org/jira/browse/INFRA-15047

-- 
Cheers
Tibor

Re: [jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm

[Igor Fedorenko]

Sorry, didn't mean to request a rollback, was merely trying to highlight
areas likely affected by the change. 

-- 
Regards,
Igor

On Thu, Aug 24, 2017, at 12:33 PM, Robert Scholte wrote:
> Hi Igor,
> 
> moving this to dev-list.
> I've asked an explanation of the Java developers team. They confirm that  
> they've made a more clear separation of boot-, system- and  
> application-classloader. They wondered why we put "null" there in the  
> first place, because in general the boot classloader is not enough.
> I've tested if and this change would be the required fix for MANTRUN-200. 
> I haven't found any failing tests yet.
> If this causes issues for other frameworks we need to have a look what  
> should be changed combined with the impact. Were they relying on a bug in 
> Maven. Based on the analysis so far this should be the proper fix.
> Can you somehow try to verify first if this is really an issue. I'm not  
> sure if this should be reverted because of _potential_ issues, because in 
> the end every change could result in new issues.
> 
> I'll try to prepare new Maven installation locally and run other Maven  
> subprojects as well.
> 
> thanks,
> Robert
> 
> ps Stephen gave me the +1 for merging.
> 
> 
> On Thu, 24 Aug 2017 14:30:00 +0200, Igor Fedorenko (JIRA)  
> <j...@apache.org> wrote:
> 
> >
> > [  
> > https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139975#comment-16139975
> >   
> > ]
> >
> > Igor Fedorenko commented on MNG-6275:
> > -
> >
> > I don't have time to do proper analysis of this, but this change will  
> > likely cause problems in m2e, plugin testing, jenkins and other embedded  
> > usecases, where contents of system classloader is generally unknown and  
> > can contain classes that either collide or confuse plugins in some other  
> > ways (e.g. random/unrelated components visible to plugins in only some  
> > environments, which will be very hard to troubleshoot).
> >
> > PS: didn't we agree to get all core changes reviewed and +1'ed by at  
> > least one other developer before pushing to master?
> >
> >> ServiceLoaderFactory can't find implementations via ClassRealm
> >> --
> >>
> >> Key: MNG-6275
> >> URL: https://issues.apache.org/jira/browse/MNG-6275
> >> Project: Maven
> >>  Issue Type: Bug
> >>  Components: Class Loading
> >>Reporter: Robert Scholte
> >>Assignee: Robert Scholte
> >>Priority: Critical
> >> Fix For: 3.5.1
> >>
> >>
> >> Spotted this issue via MANTRUN-200. The reason is that in the  
> >> {{DefaultClassRealmManager}} a new realm is created where the parent  
> >> classLoader is {{null}}. This implies that the bootstrap classloader is  
> >> used as parent.
> >> With Java8 nashorn has become an extension and is not part of the  
> >> bootstrap classloader anymore.
> >> It is kind of strange that we want the bootstrap classloader here, it  
> >> makes more sense if the system classloader is used (but with Java 7 and  
> >> older versions of Java this was not an issue, both worked fine).
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.4.14#64029)
> 
> -
> 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: [jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm

[Robert Scholte]

Hi Igor,

moving this to dev-list.
I've asked an explanation of the Java developers team. They confirm that  
they've made a more clear separation of boot-, system- and  
application-classloader. They wondered why we put "null" there in the  
first place, because in general the boot classloader is not enough.
I've tested if and this change would be the required fix for MANTRUN-200.  
I haven't found any failing tests yet.
If this causes issues for other frameworks we need to have a look what  
should be changed combined with the impact. Were they relying on a bug in  
Maven. Based on the analysis so far this should be the proper fix.
Can you somehow try to verify first if this is really an issue. I'm not  
sure if this should be reverted because of _potential_ issues, because in  
the end every change could result in new issues.


I'll try to prepare new Maven installation locally and run other Maven  
subprojects as well.


thanks,
Robert

ps Stephen gave me the +1 for merging.


On Thu, 24 Aug 2017 14:30:00 +0200, Igor Fedorenko (JIRA)  
<j...@apache.org> wrote:




[  
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139975#comment-16139975  
]


Igor Fedorenko commented on MNG-6275:
-

I don't have time to do proper analysis of this, but this change will  
likely cause problems in m2e, plugin testing, jenkins and other embedded  
usecases, where contents of system classloader is generally unknown and  
can contain classes that either collide or confuse plugins in some other  
ways (e.g. random/unrelated components visible to plugins in only some  
environments, which will be very hard to troubleshoot).


PS: didn't we agree to get all core changes reviewed and +1'ed by at  
least one other developer before pushing to master?



ServiceLoaderFactory can't find implementations via ClassRealm
--

Key: MNG-6275
URL: https://issues.apache.org/jira/browse/MNG-6275
Project: Maven
 Issue Type: Bug
 Components: Class Loading
   Reporter: Robert Scholte
   Assignee: Robert Scholte
   Priority: Critical
Fix For: 3.5.1


Spotted this issue via MANTRUN-200. The reason is that in the  
{{DefaultClassRealmManager}} a new realm is created where the parent  
classLoader is {{null}}. This implies that the bootstrap classloader is  
used as parent.
With Java8 nashorn has become an extension and is not part of the  
bootstrap classloader anymore.
It is kind of strange that we want the bootstrap classloader here, it  
makes more sense if the system classloader is used (but with Java 7 and  
older versions of Java this was not an issue, both worked fine).




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


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

Re: Maven JIRA Projects - Issue Type

[Stephen Connolly]

B please,

On Sat 19 Aug 2017 at 06:54, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:

> Hi,
>
> so based on the feedback I will go back to INFRA and let them configure
> a separate Configuration type "Maven Issue Type Scheme" which contains
> the issue type "Dependency Upgrade"...
>
> Kind regards
> Karl Heinz Marbaise
>
> On 18/08/17 20:52, Karl Heinz Marbaise wrote:
> > Hi to all,
> >
> > I have realized that in MASSEMBLY it is possible to define an issue Type
> > "Dependency Upgrade" which is very feasible for our projects...
> >
> > So I have asked INFRA[1] if we could have that for our other JIRA
> > projects as wellSo the now we can decide between three options:
> >
> >
> > A) switch your other schemes to match MASSEMBLY - meaning in addition to
> > getting 'Dependency Upgrade' you also get add additional 30+ others you
> > dont use.
> >
> > B) Create a Maven Issue Type Scheme, adding 'Dependency Upgrade' to the
> > default.
> >
> > C) Nothing.
> >
> >
> > So I would vote for option "B" ...The question is what do you think?
> > Which options would you like to use in JIRA ?
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > More details in the issue.
> >
> > [1]: https://issues.apache.org/jira/browse/INFRA-14898
> >
> > -
> > 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: Maven JIRA Projects - Issue Type

[Karl Heinz Marbaise]

Hi,

so based on the feedback I will go back to INFRA and let them configure 
a separate Configuration type "Maven Issue Type Scheme" which contains 
the issue type "Dependency Upgrade"...


Kind regards
Karl Heinz Marbaise

On 18/08/17 20:52, Karl Heinz Marbaise wrote:

Hi to all,

I have realized that in MASSEMBLY it is possible to define an issue Type 
"Dependency Upgrade" which is very feasible for our projects...


So I have asked INFRA[1] if we could have that for our other JIRA 
projects as wellSo the now we can decide between three options:



A) switch your other schemes to match MASSEMBLY - meaning in addition to 
getting 'Dependency Upgrade' you also get add additional 30+ others you 
dont use.


B) Create a Maven Issue Type Scheme, adding 'Dependency Upgrade' to the 
default.


C) Nothing.


So I would vote for option "B" ...The question is what do you think? 
Which options would you like to use in JIRA ?



Kind regards
Karl Heinz Marbaise

More details in the issue.

[1]: https://issues.apache.org/jira/browse/INFRA-14898

-
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