Re: Migration of remaining plugins to Git

[Paul Hammant]

I met Chris Wanstrath at a meetup in Cincinatti about four years ago, and
bent his ear about how fantastic Github-Pages (and Jekyll) was as a CMS. I
suggested that if they could add themes for "high school", "community
group", etc they could pull in another category of user of the platform,
and that the themes that are available for gh-pages are not that useful as
they are.

[image: Inline image 1]

^ screencap from today: unchanged :(

On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Polite, yes, just non commital ;-)
>
> On Sun 18 Jun 2017 at 23:10, Paul Hammant  wrote:
>
> > They're always very polite for things that I ask for, but I can't claim
> to
> > have suggested anything that got implemented. I've a better hit-rate with
> > JetBrains and their IDEs.
> >
> > - Paul
> >
> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > Liable to get an answer like:
> > >
> > > > We don't comment our roadmap publicly I'm afraid
> > >
> > > (I've gotten that a couple of times for different things... you'd think
> > > given that I'm the maintainer of the GitHub Branch Source plugin for
> > > Jenkins they might - you know - want to help... but alas)
> > >
> > > On 18 June 2017 at 10:12, Paul Hammant  wrote:
> > >
> > > > Good thought. We could ask about a timeline.
> > > >
> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com> wrote:
> > > >
> > > > > They are now adding user grouping... I wonder how long before repo
> > > > grouping
> > > > > too
> > > > >
> > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant 
> wrote:
> > > > >
> > > > > > Choose one to start with, is what I would do.
> > > > > >
> > > > > > git svn clone of a trunk only, then make that master. branch/tag
> > > > history
> > > > > > can be retained in Subversion but also up on MavenCentral as
> > > > > > foo-x.y-sources.jar files.  Unless you optimize that
> git-svn-clone
> > > > > > operation by specifying the first Svn commit for the module in
> > > > question,
> > > > > > it'll need many hours to iterate over all commits to pluck out
> the
> > > ones
> > > > > > pertinent to the trunk of that module.
> > > > > >
> > > > > > GitHub only allows a single effective 'parent directory' for
> repos,
> > > so
> > > > > > instead of the general github.com/apache org (and in lieu of
> > > > > > github.com/apache/maven/ which is what you'd actually
> > > > want),
> > > > > we
> > > > > > could do github.com/apache-maven/.
> > > > > >
> > > > > > I volunteer for some of the work.  Err, maybe I should read those
> > > > > > confluence pages.
> > > > > >
> > > > > > - Paul
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY <
> > > herve.bout...@free.fr
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > yes, git is really ubiquitous now and nowadays could perhaps
> help
> > > > some
> > > > > > > contributions
> > > > > > > here is our tracking of git migration [1]
> > > > > > >
> > > > > > > there are a few entries that we could move if someone takes the
> > > job:
> > > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools,
> > Release
> > > > > > >
> > > > > > > there are issues to fix when migrating 1 svn repo
> > > (trunk/tags/branch)
> > > > > to
> > > > > > > many
> > > > > > > git repos that are documented but not solved yet
> > > > > > > Plugins and shared components are the 2 big repos, with
> > > respectively
> > > > 41
> > > > > > > and 26
> > > > > > > parts if we switch to git that look hard to manage if we don't
> > > have a
> > > > > > plan.
> > > > > > > Perphaps Jenkins pipelines could provide some solutions on the
> > > > Jenkins
> > > > > > > side.
> > > > > > >
> > > > > > > Skins is perhaps not an issue any more now that we deprecated 3
> > old
> > > > > > skins,
> > > > > > > then only 2 skins remain. Pom would be feasible now that I
> > reworked
> > > > > Maven
> > > > > > > parent poms to be only in one global release: just the history
> > > > > migration
> > > > > > > could
> > > > > > > be tricky given this exact rework :)
> > > > > > >
> > > > > > >
> > > > > > > Then we can move forward:
> > > > > > > - just do it for some svn repos
> > > > > > > - a plan, particularly on Jenkins side, has to be found for
> > plugins
> > > > and
> > > > > > > shared
> > > > > > >
> > > > > > > any taker for some of the work?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Hervé
> > > > > > >
> > > > > > >
> > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+
> > > Migration
> > > > > > >
> > > > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > > > > > >
> > > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa
> > > > > collectionofgitrepos
> > > > > > >
> > > > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a 

Re: Migration of remaining plugins to Git

[Stephen Connolly]

Polite, yes, just non commital ;-)

On Sun 18 Jun 2017 at 23:10, Paul Hammant  wrote:

> They're always very polite for things that I ask for, but I can't claim to
> have suggested anything that got implemented. I've a better hit-rate with
> JetBrains and their IDEs.
>
> - Paul
>
> On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Liable to get an answer like:
> >
> > > We don't comment our roadmap publicly I'm afraid
> >
> > (I've gotten that a couple of times for different things... you'd think
> > given that I'm the maintainer of the GitHub Branch Source plugin for
> > Jenkins they might - you know - want to help... but alas)
> >
> > On 18 June 2017 at 10:12, Paul Hammant  wrote:
> >
> > > Good thought. We could ask about a timeline.
> > >
> > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > They are now adding user grouping... I wonder how long before repo
> > > grouping
> > > > too
> > > >
> > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant  wrote:
> > > >
> > > > > Choose one to start with, is what I would do.
> > > > >
> > > > > git svn clone of a trunk only, then make that master. branch/tag
> > > history
> > > > > can be retained in Subversion but also up on MavenCentral as
> > > > > foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> > > > > operation by specifying the first Svn commit for the module in
> > > question,
> > > > > it'll need many hours to iterate over all commits to pluck out the
> > ones
> > > > > pertinent to the trunk of that module.
> > > > >
> > > > > GitHub only allows a single effective 'parent directory' for repos,
> > so
> > > > > instead of the general github.com/apache org (and in lieu of
> > > > > github.com/apache/maven/ which is what you'd actually
> > > want),
> > > > we
> > > > > could do github.com/apache-maven/.
> > > > >
> > > > > I volunteer for some of the work.  Err, maybe I should read those
> > > > > confluence pages.
> > > > >
> > > > > - Paul
> > > > >
> > > > >
> > > > >
> > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY <
> > herve.bout...@free.fr
> > > >
> > > > > wrote:
> > > > >
> > > > > > yes, git is really ubiquitous now and nowadays could perhaps help
> > > some
> > > > > > contributions
> > > > > > here is our tracking of git migration [1]
> > > > > >
> > > > > > there are a few entries that we could move if someone takes the
> > job:
> > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools,
> Release
> > > > > >
> > > > > > there are issues to fix when migrating 1 svn repo
> > (trunk/tags/branch)
> > > > to
> > > > > > many
> > > > > > git repos that are documented but not solved yet
> > > > > > Plugins and shared components are the 2 big repos, with
> > respectively
> > > 41
> > > > > > and 26
> > > > > > parts if we switch to git that look hard to manage if we don't
> > have a
> > > > > plan.
> > > > > > Perphaps Jenkins pipelines could provide some solutions on the
> > > Jenkins
> > > > > > side.
> > > > > >
> > > > > > Skins is perhaps not an issue any more now that we deprecated 3
> old
> > > > > skins,
> > > > > > then only 2 skins remain. Pom would be feasible now that I
> reworked
> > > > Maven
> > > > > > parent poms to be only in one global release: just the history
> > > > migration
> > > > > > could
> > > > > > be tricky given this exact rework :)
> > > > > >
> > > > > >
> > > > > > Then we can move forward:
> > > > > > - just do it for some svn repos
> > > > > > - a plan, particularly on Jenkins side, has to be found for
> plugins
> > > and
> > > > > > shared
> > > > > >
> > > > > > any taker for some of the work?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > >
> > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+
> > Migration
> > > > > >
> > > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > > > > >
> > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa
> > > > collectionofgitrepos
> > > > > >
> > > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > > > > > In order to be able to build a composite 'trunk' for all
> > > components
> > > > > of
> > > > > > > > maven (that are org.apache.*) can we move the remaining
> things
> > > left
> > > > > in
> > > > > > > > Subversion to Git, and mirror them to Github?
> > > > > > > >
> > > > > > > > `git submodule` (etc) would be how we'd recreate a developer
> > > > > experience
> > > > > > > > that felt like a single trunk that would be cloneable in a
> > single
> > > > > > command.
> > > > > > >
> > > > > > > This have been discussed, afaik, for the plugins already. That
> > > would
> > > > > > > result in an explosion of repositories. It wasn't worthwhile.
> > > > > > >
> > > > > > >
> > > > > > > 

Re: Migration of remaining plugins to Git

[Paul Hammant]

They're always very polite for things that I ask for, but I can't claim to
have suggested anything that got implemented. I've a better hit-rate with
JetBrains and their IDEs.

- Paul

On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Liable to get an answer like:
>
> > We don't comment our roadmap publicly I'm afraid
>
> (I've gotten that a couple of times for different things... you'd think
> given that I'm the maintainer of the GitHub Branch Source plugin for
> Jenkins they might - you know - want to help... but alas)
>
> On 18 June 2017 at 10:12, Paul Hammant  wrote:
>
> > Good thought. We could ask about a timeline.
> >
> > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > They are now adding user grouping... I wonder how long before repo
> > grouping
> > > too
> > >
> > > On Sun 18 Jun 2017 at 17:12, Paul Hammant  wrote:
> > >
> > > > Choose one to start with, is what I would do.
> > > >
> > > > git svn clone of a trunk only, then make that master. branch/tag
> > history
> > > > can be retained in Subversion but also up on MavenCentral as
> > > > foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> > > > operation by specifying the first Svn commit for the module in
> > question,
> > > > it'll need many hours to iterate over all commits to pluck out the
> ones
> > > > pertinent to the trunk of that module.
> > > >
> > > > GitHub only allows a single effective 'parent directory' for repos,
> so
> > > > instead of the general github.com/apache org (and in lieu of
> > > > github.com/apache/maven/ which is what you'd actually
> > want),
> > > we
> > > > could do github.com/apache-maven/.
> > > >
> > > > I volunteer for some of the work.  Err, maybe I should read those
> > > > confluence pages.
> > > >
> > > > - Paul
> > > >
> > > >
> > > >
> > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY <
> herve.bout...@free.fr
> > >
> > > > wrote:
> > > >
> > > > > yes, git is really ubiquitous now and nowadays could perhaps help
> > some
> > > > > contributions
> > > > > here is our tracking of git migration [1]
> > > > >
> > > > > there are a few entries that we could move if someone takes the
> job:
> > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
> > > > >
> > > > > there are issues to fix when migrating 1 svn repo
> (trunk/tags/branch)
> > > to
> > > > > many
> > > > > git repos that are documented but not solved yet
> > > > > Plugins and shared components are the 2 big repos, with
> respectively
> > 41
> > > > > and 26
> > > > > parts if we switch to git that look hard to manage if we don't
> have a
> > > > plan.
> > > > > Perphaps Jenkins pipelines could provide some solutions on the
> > Jenkins
> > > > > side.
> > > > >
> > > > > Skins is perhaps not an issue any more now that we deprecated 3 old
> > > > skins,
> > > > > then only 2 skins remain. Pom would be feasible now that I reworked
> > > Maven
> > > > > parent poms to be only in one global release: just the history
> > > migration
> > > > > could
> > > > > be tricky given this exact rework :)
> > > > >
> > > > >
> > > > > Then we can move forward:
> > > > > - just do it for some svn repos
> > > > > - a plan, particularly on Jenkins side, has to be found for plugins
> > and
> > > > > shared
> > > > >
> > > > > any taker for some of the work?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > >
> > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+
> Migration
> > > > >
> > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > > > >
> > > > +Migration#GitMigration-Migratinganaggregatortreeintoa
> > > collectionofgitrepos
> > > > >
> > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > > > > In order to be able to build a composite 'trunk' for all
> > components
> > > > of
> > > > > > > maven (that are org.apache.*) can we move the remaining things
> > left
> > > > in
> > > > > > > Subversion to Git, and mirror them to Github?
> > > > > > >
> > > > > > > `git submodule` (etc) would be how we'd recreate a developer
> > > > experience
> > > > > > > that felt like a single trunk that would be cloneable in a
> single
> > > > > command.
> > > > > >
> > > > > > This have been discussed, afaik, for the plugins already. That
> > would
> > > > > > result in an explosion of repositories. It wasn't worthwhile.
> > > > > >
> > > > > >
> > > > > > 
> > > -
> > > > > > 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 

Re: Migration of remaining plugins to Git

[Stephen Connolly]

Liable to get an answer like:

> We don't comment our roadmap publicly I'm afraid

(I've gotten that a couple of times for different things... you'd think
given that I'm the maintainer of the GitHub Branch Source plugin for
Jenkins they might - you know - want to help... but alas)

On 18 June 2017 at 10:12, Paul Hammant  wrote:

> Good thought. We could ask about a timeline.
>
> On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > They are now adding user grouping... I wonder how long before repo
> grouping
> > too
> >
> > On Sun 18 Jun 2017 at 17:12, Paul Hammant  wrote:
> >
> > > Choose one to start with, is what I would do.
> > >
> > > git svn clone of a trunk only, then make that master. branch/tag
> history
> > > can be retained in Subversion but also up on MavenCentral as
> > > foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> > > operation by specifying the first Svn commit for the module in
> question,
> > > it'll need many hours to iterate over all commits to pluck out the ones
> > > pertinent to the trunk of that module.
> > >
> > > GitHub only allows a single effective 'parent directory' for repos, so
> > > instead of the general github.com/apache org (and in lieu of
> > > github.com/apache/maven/ which is what you'd actually
> want),
> > we
> > > could do github.com/apache-maven/.
> > >
> > > I volunteer for some of the work.  Err, maybe I should read those
> > > confluence pages.
> > >
> > > - Paul
> > >
> > >
> > >
> > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY  >
> > > wrote:
> > >
> > > > yes, git is really ubiquitous now and nowadays could perhaps help
> some
> > > > contributions
> > > > here is our tracking of git migration [1]
> > > >
> > > > there are a few entries that we could move if someone takes the job:
> > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
> > > >
> > > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch)
> > to
> > > > many
> > > > git repos that are documented but not solved yet
> > > > Plugins and shared components are the 2 big repos, with respectively
> 41
> > > > and 26
> > > > parts if we switch to git that look hard to manage if we don't have a
> > > plan.
> > > > Perphaps Jenkins pipelines could provide some solutions on the
> Jenkins
> > > > side.
> > > >
> > > > Skins is perhaps not an issue any more now that we deprecated 3 old
> > > skins,
> > > > then only 2 skins remain. Pom would be feasible now that I reworked
> > Maven
> > > > parent poms to be only in one global release: just the history
> > migration
> > > > could
> > > > be tricky given this exact rework :)
> > > >
> > > >
> > > > Then we can move forward:
> > > > - just do it for some svn repos
> > > > - a plan, particularly on Jenkins side, has to be found for plugins
> and
> > > > shared
> > > >
> > > > any taker for some of the work?
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > >
> > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
> > > >
> > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > > >
> > > +Migration#GitMigration-Migratinganaggregatortreeintoa
> > collectionofgitrepos
> > > >
> > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > > > In order to be able to build a composite 'trunk' for all
> components
> > > of
> > > > > > maven (that are org.apache.*) can we move the remaining things
> left
> > > in
> > > > > > Subversion to Git, and mirror them to Github?
> > > > > >
> > > > > > `git submodule` (etc) would be how we'd recreate a developer
> > > experience
> > > > > > that felt like a single trunk that would be cloneable in a single
> > > > command.
> > > > >
> > > > > This have been discussed, afaik, for the plugins already. That
> would
> > > > > result in an explosion of repositories. It wasn't worthwhile.
> > > > >
> > > > >
> > > > > 
> > -
> > > > > 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: Migration of remaining plugins to Git

[Paul Hammant]

Good thought. We could ask about a timeline.

On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> They are now adding user grouping... I wonder how long before repo grouping
> too
>
> On Sun 18 Jun 2017 at 17:12, Paul Hammant  wrote:
>
> > Choose one to start with, is what I would do.
> >
> > git svn clone of a trunk only, then make that master. branch/tag history
> > can be retained in Subversion but also up on MavenCentral as
> > foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> > operation by specifying the first Svn commit for the module in question,
> > it'll need many hours to iterate over all commits to pluck out the ones
> > pertinent to the trunk of that module.
> >
> > GitHub only allows a single effective 'parent directory' for repos, so
> > instead of the general github.com/apache org (and in lieu of
> > github.com/apache/maven/ which is what you'd actually want),
> we
> > could do github.com/apache-maven/.
> >
> > I volunteer for some of the work.  Err, maybe I should read those
> > confluence pages.
> >
> > - Paul
> >
> >
> >
> > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY 
> > wrote:
> >
> > > yes, git is really ubiquitous now and nowadays could perhaps help some
> > > contributions
> > > here is our tracking of git migration [1]
> > >
> > > there are a few entries that we could move if someone takes the job:
> > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
> > >
> > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch)
> to
> > > many
> > > git repos that are documented but not solved yet
> > > Plugins and shared components are the 2 big repos, with respectively 41
> > > and 26
> > > parts if we switch to git that look hard to manage if we don't have a
> > plan.
> > > Perphaps Jenkins pipelines could provide some solutions on the Jenkins
> > > side.
> > >
> > > Skins is perhaps not an issue any more now that we deprecated 3 old
> > skins,
> > > then only 2 skins remain. Pom would be feasible now that I reworked
> Maven
> > > parent poms to be only in one global release: just the history
> migration
> > > could
> > > be tricky given this exact rework :)
> > >
> > >
> > > Then we can move forward:
> > > - just do it for some svn repos
> > > - a plan, particularly on Jenkins side, has to be found for plugins and
> > > shared
> > >
> > > any taker for some of the work?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
> > >
> > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > >
> > +Migration#GitMigration-Migratinganaggregatortreeintoa
> collectionofgitrepos
> > >
> > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > > In order to be able to build a composite 'trunk' for all components
> > of
> > > > > maven (that are org.apache.*) can we move the remaining things left
> > in
> > > > > Subversion to Git, and mirror them to Github?
> > > > >
> > > > > `git submodule` (etc) would be how we'd recreate a developer
> > experience
> > > > > that felt like a single trunk that would be cloneable in a single
> > > command.
> > > >
> > > > This have been discussed, afaik, for the plugins already. That would
> > > > result in an explosion of repositories. It wasn't worthwhile.
> > > >
> > > >
> > > > 
> -
> > > > 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: Migration of remaining plugins to Git

[Stephen Connolly]

They are now adding user grouping... I wonder how long before repo grouping
too

On Sun 18 Jun 2017 at 17:12, Paul Hammant  wrote:

> Choose one to start with, is what I would do.
>
> git svn clone of a trunk only, then make that master. branch/tag history
> can be retained in Subversion but also up on MavenCentral as
> foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> operation by specifying the first Svn commit for the module in question,
> it'll need many hours to iterate over all commits to pluck out the ones
> pertinent to the trunk of that module.
>
> GitHub only allows a single effective 'parent directory' for repos, so
> instead of the general github.com/apache org (and in lieu of
> github.com/apache/maven/ which is what you'd actually want), we
> could do github.com/apache-maven/.
>
> I volunteer for some of the work.  Err, maybe I should read those
> confluence pages.
>
> - Paul
>
>
>
> On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY 
> wrote:
>
> > yes, git is really ubiquitous now and nowadays could perhaps help some
> > contributions
> > here is our tracking of git migration [1]
> >
> > there are a few entries that we could move if someone takes the job:
> > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
> >
> > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to
> > many
> > git repos that are documented but not solved yet
> > Plugins and shared components are the 2 big repos, with respectively 41
> > and 26
> > parts if we switch to git that look hard to manage if we don't have a
> plan.
> > Perphaps Jenkins pipelines could provide some solutions on the Jenkins
> > side.
> >
> > Skins is perhaps not an issue any more now that we deprecated 3 old
> skins,
> > then only 2 skins remain. Pom would be feasible now that I reworked Maven
> > parent poms to be only in one global release: just the history migration
> > could
> > be tricky given this exact rework :)
> >
> >
> > Then we can move forward:
> > - just do it for some svn repos
> > - a plan, particularly on Jenkins side, has to be found for plugins and
> > shared
> >
> > any taker for some of the work?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
> >
> > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> >
> +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
> >
> > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > In order to be able to build a composite 'trunk' for all components
> of
> > > > maven (that are org.apache.*) can we move the remaining things left
> in
> > > > Subversion to Git, and mirror them to Github?
> > > >
> > > > `git submodule` (etc) would be how we'd recreate a developer
> experience
> > > > that felt like a single trunk that would be cloneable in a single
> > command.
> > >
> > > This have been discussed, afaik, for the plugins already. That would
> > > result in an explosion of repositories. It wasn't worthwhile.
> > >
> > >
> > > -
> > > 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: Migration of remaining plugins to Git

[Enrico Olivelli]

Hi,
I am currently migrating many projects from sv to git, all of them are on
the same svn repo.
I am using tools like svn2git
https://github.com/nirvdrum/svn2git

These tools retain the full history, authors, branches and tags.

I can give more info if needed

Hope that helps
Enrico

Il dom 18 giu 2017, 18:12 Paul Hammant  ha scritto:

> Choose one to start with, is what I would do.
>
> git svn clone of a trunk only, then make that master. branch/tag history
> can be retained in Subversion but also up on MavenCentral as
> foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> operation by specifying the first Svn commit for the module in question,
> it'll need many hours to iterate over all commits to pluck out the ones
> pertinent to the trunk of that module.
>
> GitHub only allows a single effective 'parent directory' for repos, so
> instead of the general github.com/apache org (and in lieu of
> github.com/apache/maven/ which is what you'd actually want), we
> could do github.com/apache-maven/.
>
> I volunteer for some of the work.  Err, maybe I should read those
> confluence pages.
>
> - Paul
>
>
>
> On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY 
> wrote:
>
> > yes, git is really ubiquitous now and nowadays could perhaps help some
> > contributions
> > here is our tracking of git migration [1]
> >
> > there are a few entries that we could move if someone takes the job:
> > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
> >
> > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to
> > many
> > git repos that are documented but not solved yet
> > Plugins and shared components are the 2 big repos, with respectively 41
> > and 26
> > parts if we switch to git that look hard to manage if we don't have a
> plan.
> > Perphaps Jenkins pipelines could provide some solutions on the Jenkins
> > side.
> >
> > Skins is perhaps not an issue any more now that we deprecated 3 old
> skins,
> > then only 2 skins remain. Pom would be feasible now that I reworked Maven
> > parent poms to be only in one global release: just the history migration
> > could
> > be tricky given this exact rework :)
> >
> >
> > Then we can move forward:
> > - just do it for some svn repos
> > - a plan, particularly on Jenkins side, has to be found for plugins and
> > shared
> >
> > any taker for some of the work?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
> >
> > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> >
> +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
> >
> > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > In order to be able to build a composite 'trunk' for all components
> of
> > > > maven (that are org.apache.*) can we move the remaining things left
> in
> > > > Subversion to Git, and mirror them to Github?
> > > >
> > > > `git submodule` (etc) would be how we'd recreate a developer
> experience
> > > > that felt like a single trunk that would be cloneable in a single
> > command.
> > >
> > > This have been discussed, afaik, for the plugins already. That would
> > > result in an explosion of repositories. It wasn't worthwhile.
> > >
> > >
> > > -
> > > 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
> >
> >
>
-- 


-- Enrico Olivelli

Re: Migration of remaining plugins to Git

[Hervé BOUTEMY]

I updated the page to mark in green the repos that are ready to migrate: just 
need the job to be done (with the help of infra, I suppose) with immediate one 
to one migration

We can in parallel work on organizing more complex 1 to many migration plan

Thank you for your help on this tedious work that exhausted previous 
volunteers...

Regards,

Hervé

Le dimanche 18 juin 2017, 12:12:54 CEST Paul Hammant a écrit :
> Choose one to start with, is what I would do.
> 
> git svn clone of a trunk only, then make that master. branch/tag history
> can be retained in Subversion but also up on MavenCentral as
> foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
> operation by specifying the first Svn commit for the module in question,
> it'll need many hours to iterate over all commits to pluck out the ones
> pertinent to the trunk of that module.
> 
> GitHub only allows a single effective 'parent directory' for repos, so
> instead of the general github.com/apache org (and in lieu of
> github.com/apache/maven/ which is what you'd actually want), we
> could do github.com/apache-maven/.
> 
> I volunteer for some of the work.  Err, maybe I should read those
> confluence pages.
> 
> - Paul
> 
> 
> 
> On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY 
> 
> wrote:
> > yes, git is really ubiquitous now and nowadays could perhaps help some
> > contributions
> > here is our tracking of git migration [1]
> > 
> > there are a few entries that we could move if someone takes the job:
> > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
> > 
> > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to
> > many
> > git repos that are documented but not solved yet
> > Plugins and shared components are the 2 big repos, with respectively 41
> > and 26
> > parts if we switch to git that look hard to manage if we don't have a
> > plan.
> > Perphaps Jenkins pipelines could provide some solutions on the Jenkins
> > side.
> > 
> > Skins is perhaps not an issue any more now that we deprecated 3 old skins,
> > then only 2 skins remain. Pom would be feasible now that I reworked Maven
> > parent poms to be only in one global release: just the history migration
> > could
> > be tricky given this exact rework :)
> > 
> > 
> > Then we can move forward:
> > - just do it for some svn repos
> > - a plan, particularly on Jenkins side, has to be found for plugins and
> > shared
> > 
> > any taker for some of the work?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > 
> > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
> > 
> > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
> > 
> > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > > In order to be able to build a composite 'trunk' for all components of
> > > > maven (that are org.apache.*) can we move the remaining things left in
> > > > Subversion to Git, and mirror them to Github?
> > > > 
> > > > `git submodule` (etc) would be how we'd recreate a developer
> > > > experience
> > > > that felt like a single trunk that would be cloneable in a single
> > 
> > command.
> > 
> > > This have been discussed, afaik, for the plugins already. That would
> > > result in an explosion of repositories. It wasn't worthwhile.
> > > 
> > > 
> > > -
> > > 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: Migration of remaining plugins to Git

[Paul Hammant]

Choose one to start with, is what I would do.

git svn clone of a trunk only, then make that master. branch/tag history
can be retained in Subversion but also up on MavenCentral as
foo-x.y-sources.jar files.  Unless you optimize that git-svn-clone
operation by specifying the first Svn commit for the module in question,
it'll need many hours to iterate over all commits to pluck out the ones
pertinent to the trunk of that module.

GitHub only allows a single effective 'parent directory' for repos, so
instead of the general github.com/apache org (and in lieu of
github.com/apache/maven/ which is what you'd actually want), we
could do github.com/apache-maven/.

I volunteer for some of the work.  Err, maybe I should read those
confluence pages.

- Paul



On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY 
wrote:

> yes, git is really ubiquitous now and nowadays could perhaps help some
> contributions
> here is our tracking of git migration [1]
>
> there are a few entries that we could move if someone takes the job:
> Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release
>
> there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to
> many
> git repos that are documented but not solved yet
> Plugins and shared components are the 2 big repos, with respectively 41
> and 26
> parts if we switch to git that look hard to manage if we don't have a plan.
> Perphaps Jenkins pipelines could provide some solutions on the Jenkins
> side.
>
> Skins is perhaps not an issue any more now that we deprecated 3 old skins,
> then only 2 skins remain. Pom would be feasible now that I reworked Maven
> parent poms to be only in one global release: just the history migration
> could
> be tricky given this exact rework :)
>
>
> Then we can move forward:
> - just do it for some svn repos
> - a plan, particularly on Jenkins side, has to be found for plugins and
> shared
>
> any taker for some of the work?
>
> Regards,
>
> Hervé
>
>
> [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
>
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
>
> Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> > Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > > In order to be able to build a composite 'trunk' for all components of
> > > maven (that are org.apache.*) can we move the remaining things left in
> > > Subversion to Git, and mirror them to Github?
> > >
> > > `git submodule` (etc) would be how we'd recreate a developer experience
> > > that felt like a single trunk that would be cloneable in a single
> command.
> >
> > This have been discussed, afaik, for the plugins already. That would
> > result in an explosion of repositories. It wasn't worthwhile.
> >
> >
> > -
> > 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: Migration of remaining plugins to Git

[Hervé BOUTEMY]

yes, git is really ubiquitous now and nowadays could perhaps help some 
contributions
here is our tracking of git migration [1]

there are a few entries that we could move if someone takes the job:
Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release

there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to many 
git repos that are documented but not solved yet
Plugins and shared components are the 2 big repos, with respectively 41 and 26 
parts if we switch to git that look hard to manage if we don't have a plan.
Perphaps Jenkins pipelines could provide some solutions on the Jenkins side.

Skins is perhaps not an issue any more now that we deprecated 3 old skins, 
then only 2 skins remain. Pom would be feasible now that I reworked Maven 
parent poms to be only in one global release: just the history migration could 
be tricky given this exact rework :)


Then we can move forward:
- just do it for some svn repos
- a plan, particularly on Jenkins side, has to be found for plugins and shared

any taker for some of the work?

Regards,

Hervé


[1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration

[2] https://cwiki.apache.org/confluence/display/MAVEN/Git
+Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos

Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> Am 2017-06-18 um 15:45 schrieb Paul Hammant:
> > In order to be able to build a composite 'trunk' for all components of
> > maven (that are org.apache.*) can we move the remaining things left in
> > Subversion to Git, and mirror them to Github?
> > 
> > `git submodule` (etc) would be how we'd recreate a developer experience
> > that felt like a single trunk that would be cloneable in a single command.
> 
> This have been discussed, afaik, for the plugins already. That would
> result in an explosion of repositories. It wasn't worthwhile.
> 
> 
> -
> 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: Migration of remaining plugins to Git

[Michael Osipov]

Am 2017-06-18 um 15:45 schrieb Paul Hammant:

In order to be able to build a composite 'trunk' for all components of
maven (that are org.apache.*) can we move the remaining things left in
Subversion to Git, and mirror them to Github?

`git submodule` (etc) would be how we'd recreate a developer experience
that felt like a single trunk that would be cloneable in a single command.


This have been discussed, afaik, for the plugins already. That would 
result in an explosion of repositories. It wasn't worthwhile.



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

Migration of remaining plugins to Git

[Paul Hammant]

In order to be able to build a composite 'trunk' for all components of
maven (that are org.apache.*) can we move the remaining things left in
Subversion to Git, and mirror them to Github?

`git submodule` (etc) would be how we'd recreate a developer experience
that felt like a single trunk that would be cloneable in a single command.

Thoughts?

Releasing maven-reporting-impl 3.0

[Karl Heinz Marbaise]

Hi,
currently there are 13 issues solved and I would like to start with a 
release of no one objects on Tuesday...



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: JDK9: Jigsaw Problem with maven-site-plugin 3.6

[Enrico Olivelli]

Il dom 18 giu 2017, 09:38 Tibor Digana  ha
scritto:

> @Enrico
> What "--add-modules ALL-SYSTEM" really does ?
> For me it would be maybe a handy hack but for you it would be just a hack
> anyway as it first seems. Strong encapsulation in Java9 can be openly
> passed by.
>

This is not about strong encapsulation per se, but it adds automatically
every known system module to the module path.
By default new java apps will see only the java.se module and not the full
java8 jdk, which can be referenced using the java.se.ee module.
It is a big jump and it makes impossible to simply upgrade your java
installation from java8 to java9 and hope it will work

>From my point of view the big problem is that existing libraries broke
encapsulation of jdk.
Recently there was a decision to allow illegal reraccessflective access by
default to every legacy classpath based application and, this will ease the
transition. This is available from jdk9b172.


As third party library providers all of us should update our code and
remove illegal code.





> For instance in Surefire we extend UrlClassLoader and I need to access
> entire Java API and let our users to load their classes with entire Java
> API as in Java 8. Suppose no module-info is embedded in any jar.
> Before my plan was to call [1]
> findClass​(String moduleName, String name)
> in subclass of UrlClassLoader with javase-ee in moduleName.



> Now I don't know which approach is better.
>

Honestly I do not know either. Maybe surefire should do its magic and make
jdk8 apps work as before but for the otherside in real world they won't
work on java9 without additional command line options


 Enrico


> [1]:
>
> http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#findClass-java.lang.String-java.lang.String-
>
> Offtopic: I see several Java EE vendors voted against Jigsaw release of
> JDK9. I think JCP members should guarantee that application servers [2] are
> compliant with JDK9 in first step and then cut release version JDK 9 of
> Java SE. Otherwise Jigsaw may kill Java.
> [2]: TomEE, JBoss, WebSphere, GlassFish, WildFly, Weblogic
>

I think that this could be a good read about this topic

http://www.tomitribe.com/blog/2017/05/is-jigsaw-dead-not-quite/


> On Sat, Jun 17, 2017 at 9:53 PM, Robert Scholte 
> wrote:
>
> > +1, fully agree with Guillaume
> >
> > There's no real need to make a plugin modular: it won't become a
> > dependency and the dependency management as done by Maven is strong
> enough
> > to have a stable plugin (i.e no need to add requires-statements).
> >
> > In case of experiment if you want to add a module name,
> > "org.apache.maven.plugins.site" would be my choice as well.
> >
> > Robert
> >
> >
> > On Sat, 17 Jun 2017 16:31:14 +0200, Guillaume Boué 
> > wrote:
> >
> > Hi,
> >>
> >> There was a link to Stephen Colebourne's blog about naming modules:
> >> http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html. So what
> >> about "org.apache.maven.plugins.site" for the module name?
> >>
> >> But I don't think it is necessary to make the plugin modular. The error
> >> means that code launched by the Site plugin is trying to access the
> private
> >> "File(String,File)" constructor. Can you turn on stacktraces to see what
> >> part of the code is doing that? We can perhaps fix the deep reflection
> >> usage and only rely on public API.
> >>
> >> I've also noticed MSITE-789 about a similar error but it was in Findbugs
> >> code.
> >>
> >> Guillaume
> >>
> >> Le 17/06/2017 à 15:54, Karl Heinz Marbaise a écrit :
> >>
> >>> Hi,
> >>> currently I'm a bit on testing JDK 9 EA+174..and found the following
> >>> issue:
> >>>
> >>> [INFO]
> >>> [INFO] <<< maven-plugin-plugin:3.4:report < process-classes @
> >>> maven-install-plugin <<<
> >>> [INFO]
> >>> [INFO] 'process-classes' forked phase execution for
> >>> maven-plugin-plugin:report report preparation done
> >>> [INFO] configuring report plugin org.apache.maven.plugins:maven
> >>> -invoker-plugin:2.0.0
> >>> [INFO] 
> >>> 
> >>> [INFO] BUILD FAILURE
> >>> [INFO] 
> >>> 
> >>> [INFO] Total time: 14.810 s
> >>> [INFO] Finished at: 2017-06-17T15:47:38+02:00
> >>> [INFO] Final Memory: 57M/256M
> >>> [INFO] 
> >>> 
> >>> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site
> >>> (default-site) on project maven-install-plugin: Execution default-site
> of
> >>> goal org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable
> >>> to make private java.io.File(java.lang.String,java.io.File) accessible:
> >>> module java.base does not "opens java.io" to unnamed module @44b002c9
> >>> -> [Help 1]
> >>> [ERROR]
> >>> [ERROR] To see the full stack trace of the errors, 

Re: New Branch (report real sys props of forked JVM) SUREFIRE-1360

[Michael Osipov]

Tibor,

I have left a few comments on GitHub. Check the out. I'll run the ITs 
too here.


Michael

Am 2017-06-18 um 02:15 schrieb Tibor Digana:

I have fixed https://issues.apache.org/jira/browse/SUREFIRE-1302 in branch
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=b9034a3bbb32a27a2d7b66e4d516c2dac61fce29
Tested and made debugging. Forked VM is killed immediately.

On Wed, Apr 26, 2017 at 3:38 AM, Tibor Digana 
wrote:


If we do not have time for this, can I proceed with pushing both branches
SUREFIRE-1364 and SUREFIRE-1366?

On Sun, Apr 23, 2017 at 9:50 PM, Tibor Digana " to .

On Sun, Apr 23, 2017 at 10:42 AM, Tibor Digana <
tibor.dig...@googlemail.com> wrote:


Hi Michael,

No problem.
I am glad that somebody helps me like you do.

On Sun, Apr 23, 2017 at 10:36 AM, Michael Osipov 
wrote:


Am 2017-04-22 um 11:31 schrieb Tibor Digana:


Hi,

I would like to push SUREFIRE-1364 and then fix jira issue
SUREFIRE-1360
which should help the users to speed up testing on cloud.
Can we proceed?



I will need a day or two to check the branch. Please wait...

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





--
Cheers
Tibor





--
Cheers
Tibor









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

Re: Closing issues in JIRA

[Hervé BOUTEMY]

I had a look and it seems roles assignments in MASSEMBLY were broken: I just 
changed them to match classical pattern

please check and confirm MASSEMBLY works now as other Maven Jira projects

Regards,

Hervé

Le samedi 17 juin 2017, 14:17:16 CEST Karl Heinz Marbaise a écrit :
> Hi,
> 
> created an INFRA Ticket for that issue.
> 
> https://issues.apache.org/jira/browse/INFRA-14380
> 
> Kind regards
> Karl Heinz Marbaise
> 
> On 17/06/17 13:21, Karl Heinz Marbaise wrote:
> > Hi,
> > 
> > I have checked that I'm unable to do that on Maven Assembly plugin but
> > on others for example maven-jar-plugin I'm allowed to do so...
> > 
> > Kind regards
> > Karl Heinz Marbaise
> > 
> > On 17/06/17 13:18, Karl Heinz Marbaise wrote:
> >> Hi,
> >> 
> >> it looks at the moment that I'm unable to close (closed as duplicate
> >> etc.) an issue ?
> >> 
> >> is this a general problem for others as well or only for me?
> >> 
> >> Any ideas?
> >> 
> >> Kind regards
> >> Karl Heinz Marbaise
> 
> -
> 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: JDK9: Jigsaw Problem with maven-site-plugin 3.6

[Tibor Digana]

@Enrico
What "--add-modules ALL-SYSTEM" really does ?
For me it would be maybe a handy hack but for you it would be just a hack
anyway as it first seems. Strong encapsulation in Java9 can be openly
passed by.

For instance in Surefire we extend UrlClassLoader and I need to access
entire Java API and let our users to load their classes with entire Java
API as in Java 8. Suppose no module-info is embedded in any jar.
Before my plan was to call [1]
findClass​(String moduleName, String name)
in subclass of UrlClassLoader with javase-ee in moduleName.

Now I don't know which approach is better.

[1]:
http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#findClass-java.lang.String-java.lang.String-

Offtopic: I see several Java EE vendors voted against Jigsaw release of
JDK9. I think JCP members should guarantee that application servers [2] are
compliant with JDK9 in first step and then cut release version JDK 9 of
Java SE. Otherwise Jigsaw may kill Java.
[2]: TomEE, JBoss, WebSphere, GlassFish, WildFly, Weblogic

On Sat, Jun 17, 2017 at 9:53 PM, Robert Scholte 
wrote:

> +1, fully agree with Guillaume
>
> There's no real need to make a plugin modular: it won't become a
> dependency and the dependency management as done by Maven is strong enough
> to have a stable plugin (i.e no need to add requires-statements).
>
> In case of experiment if you want to add a module name,
> "org.apache.maven.plugins.site" would be my choice as well.
>
> Robert
>
>
> On Sat, 17 Jun 2017 16:31:14 +0200, Guillaume Boué 
> wrote:
>
> Hi,
>>
>> There was a link to Stephen Colebourne's blog about naming modules:
>> http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html. So what
>> about "org.apache.maven.plugins.site" for the module name?
>>
>> But I don't think it is necessary to make the plugin modular. The error
>> means that code launched by the Site plugin is trying to access the private
>> "File(String,File)" constructor. Can you turn on stacktraces to see what
>> part of the code is doing that? We can perhaps fix the deep reflection
>> usage and only rely on public API.
>>
>> I've also noticed MSITE-789 about a similar error but it was in Findbugs
>> code.
>>
>> Guillaume
>>
>> Le 17/06/2017 à 15:54, Karl Heinz Marbaise a écrit :
>>
>>> Hi,
>>> currently I'm a bit on testing JDK 9 EA+174..and found the following
>>> issue:
>>>
>>> [INFO]
>>> [INFO] <<< maven-plugin-plugin:3.4:report < process-classes @
>>> maven-install-plugin <<<
>>> [INFO]
>>> [INFO] 'process-classes' forked phase execution for
>>> maven-plugin-plugin:report report preparation done
>>> [INFO] configuring report plugin org.apache.maven.plugins:maven
>>> -invoker-plugin:2.0.0
>>> [INFO] 
>>> 
>>> [INFO] BUILD FAILURE
>>> [INFO] 
>>> 
>>> [INFO] Total time: 14.810 s
>>> [INFO] Finished at: 2017-06-17T15:47:38+02:00
>>> [INFO] Final Memory: 57M/256M
>>> [INFO] 
>>> 
>>> [ERROR] Failed to execute goal 
>>> org.apache.maven.plugins:maven-site-plugin:3.6:site
>>> (default-site) on project maven-install-plugin: Execution default-site of
>>> goal org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable
>>> to make private java.io.File(java.lang.String,java.io.File) accessible:
>>> module java.base does not "opens java.io" to unnamed module @44b002c9
>>> -> [Help 1]
>>> [ERROR]
>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>>> -e switch.
>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>> [ERROR]
>>>
>>> So based on what I understood at the moment is that the
>>> maven-site-plugin needs to have a module-info.java file
>>>
>>> The first thing which came into my mind was how-to name the module?
>>>
>>> module org.apache.maven.plugins.maven.site.plugin {
>>>   requires java.io;
>>>   requires java.base;
>>> }
>>>
>>> Do we have any kind of general naming convention for the plugins?
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>
>> ---
>> L'absence de virus dans ce courrier électronique a été vérifiée par le
>> logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>>
>>
>> -
>> 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
>
>


-- 
Cheers
Tibor