Re: Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

It is the last big problem, yes.

Sent from my iPhone

> On Jan 24, 2017, at 10:10 AM, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> Don't mean to derail the discussion, but I am wondering if sparse
> checkout is the last/biggest problem you have to solve to use maven for
> your "one bg ass trunk". 
> 
> We are using maven for a monorepo (maybe not as "bg ass" as google's
> but pretty big nonetheless) for few years now and lack of sparse
> checkout was never a big problem for us. Disk space and even network are
> relatively cheap these days, after all. We did have to implement what we
> call "partial build", where we don't build the whole tree, but a subset
> of modules  selected by the user, with the required dependencies coming
> as prebuilt artifacts from a repository.  This is conceptually what
> --projects and -SNAPSHOTs claim do, only hardened to scale for large
> number of modules and developers.
> 
> -- 
> Regards,
> Igor
> 
>> On Tue, Jan 24, 2017, at 12:05 AM, Paul Hammant wrote:
>> OK, so I'm a documenter of Google's Monorepo (one bg ass trunk) and
>> it's usage of shell scripts to subset the checkout for speedy
>> development:
>> 
>>   http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/
>>   https://trunkbaseddevelopment.com/monorepos/
>> 
>> For Maven to be used with a scripted use of Subversion or Git's
>> sparse-checkout (or Perforce's client spec), it'd been to be more like
>> Bazel/Blaze or Buck, in that sub-modules are *not* forward declared, they
>> are discovered/calculated/inferred somehow.
>> 
>> In pom.xml instead of -
>> 
>>  
>>one
>>two
>>   
>> 
>> We'd need -
>> 
>>  
>>recursively
>>   
>> 
>> Or -
>> 
>>  
>>.full-module-list.txt
>>
>>   
>> 
>> Thoughts?
>> 
>> Any questions?
>> 
>> - Paul H
>> 
>> PS - I'm a solid Maven user since 2003.
> 
> -
> 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

Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

OK, so I'm a documenter of Google's Monorepo (one bg ass trunk) and
it's usage of shell scripts to subset the checkout for speedy development:

   http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/
   https://trunkbaseddevelopment.com/monorepos/

For Maven to be used with a scripted use of Subversion or Git's
sparse-checkout (or Perforce's client spec), it'd been to be more like
Bazel/Blaze or Buck, in that sub-modules are *not* forward declared, they
are discovered/calculated/inferred somehow.

In pom.xml instead of -

  
one
two
   

We'd need -

  
recursively
   

Or -

  
.full-module-list.txt

   

Thoughts?

Any questions?

- Paul H

PS - I'm a solid Maven user since 2003.

Re: Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

i thought about that too, except that in a monorepo situation, I don't want
the don't want the changed pom to get pushed back in a commit, and I don't
want one of the those changelists in my IDE labeled "do not commit" to
facilitate that.

Rationale: Just because I've subset my checkout/clone doesn't mean that all
users of the same repo want to.

It was implied, but I'll call it out:  .full-module-list.txt is in
.gitignore (etc), and that it's easily regenerate per the 'find' command.

Regards,

- Paul

On Tue, Jan 24, 2017 at 12:50 AM, Aldrin Leal <ald...@leal.eng.br> wrote:

> Actually, I always wondered if it was interesting to have a tool to allow
> the modification of POM files from Command Line. Like setting a property,
> adding a dependency and/or, as you exposed, changing modules.
>
> --
> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
>
> On Tue, Jan 24, 2017 at 12:05 AM, Paul Hammant <hamm...@apache.org> wrote:
>
> > OK, so I'm a documenter of Google's Monorepo (one bg ass trunk) and
> > it's usage of shell scripts to subset the checkout for speedy
> development:
> >
> >http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/
> >https://trunkbaseddevelopment.com/monorepos/
> >
> > For Maven to be used with a scripted use of Subversion or Git's
> > sparse-checkout (or Perforce's client spec), it'd been to be more like
> > Bazel/Blaze or Buck, in that sub-modules are *not* forward declared, they
> > are discovered/calculated/inferred somehow.
> >
> > In pom.xml instead of -
> >
> >   
> > one
> > two
> >
> >
> > We'd need -
> >
> >   
> > recursively
> >
> >
> > Or -
> >
> >   
> > .full-module-list.txt
> > 
> >
> >
> > Thoughts?
> >
> > Any questions?
> >
> > - Paul H
> >
> > PS - I'm a solid Maven user since 2003.
> >
>

Re: Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

Versus profiles, I would rather have pom.xml exhaustively renamed to
pom.xml.template in SCM, and a Python script to generate  as we
have it today (pom.xml marked as .gitignore) before invoking 'maven install'

- Paul


On Tue, Jan 24, 2017 at 7:31 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> It's an interesting idea for model version 5.0.0 to consider.
>
> At present, I would handle it by using profiles with activation to pull in
> the modules:
>
> if your activation in the root is based on the presence of the module's
> pom.xml then it will only add the module if you checked it out: (approx
> structure and I do not have the XSD to hand)
>
> 
>   module-foo
>   
> module-foo/pom.xml
>   
>   
> module-foo
>   
> 
> 
>   module-bar
>   
> module-bar/pom.xml
>   
>   
> module-bar
>   
> 
>
> Yes that becomes an ugly pom, but it will do what you want when run from
> the root and I have used it before
>
> HTH
>
> On 24 January 2017 at 11:14, Paul Hammant <p...@hammant.org> wrote:
>
> > i thought about that too, except that in a monorepo situation, I don't
> want
> > the don't want the changed pom to get pushed back in a commit, and I
> don't
> > want one of the those changelists in my IDE labeled "do not commit" to
> > facilitate that.
> >
> > Rationale: Just because I've subset my checkout/clone doesn't mean that
> all
> > users of the same repo want to.
> >
> > It was implied, but I'll call it out:  .full-module-list.txt is in
> > .gitignore (etc), and that it's easily regenerate per the 'find' command.
> >
> > Regards,
> >
> > - Paul
> >
> > On Tue, Jan 24, 2017 at 12:50 AM, Aldrin Leal <ald...@leal.eng.br>
> wrote:
> >
> > > Actually, I always wondered if it was interesting to have a tool to
> allow
> > > the modification of POM files from Command Line. Like setting a
> property,
> > > adding a dependency and/or, as you exposed, changing modules.
> > >
> > > --
> > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
> > >
> > > On Tue, Jan 24, 2017 at 12:05 AM, Paul Hammant <hamm...@apache.org>
> > wrote:
> > >
> > > > OK, so I'm a documenter of Google's Monorepo (one bg ass trunk)
> and
> > > > it's usage of shell scripts to subset the checkout for speedy
> > > development:
> > > >
> > > >http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/
> > > >https://trunkbaseddevelopment.com/monorepos/
> > > >
> > > > For Maven to be used with a scripted use of Subversion or Git's
> > > > sparse-checkout (or Perforce's client spec), it'd been to be more
> like
> > > > Bazel/Blaze or Buck, in that sub-modules are *not* forward declared,
> > they
> > > > are discovered/calculated/inferred somehow.
> > > >
> > > > In pom.xml instead of -
> > > >
> > > >   
> > > > one
> > > > two
> > > >
> > > >
> > > > We'd need -
> > > >
> > > >   
> > > > recursively
> > > >
> > > >
> > > > Or -
> > > >
> > > >   
> > > > .full-module-list.txt
> > > > 
> > > >
> > > >
> > > > Thoughts?
> > > >
> > > > Any questions?
> > > >
> > > > - Paul H
> > > >
> > > > PS - I'm a solid Maven user since 2003.
> > > >
> > >
> >
>

Re: Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

Thanks Jörg - I'll keep that in mind for a fallback.

For a hacky maven3 modification towards Robert's def:.full-module-
list.txt I have found:


https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/MavenProject.java#L1480

It looks like that method can modify module/sub-project lists. And that's
where I'm going to play around.

The method is marked as to-delete for Maven 4+, but that's not going to
stop me I don't think.

- Paul

On Tue, Jan 24, 2017 at 11:26 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi Paul,
>
> Paul Hammant wrote:
>
> > OK, so I'm a documenter of Google's Monorepo (one bg ass trunk) and
> > it's usage of shell scripts to subset the checkout for speedy
> development:
> >
> >http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/
> >https://trunkbaseddevelopment.com/monorepos/
> >
> > For Maven to be used with a scripted use of Subversion or Git's
> > sparse-checkout (or Perforce's client spec), it'd been to be more like
> > Bazel/Blaze or Buck, in that sub-modules are *not* forward declared, they
> > are discovered/calculated/inferred somehow.
> >
> > In pom.xml instead of -
> >
> >   
> > one
> > two
> >
> >
> > We'd need -
> >
> >   
> > recursively
> >
> >
> > Or -
> >
> >   
> > .full-module-list.txt
> > 
> >
> >
> > Thoughts?
> >
> > Any questions?
> >
> > - Paul H
> >
> > PS - I'm a solid Maven user since 2003.
>
> we did something like that just with bash scripts and it boils down to to a
> simple shell function. In the follwing example it creates module entries
> for
> all direct subdirectories containing a pom.xml file, but you might easily
> adjust this to some expression using globs, find or a list in a file.
>
>  %< 
>
> function createBuilder()
> {
> local artifactId
> local path
>
> artifactId=${1##*/}
> cat > "$1"/pom.xml < 
>  xmlns="http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
>
> 4.0.0
> builder
> $artifactId
> pom
> x-SNAPSHOT
> Builder $artifactId
>
> 
> EOF
> while read path; do
> if [ -f "$path" ]; then
> continue
> fi
> path=${path##*/}
> cat >> "$1"/pom.xml < $path
> EOF
> done < <(ls -d "$1"/*)
> cat >> "$1"/pom.xml < 
> 
> EOF
> }
>
>  %< 
>
> Cheers,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

Here it is working with some Python scripting growing/shrinking the checkout.

http://paulhammant.com/2017/01/27/maven-in-a-google-style-monorepo/

A team could use it like that, right now.

On Wed, Jan 25, 2017 at 6:35 AM, Paul Hammant <p...@hammant.org> wrote:
> OK so I've grappled git's sparse checkout and won (for now).  I can use it
> to subset the checkout (not clone) and make Maven3 do a reduced build graph
> without using profiles.
>
> Details:
> https://github.com/paul-hammant/maven-monorepo-experiment/tree/trick-maven-monorepo
> details
>
> Google has 86 TB of history in their trunk, and you could't use Git for that
> for many reasons, but we' are a couple of inches closer for Maven now.
>
> - Paul
>
> On Tue, Jan 24, 2017 at 10:44 PM, Paul Hammant <p...@hammant.org> wrote:
>>
>> OK, take a look at
>> https://github.com/paul-hammant/maven-monorepo-experiment/compare/trick-maven-monorepo
>>
>> Branch 1 - vanilla-recursive is a branch with HazelCast's core and samples
>> checked in - a 14 minute build IF YOU SKIP TESTS AND YOU ALREADY HAD CACHED
>> DEPS !!.
>>
>> Branch 2 - pom.xml files renamed to pom-template.xml and some shell/python
>> fu to recreate pom.xml files (read-only, .gitignore'd) obeying the directory
>> structure, and excluding  lines where the directory is missing.
>>
>> See
>> https://github.com/paul-hammant/maven-monorepo-experiment/blob/trick-maven-monorepo/README.md
>>
>> That's enough for one night - more tomorrow. I get to find out whether
>> Git's sparse-checkout is elegant or a mess. At least for my use case.
>>
>> - Paul
>
>

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

Re: Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

OK so I've grappled git's sparse checkout and won (for now).  I can use it
to subset the checkout (not clone) and make Maven3 do a reduced build graph
without using profiles.

Details:
https://github.com/paul-hammant/maven-monorepo-experiment/tree/trick-maven-monorepo
details

Google has 86 TB of history in their trunk, and you could't use Git for
that for many reasons, but we' are a couple of inches closer for Maven now.

- Paul

On Tue, Jan 24, 2017 at 10:44 PM, Paul Hammant <p...@hammant.org> wrote:

> OK, take a look at https://github.com/paul-hammant/maven-monorepo-
> experiment/compare/trick-maven-monorepo
>
> Branch 1 - vanilla-recursive
> <https://github.com/paul-hammant/maven-monorepo-experiment> is a branch
> with HazelCast's core and samples checked in - a 14 minute build IF YOU
> SKIP TESTS AND YOU ALREADY HAD CACHED DEPS !!.
>
> Branch 2 - pom.xml files renamed to pom-template.xml and some shell/python
> fu to recreate pom.xml files (read-only, .gitignore'd) obeying the
> directory structure, and excluding  lines where the directory is
> missing.
>
> See https://github.com/paul-hammant/maven-monorepo-
> experiment/blob/trick-maven-monorepo/README.md
>
> That's enough for one night - more tomorrow. I get to find out whether
> Git's sparse-checkout is elegant or a mess. At least for my use case.
>
> - Paul
>

Re: Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

OK, take a look at
https://github.com/paul-hammant/maven-monorepo-experiment/compare/trick-maven-monorepo

Branch 1 - vanilla-recursive
<https://github.com/paul-hammant/maven-monorepo-experiment> is a branch
with HazelCast's core and samples checked in - a 14 minute build IF YOU
SKIP TESTS AND YOU ALREADY HAD CACHED DEPS !!.

Branch 2 - pom.xml files renamed to pom-template.xml and some shell/python
fu to recreate pom.xml files (read-only, .gitignore'd) obeying the
directory structure, and excluding  lines where the directory is
missing.

See
https://github.com/paul-hammant/maven-monorepo-experiment/blob/trick-maven-monorepo/README.md

That's enough for one night - more tomorrow. I get to find out whether
Git's sparse-checkout is elegant or a mess. At least for my use case.

- Paul

Re: Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

100% agree that teams not using this feature should be able to carry on 
unchanged. If the likes of JetBrains have to do extra code for the short-hand 
inside  that Robert proposed, then I'm sure they'll agree with me that 
that is the cost of doing business. And from that they can choose to delay it 
too, or wait for a PR from someone who has cloned their GH repo.

Sent from my iPhone

> On Jan 24, 2017, at 8:50 AM, Stephen Connolly 
> <stephen.alan.conno...@gmail.com> wrote:
> 
> I don't disagree... but
> 
> There is tooling that parses the Pom directly and has made assumptions
> about the modules tag and its structure
> 
> We would break such tooling with such a seemingly trivial change (I know of
> at least 5 of my employer's customers who I would be quite upset... any my
> employer is focused on a different product from Maven)
> 
> 
>> On Tue 24 Jan 2017 at 13:33, Paul Hammant <p...@hammant.org> wrote:
>> 
>> Stephen - I think think Robert's def:.full-module-list.txt
>> 
>> is compatible hacking that is POM 4 friendly (and 3 for that matter) until
>> 
>> you revisit in 5.
>> 
>> 
>> 
>> I'd be horrified to write more XML than I already write in Maven.
>> 
>> 
>> 
>> I'm able to face Gradle advocates re a particular enterprise app and
>> 
>> without feeling I'm lying to myself say "what you're showing me is more of
>> 
>> less the same as Maven all things considered". Well if failsafe and tomcat
>> 
>> and surefile and coverage aren't in the same solution, that is.  With the
>> 
>> profile fu, just to get Maven to follow the lead git-sparse-checkout could
>> 
>> give for such things, I could not face anyone and say that's what you
>> 
>> should do.
>> 
>> 
>> 
>> - Paul
>> 
>> 
>> 
>> On Tue, Jan 24, 2017 at 8:13 AM, Stephen Connolly <
>> 
>> stephen.alan.conno...@gmail.com> wrote:
>> 
>> 
>> 
>>> Yep I hear you.
>> 
>>> 
>> 
>>> We cannot change the 4.0.0 schema
>> 
>>> 
>> 
>>> And changing to a new modelVersion requires ensuring that we can evolve
>> 
>>> without breaking consumers of the older model.
>> 
>>> 
>> 
>>> Basically we have one chance to make a "breaking" change to something
>> that
>> 
>>> allows us to evolve going forward
>> 
>>> 
>> 
>>> So what I provided was the 4.0.0 modelVersion solution... it's ugly but
>> 
>>> does not require pre-processing or generation of the pom
>> 
>>> 
>> 
>>>> On Tue 24 Jan 2017 at 12:53, Paul Hammant <p...@hammant.org> wrote:
>>> 
>>> 
>> 
>>>> Versus profiles, I would rather have pom.xml exhaustively renamed to
>> 
>>>> 
>> 
>>>> pom.xml.template in SCM, and a Python script to generate  as
>> we
>> 
>>>> 
>> 
>>>> have it today (pom.xml marked as .gitignore) before invoking 'maven
>> 
>>>> install'
>> 
>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> - Paul
>> 
>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> On Tue, Jan 24, 2017 at 7:31 AM, Stephen Connolly <
>> 
>>>> 
>> 
>>>> stephen.alan.conno...@gmail.com> wrote:
>> 
>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>>> It's an interesting idea for model version 5.0.0 to consider.
>> 
>>>> 
>> 
>>>>> 
>> 
>>>> 
>> 
>>>>> At present, I would handle it by using profiles with activation to
>> pull
>> 
>>>> in
>> 
>>>> 
>> 
>>>>> the modules:
>> 
>>>> 
>> 
>>>>> 
>> 
>>>> 
>> 
>>>>> if your activation in the root is based on the presence of the
>> module's
>> 
>>>> 
>> 
>>>>> pom.xml then it will only add the module if you checked it out:
>> (approx
>> 
>>>> 
>> 
>>>>> structure and I do not have the XSD to hand)
>> 
>>>> 
>> 
>>>>> 
>> 
>>>> 
>> 
>>>>> 
>> 
>>>> 
>> 
>>>>>  module-foo
>> 
>>>> 
>> 
>>>>>  
>>

Re: Requesting a single Monorepo enhancement for Maven

[Paul Hammant]

Stephen - I think think Robert's def:.full-module-list.txt
is compatible hacking that is POM 4 friendly (and 3 for that matter) until
you revisit in 5.

I'd be horrified to write more XML than I already write in Maven.

I'm able to face Gradle advocates re a particular enterprise app and
without feeling I'm lying to myself say "what you're showing me is more of
less the same as Maven all things considered". Well if failsafe and tomcat
and surefile and coverage aren't in the same solution, that is.  With the
profile fu, just to get Maven to follow the lead git-sparse-checkout could
give for such things, I could not face anyone and say that's what you
should do.

- Paul

On Tue, Jan 24, 2017 at 8:13 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Yep I hear you.
>
> We cannot change the 4.0.0 schema
>
> And changing to a new modelVersion requires ensuring that we can evolve
> without breaking consumers of the older model.
>
> Basically we have one chance to make a "breaking" change to something that
> allows us to evolve going forward
>
> So what I provided was the 4.0.0 modelVersion solution... it's ugly but
> does not require pre-processing or generation of the pom
>
> On Tue 24 Jan 2017 at 12:53, Paul Hammant <p...@hammant.org> wrote:
>
> > Versus profiles, I would rather have pom.xml exhaustively renamed to
> >
> > pom.xml.template in SCM, and a Python script to generate  as we
> >
> > have it today (pom.xml marked as .gitignore) before invoking 'maven
> > install'
> >
> >
> >
> > - Paul
> >
> >
> >
> >
> >
> > On Tue, Jan 24, 2017 at 7:31 AM, Stephen Connolly <
> >
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >
> >
> > > It's an interesting idea for model version 5.0.0 to consider.
> >
> > >
> >
> > > At present, I would handle it by using profiles with activation to pull
> > in
> >
> > > the modules:
> >
> > >
> >
> > > if your activation in the root is based on the presence of the module's
> >
> > > pom.xml then it will only add the module if you checked it out: (approx
> >
> > > structure and I do not have the XSD to hand)
> >
> > >
> >
> > > 
> >
> > >   module-foo
> >
> > >   
> >
> > > module-foo/pom.xml
> >
> > >   
> >
> > >   
> >
> > > module-foo
> >
> > >   
> >
> > > 
> >
> > > 
> >
> > >   module-bar
> >
> > >   
> >
> > > module-bar/pom.xml
> >
> > >   
> >
> > >   
> >
> > > module-bar
> >
> > >   
> >
> > > 
> >
> > >
> >
> > > Yes that becomes an ugly pom, but it will do what you want when run
> from
> >
> > > the root and I have used it before
> >
> > >
> >
> > > HTH
> >
> > >
> >
> > > On 24 January 2017 at 11:14, Paul Hammant <p...@hammant.org> wrote:
> >
> > >
> >
> > > > i thought about that too, except that in a monorepo situation, I
> don't
> >
> > > want
> >
> > > > the don't want the changed pom to get pushed back in a commit, and I
> >
> > > don't
> >
> > > > want one of the those changelists in my IDE labeled "do not commit"
> to
> >
> > > > facilitate that.
> >
> > > >
> >
> > > > Rationale: Just because I've subset my checkout/clone doesn't mean
> that
> >
> > > all
> >
> > > > users of the same repo want to.
> >
> > > >
> >
> > > > It was implied, but I'll call it out:  .full-module-list.txt is in
> >
> > > > .gitignore (etc), and that it's easily regenerate per the 'find'
> > command.
> >
> > > >
> >
> > > > Regards,
> >
> > > >
> >
> > > > - Paul
> >
> > > >
> >
> > > > On Tue, Jan 24, 2017 at 12:50 AM, Aldrin Leal <ald...@leal.eng.br>
> >
> > > wrote:
> >
> > > >
> >
> > > > > Actually, I always wondered if it was interesting to have a tool to
> >
> > > allow
> >
> > > > > the modification of POM files from Command Line. Like setting a
> >
> > > property,
> >
> > > > > adding a 

Re: Apache owned index of Maven-Central artifacts?

[Paul Hammant]

OK I'll shut up then. While I might hope for a slim front-end-only
read-only UI for 'central' it's compete with Nexus, which Sonatype sell, so
asking them to host something (that I could write solo) would be beyond
cheeky.

On Mon, Apr 3, 2017 at 2:30 PM, Manfred Moser <manf...@simpligility.com>
wrote:

> Fyi the URL repo.maven.apache.org points to the same hosts as repo
> repo1.maven.org, which are all running on the Sonatype-sponsored
> infrastructure. More detail and such are at
> http://central.sonatype.org/
>
> Manfred
>
> Stephen Connolly wrote on 2017-04-03 10:57:
>
> > Sonatype owns the host that our DNA name resolves to.
> >
> > In the (unlikely) event that sonatype ceases to provide the service this
> > would allow us to move to another provider, but there would be a lot of
> > work establishing content routes to publish to central in that event.
> >
> > On Mon 3 Apr 2017 at 17:46, Paul Hammant <p...@hammant.org> wrote:
> >
> >> Specifically, that domain - https://repo.maven.apache.org/maven2 on
> >> fastly.net infra ?
> >>
> >> On Mon, Apr 3, 2017 at 11:50 AM, Manfred Moser <
> manf...@simpligility.com>
> >> wrote:
> >>
> >> > Just to clarify... the whole infrastructure for Maven Central aka the
> >> > Central Repository is maintained and sponsored by Sonatype.
> >> >
> >> > manfred
> >> >
> >> > Paul Hammant wrote on 2017-04-03 07:07:
> >> >
> >> > > My bad - I'll explain more fully - I'm thinking of a read-only
> >> interface
> >> > > for querying the data within a maven repo.  I'm thinking of
> something
> >> > that
> >> > > is entirely static. Specifically it would use JavaScript
> >> > Angular/React/Vue
> >> > > and static JSON or maybe projname.POM files directly from
> JavaScript.
> >> > >
> >> > > I'm thinking of proposing such an app to Apache.  If the dev-list
> wants
> >> > to
> >> > > recuse itself from that, then I'm happy to go through the regular
> >> Apache
> >> > > channels.
> >> > >
> >> > >> PS.: This is more a question for the user mailing list and not for
> the
> >> > > developers mailing list
> >> > >
> >> > > You're right perhaps maven (as a end-user technology) is somewhat
> >> > different
> >> > > to a usage of data from https://repo.maven.apache.org/maven2 that
> >> > requires
> >> > > no additional server process/tech setup.
> >> > >
> >> > >
> >> > > On Sun, Apr 2, 2017 at 10:21 AM, Karl Heinz Marbaise <
> >> khmarba...@gmx.de>
> >> > > wrote:
> >> > >
> >> > >> Hi Paul,
> >> > >>
> >> > >> On 02/04/17 14:45, Paul Hammant wrote:
> >> > >>
> >> > >>> Apache hosts https://repo.maven.apache.org/maven2/ but there's no
> >> web
> >> > >>> app,
> >> > >>> just a raw index.
> >> > >>>
> >> > >>
> >> > >> For what purpose is a web app needed...This is Maven
> Central...which
> >> is
> >> > >> Maven Repository...which is intended to be consumed by Maven and
> many
> >> > other
> >> > >> tools...
> >> > >>
> >> > >> Also take a look here:
> >> > >>
> >> > >> https://maven.apache.org/repository/index.html
> >> > >>
> >> > >>
> >> > >> >
> >> > >>
> >> > >>> If we wanted to host a skinny but useful application
> >> > >>> there, how would we go about that?
> >> > >>>
> >> > >>
> >> > >> To get someting into Maven Central start here:
> >> > >>
> >> > >> http://central.sonatype.org/
> >> > >> http://central.sonatype.org/pages/requirements.html
> >> > >> https://maven.apache.org/guides/mini/guide-central-
> >> > repository-upload.html
> >> > >>
> >> > >> But it is not about hosting a web app etc. which mean running an
> >> > >> application inside something similar like Tomcat/JBoss. It's just a
> >> > >> repository to host a ja

Idea plugin

[Paul Hammant]

http://maven.apache.org/plugins/maven-idea-plugin/

It is marked as "retired", yet it is still available for resolution through
regular dependency declarations.  Bug reports are referred to JIRA on
Codehaus (RIP).

Can we get https://github.com/apache/maven-idea-plugin 1) setup, 2) the GH
issue tracker enabled, 3) the site docs re-deployed (s/retired/dormant/g)
please.

- Paul

Re: Apache owned index of Maven-Central artifacts?

[Paul Hammant]

My bad - I'll explain more fully - I'm thinking of a read-only interface
for querying the data within a maven repo.  I'm thinking of something that
is entirely static. Specifically it would use JavaScript Angular/React/Vue
and static JSON or maybe projname.POM files directly from JavaScript.

I'm thinking of proposing such an app to Apache.  If the dev-list wants to
recuse itself from that, then I'm happy to go through the regular Apache
channels.

> PS.: This is more a question for the user mailing list and not for the
developers mailing list

You're right perhaps maven (as a end-user technology) is somewhat different
to a usage of data from https://repo.maven.apache.org/maven2 that requires
no additional server process/tech setup.


On Sun, Apr 2, 2017 at 10:21 AM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi Paul,
>
> On 02/04/17 14:45, Paul Hammant wrote:
>
>> Apache hosts https://repo.maven.apache.org/maven2/ but there's no web
>> app,
>> just a raw index.
>>
>
> For what purpose is a web app needed...This is Maven Central...which is
> Maven Repository...which is intended to be consumed by Maven and many other
> tools...
>
> Also take a look here:
>
> https://maven.apache.org/repository/index.html
>
>
> >
>
>> If we wanted to host a skinny but useful application
>> there, how would we go about that?
>>
>
> To get someting into Maven Central start here:
>
> http://central.sonatype.org/
> http://central.sonatype.org/pages/requirements.html
> https://maven.apache.org/guides/mini/guide-central-repository-upload.html
>
> But it is not about hosting a web app etc. which mean running an
> application inside something similar like Tomcat/JBoss. It's just a
> repository to host a jar/zip/war which are avaible for consuming by
> application developers (dependencies) etc. but it is not for running an
> application...
>
>
>> Of course there are
>> * http://search.maven.org (hosted by Sonatype)
>>
>
> This is the search engine for Maven Central...human useable engine..
>
> https://repo.maven.apache.org/maven2/ machine consumable part...
>
>
> * https://mvnrepository.com
>>
>
> This is not related to Apache Software Foundation...
>
> PS.: This is more a question for the user mailing list and not for the
> developers mailing list
> 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: Apache owned index of Maven-Central artifacts?

[Paul Hammant]

Specifically, that domain - https://repo.maven.apache.org/maven2 on
fastly.net infra ?

On Mon, Apr 3, 2017 at 11:50 AM, Manfred Moser <manf...@simpligility.com>
wrote:

> Just to clarify... the whole infrastructure for Maven Central aka the
> Central Repository is maintained and sponsored by Sonatype.
>
> manfred
>
> Paul Hammant wrote on 2017-04-03 07:07:
>
> > My bad - I'll explain more fully - I'm thinking of a read-only interface
> > for querying the data within a maven repo.  I'm thinking of something
> that
> > is entirely static. Specifically it would use JavaScript
> Angular/React/Vue
> > and static JSON or maybe projname.POM files directly from JavaScript.
> >
> > I'm thinking of proposing such an app to Apache.  If the dev-list wants
> to
> > recuse itself from that, then I'm happy to go through the regular Apache
> > channels.
> >
> >> PS.: This is more a question for the user mailing list and not for the
> > developers mailing list
> >
> > You're right perhaps maven (as a end-user technology) is somewhat
> different
> > to a usage of data from https://repo.maven.apache.org/maven2 that
> requires
> > no additional server process/tech setup.
> >
> >
> > On Sun, Apr 2, 2017 at 10:21 AM, Karl Heinz Marbaise <khmarba...@gmx.de>
> > wrote:
> >
> >> Hi Paul,
> >>
> >> On 02/04/17 14:45, Paul Hammant wrote:
> >>
> >>> Apache hosts https://repo.maven.apache.org/maven2/ but there's no web
> >>> app,
> >>> just a raw index.
> >>>
> >>
> >> For what purpose is a web app needed...This is Maven Central...which is
> >> Maven Repository...which is intended to be consumed by Maven and many
> other
> >> tools...
> >>
> >> Also take a look here:
> >>
> >> https://maven.apache.org/repository/index.html
> >>
> >>
> >> >
> >>
> >>> If we wanted to host a skinny but useful application
> >>> there, how would we go about that?
> >>>
> >>
> >> To get someting into Maven Central start here:
> >>
> >> http://central.sonatype.org/
> >> http://central.sonatype.org/pages/requirements.html
> >> https://maven.apache.org/guides/mini/guide-central-
> repository-upload.html
> >>
> >> But it is not about hosting a web app etc. which mean running an
> >> application inside something similar like Tomcat/JBoss. It's just a
> >> repository to host a jar/zip/war which are avaible for consuming by
> >> application developers (dependencies) etc. but it is not for running an
> >> application...
> >>
> >>
> >>> Of course there are
> >>> * http://search.maven.org (hosted by Sonatype)
> >>>
> >>
> >> This is the search engine for Maven Central...human useable engine..
> >>
> >> https://repo.maven.apache.org/maven2/ machine consumable part...
> >>
> >>
> >> * https://mvnrepository.com
> >>>
> >>
> >> This is not related to Apache Software Foundation...
> >>
> >> PS.: This is more a question for the user mailing list and not for the
> >> developers mailing list
> >> 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
>
>

Apache owned index of Maven-Central artifacts?

[Paul Hammant]

Apache hosts https://repo.maven.apache.org/maven2/ but there's no web app,
just a raw index.  If we wanted to host a skinny but useful application
there, how would we go about that?

Of course there are
* http://search.maven.org (hosted by Sonatype)
* https://mvnrepository.com
* others, but I forget

Is that a question for the Maven dev team, or a Apachemembers/infra
question?

- Paul

Re: Building a Java9 project just using JDK9

[Paul Hammant]

>
>
>> I don't see any activity either, so my idea is to replace XStream, see
> MWAR-397[1]
>

Just for the record, Jörg is working through the Java9 issues for XStream
presently - https://github.com/x-stream/xstream/commits/master

- Paul

Re: Publish Maven releases on SDKMAN!

[Paul Hammant]

Prior conversation -
https://www.mail-archive.com/search?q=Vermeulen=dev%40maven.apache.org



On Sat, Apr 15, 2017 at 6:56 PM, Marco Vermeulen 
wrote:

> Hi Maven folks,
>
> Some time ago I asked the Maven dev community whether they would be willing
> to publish their releases on SDKMAN! [1] using our Vendor API [2].
> Unfortunately, my request was met with scepticism and ultimately resulted
> in no action taken.
>
> I would like to appeal to the Maven dev community again to take on the
> responsibility of managing their own releases on our platform. The process
> is very simple: It involves making a few REST calls to our API and
> instantaneously releases become available for all the SDKMAN! users out
> there.
>
> Many other teams are already doing this, including Gradle, Kotlin, Groovy,
> Ceylon and Spring Boot to name a few. It would be great to have you guys on
> board too.
>
> I currently perform these releases for Maven manually, which unfortunately
> is not something I can sustain going forward.
>
> Please let me know if someone is willing to step up to this and feel free
> to contact me directly at ma...@sdkman.io
>
> Cheers!
> Marco.
>
>
> [1] http://sdkman.io
> [2] http://sdkman.io/vendors.html
>

Re: Publish Maven releases on SDKMAN!

[Paul Hammant]

So by sell, I meant an idea too. I'm forever trying to sell things I think
are best, but am not going to make money from.

Can you link to the conversations about the lack of Maven in SDKMAN-land?

Did you understand what I was getting at in my last mail? You didn't
address them, which is your right of course.

On Sat, Apr 15, 2017 at 7:33 PM, Marco Vermeulen <vermeulen...@gmail.com>
wrote:

> Paul,
>
> I really am not trying to sell anything. I'm trying to help your community.
> You will get no *arguments* in favour or against from me.
>
> My users keep asking for Maven on SDKMAN, and I sincerely wish to give them
> what they ask for. Whether the community is willing to lend a hand is
> entirely up to the *committers* of this project.
>
> On Sun, 16 Apr 2017 at 00:12 Paul Hammant <p...@hammant.org> wrote:
>
> > Marco,
> >
> > You could sell your idea better, I think. You have "Most of the big
> > projects want to do this" as one of the stronger arguments in favor,
> which
> > isn't enough. For 20 years, Lean/Agilistas have focussed on "what is the
> > problem you're trying to solve?". And that is the question, I personally*
> > would want to make to you.
> >
> > * I'm an interloper to this list, not a committer.
> >
> > Maven experts really do one setup thing: "brew install maven" (or equiv).
> >
> > Then they clone repos that purport to be example applications for the
> think
> > they want (SpringBoot, Grails). Then they mvn install that and the bits
> of
> > the SDK they need come down to their local cache. It has been four years
> > since I last acquired a new JVM technology any other way.
> >
> > - Paul
> >
>

Re: Publish Maven releases on SDKMAN!

[Paul Hammant]

Marco,

You could sell your idea better, I think. You have "Most of the big
projects want to do this" as one of the stronger arguments in favor, which
isn't enough. For 20 years, Lean/Agilistas have focussed on "what is the
problem you're trying to solve?". And that is the question, I personally*
would want to make to you.

* I'm an interloper to this list, not a committer.

Maven experts really do one setup thing: "brew install maven" (or equiv).

Then they clone repos that purport to be example applications for the think
they want (SpringBoot, Grails). Then they mvn install that and the bits of
the SDK they need come down to their local cache. It has been four years
since I last acquired a new JVM technology any other way.

- Paul

Re: Redesign website

[Paul Hammant]

I would move to plain markdown in git with one of Hugo or Hexo as the
static site generators, if I were the decider for this (I am not of course).

https://trunkbaseddevelopment.com is Hugo (Go-based) and took me about a
month from start to launch, and after/before regular work. I've another in
Hexo (Node-based) but it's far from ready to share yet. Jekyll is too slow
these days.

The absolute thing *you must have* is an edit-this-page link for each page,
and these days that doesn't mean a wiki, it means a link to the VCS's
edit-a-resource UI. For example, the bottom of
https://trunkbaseddevelopment.com/branch-for-release/ has a Contribute to
this page
<https://github.com/paul-hammant/tbd/edit/master/content/branch-for-release/index.md>
link
that you can harmless click right now to see where that ends up :)

On Fri, Jul 21, 2017 at 12:28 PM, Anton Tanasenko <atg.sleepl...@gmail.com>
wrote:

> What happened to the last attempt and the shotgun owl? :-D
>
> On Fri, 21 Jul 2017, 18:22 Robert Scholte, <rfscho...@apache.org> wrote:
>
> > Hi,
> >
> > I'd like to start an attempt to redesign our website.
> > At ApacheCon Europe Hervé and I got in touch with Open Source Design[1].
> > Any objections to contact them and to see if we can help each other?
> > Or are there other suggestions?
> >
> > thanks,
> > Robert
> >
> > [1] http://opensourcedesign.net
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Expected speed of commit over HTTP?

[Paul Hammant]

For something that's 500MB in size (random binary data) I'm experiencing
commits taking
10x longer than a straight copy to the drive the Svn repo is on.

Both timings are on the same Ubuntu 17.04 machine, with the boot drive
being the starting position of the 512MB file and a USB3 mounted 4TB
seagate hard drive being the destination.

My goal is to fill the 4TB drive with commits for the simple experience of
that.

How many places in the Apache2 --> mod_dav --> mod_dav_svn handoff does the
512MB temporarily manifest itself in a file system on the way to its
ultimate destination?  Is 1/10th speed the expectation?  Sure, I get that
7bit/8bit shenanigans are a factor, but not that much right?

- Paul

Re: Expected speed of commit over HTTP?

[Paul Hammant]

My bad - sorry.

On Thu, Jul 6, 2017 at 7:34 AM, Michael Osipov <micha...@apache.org> wrote:

> Am 2017-07-06 um 13:16 schrieb Paul Hammant:
>
>> For something that's 500MB in size (random binary data) I'm experiencing
>> commits taking
>> 10x longer than a straight copy to the drive the Svn repo is on.
>>
>> Both timings are on the same Ubuntu 17.04 machine, with the boot drive
>> being the starting position of the 512MB file and a USB3 mounted 4TB
>> seagate hard drive being the destination.
>>
>> My goal is to fill the 4TB drive with commits for the simple experience of
>> that.
>>
>> How many places in the Apache2 --> mod_dav --> mod_dav_svn handoff does
>> the
>> 512MB temporarily manifest itself in a file system on the way to its
>> ultimate destination?  Is 1/10th speed the expectation?  Sure, I get that
>> 7bit/8bit shenanigans are a factor, but not that much right?
>>
>
> Wrong mailingt list...
>
>
> -
> 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]

So the alternate strategy (to what I tested 11 hrs ago) would be to change
the release plugin so that it can do its work on a sub-directory safely.

   cd 
   cd maven-changes-plugin
   mvn release:prepare
   mvn release:perform

We note after the event that the release was* tagged in SCM with something
strong like 'maven-changes-plugin-3.0.0'*.

We also silently lament that Git doesn't have branch mappings like
Perforce. Indeed, just one small aspect of branch mapping - the ability to
remove sections of the tree in the branch and* maintain that divergence
going forwards*. Of course tags are not branches, but you know what I
mean.  In Git given it's content based storage, there's no storage
downsides from a branch/tag for 'maven-changes-plugin-3.0.0' also
containing all other plugins. Well no storage downsides ignoring working
copy (the checkout).

- Paul

On Tue, Jun 27, 2017 at 8:14 PM, Paul Hammant <p...@hammant.org> wrote:

> OK, I tried something new.
>
> *Goal*: all the plugins in one Git repo (less CI jobs to set up - just
> one recursive multi-module maven build).
> *Constraint*: Plugins must be independently releasable.
>
> *Test:* Take two modules from the Svn repo and check them in to master
> (the rest were deleted - test needs two and a parent pom in master).
>
> *Repository*: https://github.com/paul-hammant/ph_testplugins
>
> Of the two modules checked in, maven-changes-plugin is the one I attempted
> to release to my com/paulhammant/ group on 'Central. The workflow for the
> release of that single module is here https://github.com/paul-
> hammant/ph_testplugins/blob/master/CHANGES_PLUGIN_RELEASE_WORKFLOW.md
>
> *Result of Test:* failed, but in a surprising way and at a very late stage
>
> During the release:perform stage the maven tried to push to
> https://oss.sonatype.org/content/repositories/snapshots
> /com/paulhammant/testplugins-ph-chgs-pi/3.0.0-SNAPSHOT/
> testplugins-ph-chgs-pi-3.0.0-20170627.234743-1.jar which is nuts because
> I'm not trying to push to a SNAPSHOT, I'm trying to do a proper release of
> 3.0.0 (of my renamed to an obscure name plugin).
>
> The documentation for the  part of the pom says that it honors the
> name of the local branch for the sequence of commits that the release
> plugin does. Which is exactly what you'd want. I've already tested it a
> dozen times and it does the right thing by way of tags too.  It's only that
> SNAPSHOT weirdness during the upload that ends the experiment, and that's a
> fairly late stage piece. My plan was to go onto oss.sonatype.org and
> delete it from staging so it would ultimately go nowhere.
>
> Barring that bug, this would work for all of the Maven plugins in a single
> repo, meaning a lot less permutations for CI, albeit with a longer build
> per commit. I don't think that last is a big issue for this proposed
> repository.
>
> Any of you could clone the repo I have made, and do the same steps as
> CHANGES_PLUGIN_RELEASE_WORKFLOW.md document to get to the same place I
> got to (a 401 error from Sonatype's DAV infra). And one of you could tell
> me what I did wrong with the setup to encounter that snapshot issue :)
>
> - Paul
>
>
>
>
>

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

Article updated to eliminate misunderstandings and talk about a different
index for 'maven central' too.

- ph

On Sat, May 13, 2017 at 3:04 PM, Paul Hammant <p...@hammant.org> wrote:

> I was discussing this of the list today, and it may interest people on dev@
>
> https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/
>
>  "Maven Central as multiple Git repositories"
>
> Enjoy,
>
> - Paul
>

Maven-monitor still in use?

[Paul Hammant]

I''m looking to make a build radiator. Something like this -
https://www.stevefenton.co.uk/wp-content/uploads/2015/07/cruiser.jpg

I don't want to scrape logs to detect maven phase changes, and
corresponding pass/fail, I want to use a plugin. I think that plugin
is Maven-monitor

Online documentation for that is here
http://maven.apache.org/ref/2.2.1/maven-monitor/ and that doesn't say much,
except to direct the user to subversion (where the plugin still resides).

In use a few versions can be downloaded* - meaning even if I could make my
own version of Maven monitor, I would struggle to get it used exclusively
through the entire 'mvn' invocation.

Advice ?

* e.g.the build for maven-monitor-2.2.1 downloads v2.0.5 AND v2.0.9 of
itself. Different projects are going to download/use multiple different
versions of course.

- Paul

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

There's one repo per thing that is versioned. All these are separate repos

g: com/thoughtworks/paranamer a: paranamer type: javadoc  is one repo
g: com/thoughtworks/paranamer a: paranamer type: sources  is one repo
g: com/thoughtworks/paranamer a: paranamer type: classes  is one repo
g: com/thoughtworks/xstream a: xstream type: javadoc  is one repo
g: com/thoughtworks/xstream a: xstream type: sources  is one repo
g: com/thoughtworks/xstream a: xstream type: classes  is one repo

Or you could do it in less repos, I'm sure, and Git will still make a
compression saving.

And despite what you said, Git manages to find some commonality in *binary
classes *to make a saving. XStream's regular JARs:

Total size for *27* original versions 8.4MB
The .git folder afterwards 2.4MB
Raw/bare storage space saving 71.4%
Your point about the git:// protocol being being more chatty that http://
is true. That's probably more CPU on the server side. It is definitely more
time. See here ...

Git takes 1s to do:

git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 --branch
1.4.3 --bare


Wget takes 0.5s to do:

wget http://central.maven.org/maven2/com/thoughtworks/
xstream/xstream/1.4.3/xstream-1.4.3.jar


On pom files - they are within the base Git repos, yes.  You can't get them
from the server to the client in one Git operation, without bringing at
least a whole tag. Maybe there could be a tag just for the POM file to make
it addressable remotely, and checkoutable locally. I'll test that later
today.

- Paul


On Mon, May 15, 2017 at 4:14 AM, Stian Soiland-Reyes <st...@apache.org>
wrote:



> Interesting idea! All for experimenting with git!
>
> You did not take into account the protocol differences, fetching a single
> 8MB  jar from Maven Central is easy, while fetching 6 MB via multiple git
> HTTP resources (even assuming git packs there will be multiple http calls)
> is probably more expensive, particularly as a typical project may have 50
> dependencies.
>
> Would each version be a new git repo? The binary class files are not really
> suitable for "diffing" and would pretty sure be changed every release (even
> if the SRC is the exact same).
>
> It is possible in JAR to use jar200 packing, which can significantly reduce
> the compressed size. Perhsps that is relevant here. See
> http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html
>
> Are the pom files within these git repositories or can they be prefetched
> separately like today to speed up transitive dependency loading?
>
>

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files added
to Git. Git makes 70% saving on bytes used ('bare' mode).

On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <ald...@leal.eng.br> wrote:

> Just a friendly reminder that git is not optimized for large files (for
> this, they made git-lfs). Plus, when you do checkout a git repo, there's no
> binary diffs - so if you've got plenty of releases, you'll be wasting a lot
> of space/time in terms of transmission and storage.
>
> --
> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org> wrote:
>
> > We can agree to differ on what I'm suggesting and what the impact of that
> > would be :)
> >
> > On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu> wrote:
> >
> > > Even more than redefining what Central does, you're effectively
> > describing
> > > a new, unofficial java class packaging and distribution mechanism. This
> > > seems like it will violate signatures etc and make tracking of what you
> > > actually have a nightmare.
> > >
> > > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> > > wrote:
> > >
> > > > this idea of putting everything in git is funny: not sure this will
> go
> > > very
> > > > far from this poc, but let's imagine...
> > > >
> > > > on classes branch, splitting the jar into individual .class has IMHO
> a
> > > big
> > > > drawback: we loose original jar and its signature
> > > >
> > > > On the other branches, the current poc shows commits for versions
> that
> > > are
> > > > perfectly linear: if there are multiple branches that are released in
> > > > parallel, the commit won't be so clean. I don't know if this will
> have
> > an
> > > > impact on compression efficiency.
> > > >
> > > > Another issue with this idea: during development, with SNAPSHOTs, the
> > git
> > > > repo
> > > > will be polluted: this idea IMHO could only be valid for releases
> > > >
> > > > not to speak about read concurrency when one requires to use multiple
> > > > versions
> > > > of a lib. And of course, write concurrency is even harder.
> > > >
> > > >
> > > > Definitely, the idea is funny, but I don't see how this could go very
> > far
> > > > than
> > > > this funny idea (in addition to the complexity for implementing this
> > > > format in
> > > > tooling)
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le lundi 15 mai 2017, 21:45:00 CEST Paul Hammant a écrit :
> > > > > One more repo:
> > > > >
> > > > > https://github.com/paul-hammant/mc-xs-all/
> > > > >
> > > > > One branch for each of classes, javadoc, sources, and poms
> > > > >
> > > > > 15 javadoc original versions: 24.1M
> > > > >
> > > > > 16 sources original versions: 4.9M
> > > > >
> > > > > 27 classes original versions: 8.4M
> > > > >
> > > > > Afterwards git work the bare .git folder is: 8.4M
> > > > >
> > > > > *77.5% saving on storage*
> > > > >
> > > > > Any artifact, *including the poms,* can be pulled down via a single
> > git
> > > > > command
> > > > >
> > > > > git clone https://github.com/paul-hammant/mc-xs-classes --depth 1
> > > > --branch
> > > > > TAGNAME
> > > > >
> > > > > 74 TAGNAMEs: classes-0.1, classes-0.2, classes-0.3, classes-0.5,
> > > > > classes-0.6, classes-1.0, classes-1.0.1, classes-1.0.2,
> classes-1.1,
> > > > > classes-1.1.1, classes-1.1.2, classes-1.1.3, classes-1.2,
> > > classes-1.2.1,
> > > > > classes-1.2.2, classes-1.3, classes-1.3.1, classes-1.4,
> > classes-1.4.1,
> > > > > classes-1.4.2, classes-1.4.3, classes-1.4.4, classes-1.4.5,
> > > > classes-1.4.6,
> > > > > classes-1.4.7, classes-1.4.8, classes-1.4.9, javadoc-1.2,
> > > javadoc-1.2.1,
> > > > > javadoc-1.2.2, javadoc-1.3, javadoc-1.3.1, javadoc-1.4,
> > javadoc-1.4.1,
> > > > > javadoc-1.4.2, javadoc-1.4.3, javadoc-1.4.4, javadoc-1.4.5,
> > > > javadoc-1.4.6,
> > > > > javadoc-1.4.7, javadoc-1.4.8, javadoc-1.4.9, pom-1.2, pom-1.2.1,
> > > > pom-1.2.2,
> > > > > pom-1.3, pom-1.3.1, pom-1.4, pom-1.4.1, pom-1.4.2, pom-1.4.3,
> > > pom-1.4.4,
> > > > > pom-1.4.5, pom-1.4.6, pom-1.4.7, pom-1.4.8, pom-1.4.9,
> sources-1.1.3,
> > > > > sources-1.2, sources-1.2.1, sources-1.2.2, sources-1.3,
> > sources-1.3.1,
> > > > > sources-1.4, sources-1.4.1, sources-1.4.2, sources-1.4.3,
> > > sources-1.4.4,
> > > > > sources-1.4.5, sources-1.4.6, sources-1.4.7, sources-1.4.8,
> > > sources-1.4.9
> > > > >
> > > > >  - Paul
> > > >
> > > >
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

There is that, yes. And Git's general upper limits which are subject of "I
heard of a team that had a corruption at 2GB".  I've field tested Git up to
7GB for a git-svn-clone myself (a team considering saying bye bye to Svn),
but wouldn't put that live versus hive off history to a R/O repo, and start
over with HEAD of the old becoming the initial commit of the new.

- Paul

On Wed, May 17, 2017 at 2:40 PM, Aldrin Leal <ald...@leal.eng.br> wrote:

> Still, once github gets an outage, our repositories are basically
> 'left-padded' (taken offline)
>
> --
> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <p...@hammant.org> wrote:
>
> > Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files
> added
> > to Git. Git makes 70% saving on bytes used ('bare' mode).
> >
> > On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <ald...@leal.eng.br>
> wrote:
> >
> > > Just a friendly reminder that git is not optimized for large files (for
> > > this, they made git-lfs). Plus, when you do checkout a git repo,
> there's
> > no
> > > binary diffs - so if you've got plenty of releases, you'll be wasting a
> > lot
> > > of space/time in terms of transmission and storage.
> > >
> > > --
> > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
> > >
> > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org>
> wrote:
> > >
> > > > We can agree to differ on what I'm suggesting and what the impact of
> > that
> > > > would be :)
> > > >
> > > > On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu>
> wrote:
> > > >
> > > > > Even more than redefining what Central does, you're effectively
> > > > describing
> > > > > a new, unofficial java class packaging and distribution mechanism.
> > This
> > > > > seems like it will violate signatures etc and make tracking of what
> > you
> > > > > actually have a nightmare.
> > > > >
> > > > > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY <
> > herve.bout...@free.fr>
> > > > > wrote:
> > > > >
> > > > > > this idea of putting everything in git is funny: not sure this
> will
> > > go
> > > > > very
> > > > > > far from this poc, but let's imagine...
> > > > > >
> > > > > > on classes branch, splitting the jar into individual .class has
> > IMHO
> > > a
> > > > > big
> > > > > > drawback: we loose original jar and its signature
> > > > > >
> > > > > > On the other branches, the current poc shows commits for versions
> > > that
> > > > > are
> > > > > > perfectly linear: if there are multiple branches that are
> released
> > in
> > > > > > parallel, the commit won't be so clean. I don't know if this will
> > > have
> > > > an
> > > > > > impact on compression efficiency.
> > > > > >
> > > > > > Another issue with this idea: during development, with SNAPSHOTs,
> > the
> > > > git
> > > > > > repo
> > > > > > will be polluted: this idea IMHO could only be valid for releases
> > > > > >
> > > > > > not to speak about read concurrency when one requires to use
> > multiple
> > > > > > versions
> > > > > > of a lib. And of course, write concurrency is even harder.
> > > > > >
> > > > > >
> > > > > > Definitely, the idea is funny, but I don't see how this could go
> > very
> > > > far
> > > > > > than
> > > > > > this funny idea (in addition to the complexity for implementing
> > this
> > > > > > format in
> > > > > > tooling)
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > Le lundi 15 mai 2017, 21:45:00 CEST Paul Hammant a écrit :
> > > > > > > One more repo:
> > > > > > >
> > > > > > > https://github.com/paul-hammant/mc-xs-all/
> > > > > > >
> > > > > > > One branch for each of classes, javadoc, sources, and 

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

Aldrin, The blog entry I wrote on saturday mulled classes, javadocs and
sources -
https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/ (re
your "way more than" comment).

The GH repo I linked you to earlier has all three in one repo (see the
branches drop-down) - https://github.com/paul-hammant/mc-xs-all

- Paul



On Wed, May 17, 2017 at 2:54 PM, Aldrin Leal <ald...@leal.eng.br> wrote:

> I understand the approach is basically general, but maven artifacts are way
> more than binary code (there's source and javadoc). I also understand its
> an interesting option for distribution.
>
> I really would like to see something close to what "go get" does. If not
> github and bitbucket (and go get includes git, hg and bzr among scms), it
> open the URL itself and resolve it into a(by means of HTML metadata).
>
> Just distributing the source allowing it to easily updates would be
> awesome, since it would allow less effort to create and distribute. Of
> course, we could have to limit the scope of what to do to avoid abuse.
>
>
> --
> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 1:49 PM, Paul Hammant <p...@hammant.org> wrote:
>
> > There is that, yes. And Git's general upper limits which are subject of
> "I
> > heard of a team that had a corruption at 2GB".  I've field tested Git up
> to
> > 7GB for a git-svn-clone myself (a team considering saying bye bye to
> Svn),
> > but wouldn't put that live versus hive off history to a R/O repo, and
> start
> > over with HEAD of the old becoming the initial commit of the new.
> >
> > - Paul
> >
> > On Wed, May 17, 2017 at 2:40 PM, Aldrin Leal <ald...@leal.eng.br> wrote:
> >
> > > Still, once github gets an outage, our repositories are basically
> > > 'left-padded' (taken offline)
> > >
> > > --
> > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
> > >
> > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <p...@hammant.org>
> wrote:
> > >
> > > > Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files
> > > added
> > > > to Git. Git makes 70% saving on bytes used ('bare' mode).
> > > >
> > > > On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <ald...@leal.eng.br>
> > > wrote:
> > > >
> > > > > Just a friendly reminder that git is not optimized for large files
> > (for
> > > > > this, they made git-lfs). Plus, when you do checkout a git repo,
> > > there's
> > > > no
> > > > > binary diffs - so if you've got plenty of releases, you'll be
> > wasting a
> > > > lot
> > > > > of space/time in terms of transmission and storage.
> > > > >
> > > > > --
> > > > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
> > > > >
> > > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org>
> > > wrote:
> > > > >
> > > > > > We can agree to differ on what I'm suggesting and what the impact
> > of
> > > > that
> > > > > > would be :)
> > > > > >
> > > > > > On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu>
> > > wrote:
> > > > > >
> > > > > > > Even more than redefining what Central does, you're effectively
> > > > > > describing
> > > > > > > a new, unofficial java class packaging and distribution
> > mechanism.
> > > > This
> > > > > > > seems like it will violate signatures etc and make tracking of
> > what
> > > > you
> > > > > > > actually have a nightmare.
> > > > > > >
> > > > > > > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY <
> > > > herve.bout...@free.fr>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > this idea of putting everything in git is funny: not sure
> this
> > > will
> > > > > go
> > > > > > > very
> > > > > > > > far from this poc, but let's imagine...
> > > > > > > >
> > > > > > > > on classes branch, splitting the jar into individual .class
> has
> > > > IMHO
> > > > > a
> > > > > > > big
> > > > > > > &g

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

Robert,

>From the blog entry:


*Actually changing Maven Central to do this*
The maven ‘deploy’ workflow and plugin would invisibly do a commit to (or
create of) a dedicated Git repo up on central.

For XStream, a new deployment would not go into
http://central.maven.org/maven2/com/thoughtworks/xstream/xstream/ any more.
Instead they would go into (say) g...@central.maven.org:
maven2/com/thoughtworks/xstream/xstream.git

The maintainer for the group:artifact would not have to do anything
different to exist in the new deploy world, all the heavy lifting is done
in Maven Central and that future version of the deploy plugin. They would
have to upgrade their project to that deploy plugin, of course.

It is not just Maven Central. It would be Artifactory, Nexus, Gradle (etc)
technologies too.


I just put it on Github as that is an easy place to do look-here-see-bro
discussions.

:)

- Paul


On Wed, May 17, 2017 at 3:29 PM, Robert Scholte <rfscho...@apache.org>
wrote:
>
> On Wed, 17 May 2017 20:41:02 +0200, Paul Hammant <p...@hammant.org> wrote:
>
>> I would agree that it has the potential to be a new repository
>> implementation, Robert.
>> But I am not sure I follow your second sentence.
>
>
> So suppose I want to add xstream-1.4.9 as dependency to my project. How
should Maven know it has to go to
https://github.com/paul-hammant/mc-xs-classes?
> You need some kind of mapping, and with this structure you have to do it
for every git-stored dependency.
> The most straight-forward solution would be to add repositories (which
might fit in POM model 4.0.0), but I cannot imagine users want to do that
for every dependency.
>
> Robert
>
>
>
>> Maybe I do. There is one
>> Git repo per group/artifact. That's true for whether it is the principal
>> artifact you're after or a transitive dep.
>>
>> 1. For https://github.com/paul-hammant/mc-xs-all I have the sources,
>> classes, and javadoc as separate branches in one repo.
>>
>> 2. For https://github.com/paul-hammant/mc-xs-classes and
>> https://github.com/paul-hammant/mc-xs-javadocs and
>> https://github.com/paul-hammant/mc-xs-sources I have three Git repos per
>> group/artifact.
>>
>> #1 and #2 are alternate coices. #1 has poms in their own branch in that
Git
>> repo too - and they too are one-line retrievable from the remote.
>>
>> - Paul
>>
>> On Wed, May 17, 2017 at 1:27 PM, Robert Scholte <rfscho...@apache.org>
>> wrote:
>>
>>> I consider this as a new repository implementation. But this also
implies
>>> that in your pom, for every dependency you have to add a
repository-entry
>>> as well, right?
>>>
>>> Robert
>>>
>>>
>>> On Wed, 17 May 2017 17:10:49 +0200, Aldrin Leal <ald...@leal.eng.br>
>>> wrote:
>>>
>>> Just a friendly reminder that git is not optimized for large files (for
>>>>
>>>> this, they made git-lfs). Plus, when you do checkout a git repo,
there's
>>>> no
>>>> binary diffs - so if you've got plenty of releases, you'll be wasting a
>>>> lot
>>>> of space/time in terms of transmission and storage.
>>>>
>>>> --
>>>> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
>>>>
>>>> On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org> wrote:
>>>>
>>>> We can agree to differ on what I'm suggesting and what the impact of
that
>>>>>
>>>>> would be :)
>>>>>
>>>>> On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu> wrote:
>>>>>
>>>>> > Even more than redefining what Central does, you're effectively
>>>>> describing
>>>>> > a new, unofficial java class packaging and distribution mechanism.
This
>>>>> > seems like it will violate signatures etc and make tracking of what
you
>>>>> > actually have a nightmare.
>>>>> >
>>>>> > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY <
herve.bout...@free.fr>
>>>>> > wrote:
>>>>> >
>>>>> > > this idea of putting everything in git is funny: not sure this
will
>>>>> go
>>>>> > very
>>>>> > > far from this poc, but let's imagine...
>>>>> > >
>>>>> > > on classes branch, splitting the jar into individual .class has
IMHO
>>>>> a
>>>>> > big
>>>>> > > drawback: we loose original jar and its signature
>>

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

Hervé,

on classes branch, splitting the jar into individual .class has IMHO a big
> drawback: we loose original jar and its signature
>

Agree. Git doesn't care about timestamps for classes in jars. Java doesn't
either, but SHA1 (etc) of the jar does.

Thus - the next iteration will reproduce even the timestamps of a resulting
jar.


>
> On the other branches, the current poc shows commits for versions that are
> perfectly linear: if there are multiple branches that are released in
> parallel, the commit won't be so clean. I don't know if this will have an
> impact on compression efficiency.
>

They can go in any random order (I tested) and Git achieves the same over
all saving.


>
> Another issue with this idea: during development, with SNAPSHOTs, the git
> repo
> will be polluted: this idea IMHO could only be valid for releases
>

That's true. I'm really only focussed on the bring-down-from-maven-central
cycle. Obviously I need an answer for the on-workstation workflow which
inserts into ~/.m2/repository/ too.


>
> not to speak about read concurrency when one requires to use multiple
> versions
> of a lib. And of course, write concurrency is even harder.
>

I'm not following, dude.

- Paul

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

I would agree that it has the potential to be a new repository
implementation, Robert.
But I am not sure I follow your second sentence.  Maybe I do. There is one
Git repo per group/artifact. That's true for whether it is the principal
artifact you're after or a transitive dep.

1. For https://github.com/paul-hammant/mc-xs-all I have the sources,
classes, and javadoc as separate branches in one repo.

2. For https://github.com/paul-hammant/mc-xs-classes and
https://github.com/paul-hammant/mc-xs-javadocs and
https://github.com/paul-hammant/mc-xs-sources I have three Git repos per
group/artifact.

#1 and #2 are alternate coices. #1 has poms in their own branch in that Git
repo too - and they too are one-line retrievable from the remote.

- Paul

On Wed, May 17, 2017 at 1:27 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> I consider this as a new repository implementation. But this also implies
> that in your pom, for every dependency you have to add a repository-entry
> as well, right?
>
> Robert
>
>
> On Wed, 17 May 2017 17:10:49 +0200, Aldrin Leal <ald...@leal.eng.br>
> wrote:
>
> Just a friendly reminder that git is not optimized for large files (for
>> this, they made git-lfs). Plus, when you do checkout a git repo, there's
>> no
>> binary diffs - so if you've got plenty of releases, you'll be wasting a
>> lot
>> of space/time in terms of transmission and storage.
>>
>> --
>> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
>>
>> On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org> wrote:
>>
>> We can agree to differ on what I'm suggesting and what the impact of that
>>> would be :)
>>>
>>> On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu> wrote:
>>>
>>> > Even more than redefining what Central does, you're effectively
>>> describing
>>> > a new, unofficial java class packaging and distribution mechanism. This
>>> > seems like it will violate signatures etc and make tracking of what you
>>> > actually have a nightmare.
>>> >
>>> > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY <herve.bout...@free.fr>
>>> > wrote:
>>> >
>>> > > this idea of putting everything in git is funny: not sure this will
>>> go
>>> > very
>>> > > far from this poc, but let's imagine...
>>> > >
>>> > > on classes branch, splitting the jar into individual .class has IMHO
>>> a
>>> > big
>>> > > drawback: we loose original jar and its signature
>>> > >
>>> > > On the other branches, the current poc shows commits for versions
>>> that
>>> > are
>>> > > perfectly linear: if there are multiple branches that are released in
>>> > > parallel, the commit won't be so clean. I don't know if this will
>>> have
>>> an
>>> > > impact on compression efficiency.
>>> > >
>>> > > Another issue with this idea: during development, with SNAPSHOTs, the
>>> git
>>> > > repo
>>> > > will be polluted: this idea IMHO could only be valid for releases
>>> > >
>>> > > not to speak about read concurrency when one requires to use multiple
>>> > > versions
>>> > > of a lib. And of course, write concurrency is even harder.
>>> > >
>>> > >
>>> > > Definitely, the idea is funny, but I don't see how this could go very
>>> far
>>> > > than
>>> > > this funny idea (in addition to the complexity for implementing this
>>> > > format in
>>> > > tooling)
>>> > >
>>> > > Regards,
>>> > >
>>> > > Hervé
>>> > >
>>> > > Le lundi 15 mai 2017, 21:45:00 CEST Paul Hammant a écrit :
>>> > > > One more repo:
>>> > > >
>>> > > > https://github.com/paul-hammant/mc-xs-all/
>>> > > >
>>> > > > One branch for each of classes, javadoc, sources, and poms
>>> > > >
>>> > > > 15 javadoc original versions: 24.1M
>>> > > >
>>> > > > 16 sources original versions: 4.9M
>>> > > >
>>> > > > 27 classes original versions: 8.4M
>>> > > >
>>> > > > Afterwards git work the bare .git folder is: 8.4M
>>> > > >
>>> > > > *77.5% saving on storage*
>>> >

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

I'm "just" unzipping the source, and committing those sources. Sure, I
delete the previous set first, but I merge the *rm* set and *add* set into
one commit with an --amend ->

 # fn is xstream-1.4.3.jar and v is 1.4.3 for example

 git("rm", "-r", "*")

git("commit", "-m", v)
wget(root + url + "/" + v + "/" + fn)
unzip(fn)
rm(fn)
git("add", ".")
git("commit", "-m", v, "--amend")

On Wed, May 17, 2017 at 3:41 PM, Aldrin Leal <ald...@leal.eng.br> wrote:

> thats my point: the golang approach does no magic at all. It simply stores
> the source code and bases it on a convention. Just the files, and thats it.
>
> --
> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 2:38 PM, Paul Hammant <p...@hammant.org> wrote:
>
> > Aldrin, The blog entry I wrote on saturday mulled classes, javadocs and
> > sources -
> > https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/
> > (re
> > your "way more than" comment).
> >
> > The GH repo I linked you to earlier has all three in one repo (see the
> > branches drop-down) - https://github.com/paul-hammant/mc-xs-all
> >
> > - Paul
> >
> >
> >
> > On Wed, May 17, 2017 at 2:54 PM, Aldrin Leal <ald...@leal.eng.br> wrote:
> >
> > > I understand the approach is basically general, but maven artifacts are
> > way
> > > more than binary code (there's source and javadoc). I also understand
> its
> > > an interesting option for distribution.
> > >
> > > I really would like to see something close to what "go get" does. If
> not
> > > github and bitbucket (and go get includes git, hg and bzr among scms),
> it
> > > open the URL itself and resolve it into a(by means of HTML metadata).
> > >
> > > Just distributing the source allowing it to easily updates would be
> > > awesome, since it would allow less effort to create and distribute. Of
> > > course, we could have to limit the scope of what to do to avoid abuse.
> > >
> > >
> > > --
> > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
> > >
> > > On Wed, May 17, 2017 at 1:49 PM, Paul Hammant <p...@hammant.org>
> wrote:
> > >
> > > > There is that, yes. And Git's general upper limits which are subject
> of
> > > "I
> > > > heard of a team that had a corruption at 2GB".  I've field tested Git
> > up
> > > to
> > > > 7GB for a git-svn-clone myself (a team considering saying bye bye to
> > > Svn),
> > > > but wouldn't put that live versus hive off history to a R/O repo, and
> > > start
> > > > over with HEAD of the old becoming the initial commit of the new.
> > > >
> > > > - Paul
> > > >
> > > > On Wed, May 17, 2017 at 2:40 PM, Aldrin Leal <ald...@leal.eng.br>
> > wrote:
> > > >
> > > > > Still, once github gets an outage, our repositories are basically
> > > > > 'left-padded' (taken offline)
> > > > >
> > > > > --
> > > > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
> > > > >
> > > > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <p...@hammant.org>
> > > wrote:
> > > > >
> > > > > > Aldrin - https://github.com/paul-hammant/mc-xs-all - no large
> > files
> > > > > added
> > > > > > to Git. Git makes 70% saving on bytes used ('bare' mode).
> > > > > >
> > > > > > On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <
> ald...@leal.eng.br>
> > > > > wrote:
> > > > > >
> > > > > > > Just a friendly reminder that git is not optimized for large
> > files
> > > > (for
> > > > > > > this, they made git-lfs). Plus, when you do checkout a git
> repo,
> > > > > there's
> > > > > > no
> > > > > > > binary diffs - so if you've got plenty of releases, you'll be
> > > > wasting a
> > > > > > lot
> > > > > > > of space/time in terms of transmission and storage.
> > > > > > >
> > > > > > > --
> > > > > > > -- Aldrin Leal, <ald..

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

And as I'm comfortable advocating for a few Git-centric alternates, GitHub
could be a hosting platform for jars of classes too.  I think I've
established that it is efficient for storing binary classes.

The https://github.com/paul-hammant/mc-xs-classes/releases page on the
mc-xs-classes I did for the blog entry, has downloads of tags. That's all
the classes you'd want and the manifest in a a zip. The trouble is GitHub
made a root directory which will break Java.

So I raised a feature request - https://cloud.githubusercontent.com/assets/
82182/26177670/9d0cc4b8-3b28-11e7-88e1-7e97f727623c.png

Don't worry, I'm 0 for 10 or so.

- Paul

On Wed, May 17, 2017 at 5:37 PM, Paul Hammant <p...@hammant.org> wrote:

> The Maven-using developer community cares that the dependency downloader
> does its think that the uploader/deploy does too. Some new releases of
> those, and some back releases for the hard breaks (if any) going back in
> time - Maven1, Maven2 and whatever.
>
> Works well enough for Homebrew (https://github.com/homebrew - the core
> repo is at 125MB). Sure there's been teething troubles, and Ruby was the
> wrong choice for the DSL versus Python, but it is great really.
>
>
>
> On Wed, May 17, 2017 at 5:25 PM, Manfred Moser <manf...@simpligility.com>
> wrote:
>
>> If you would run Central on git like that in a centralized manner you
>> would have to find someone that does that hosting for you and you would
>> have to get buy in from the community to use that - both extremely hard or
>> impossible.
>>
>> And if you dont do that but instead go with the distributed system you
>> end up with the registry model that I think just doesnt really work in the
>> real world.
>>
>> manfred
>>
>> Paul Hammant wrote on 2017-05-17 13:39:
>>
>> > Actually I'm proposing a predictable structure on 'central :
>> >
>> > g...@central.maven.org:
>> > maven2/<group-name-with-slashes-for-dots.git
>> >
>> > (one minor fix versus previous description of the git:// location)
>> >
>> > Or for the three separate variant:
>> >
>> > g...@central.maven.org:
>> > maven2/<group-name-with-slashes-for-dots-classes.git
>> > g...@central.maven.org:
>> > maven2/<group-name-with-slashes-for-dots-javadocs.git
>> > g...@central.maven.org:
>> > maven2/<group-name-with-slashes-for-dots-sources.git
>> >
>> > More likely though (as you mentioned in your opening line) is the way
>> > homebrew works - you point at repos elsewhere, but control poms/shas
>> etc on
>> > 'central.
>> >
>> >
>> >
>> >
>> > On Wed, May 17, 2017 at 3:59 PM, Manfred Moser <
>> manf...@simpligility.com>
>> > wrote:
>> >
>> >> Having worked with repository managers and the implementation for
>> various
>> >> formats on Nexus for years I think such a format is a bit like Bower.
>> It is
>> >> a registry format that in turn points to git repositories that have the
>> >> content.
>> >>
>> >> From a corporate usage and implementation point of view this is a utter
>> >> nightmare since you would have to open up your systems to all those
>> >> different repositories and sites hosting them instead of just one.
>> >>
>> >> You also cant simply make a copy of the content or analyze it in the
>> way
>> >> it manifests as binaries.
>> >>
>> >> I am not sure what you are looking for as benefits but from my point of
>> >> view this is maybe a fun experiment but not something that will ever
>> take
>> >> off..
>> >>
>> >> Manfred
>> >>
>> >> -
>> >> 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: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

The Maven-using developer community cares that the dependency downloader
does its think that the uploader/deploy does too. Some new releases of
those, and some back releases for the hard breaks (if any) going back in
time - Maven1, Maven2 and whatever.

Works well enough for Homebrew (https://github.com/homebrew - the core repo
is at 125MB). Sure there's been teething troubles, and Ruby was the wrong
choice for the DSL versus Python, but it is great really.



On Wed, May 17, 2017 at 5:25 PM, Manfred Moser <manf...@simpligility.com>
wrote:

> If you would run Central on git like that in a centralized manner you
> would have to find someone that does that hosting for you and you would
> have to get buy in from the community to use that - both extremely hard or
> impossible.
>
> And if you dont do that but instead go with the distributed system you end
> up with the registry model that I think just doesnt really work in the real
> world.
>
> manfred
>
> Paul Hammant wrote on 2017-05-17 13:39:
>
> > Actually I'm proposing a predictable structure on 'central :
> >
> > g...@central.maven.org:
> > maven2/<group-name-with-slashes-for-dots.git
> >
> > (one minor fix versus previous description of the git:// location)
> >
> > Or for the three separate variant:
> >
> > g...@central.maven.org:
> > maven2/<group-name-with-slashes-for-dots-classes.git
> > g...@central.maven.org:
> > maven2/<group-name-with-slashes-for-dots-javadocs.git
> > g...@central.maven.org:
> > maven2/<group-name-with-slashes-for-dots-sources.git
> >
> > More likely though (as you mentioned in your opening line) is the way
> > homebrew works - you point at repos elsewhere, but control poms/shas etc
> on
> > 'central.
> >
> >
> >
> >
> > On Wed, May 17, 2017 at 3:59 PM, Manfred Moser <manf...@simpligility.com
> >
> > wrote:
> >
> >> Having worked with repository managers and the implementation for
> various
> >> formats on Nexus for years I think such a format is a bit like Bower.
> It is
> >> a registry format that in turn points to git repositories that have the
> >> content.
> >>
> >> From a corporate usage and implementation point of view this is a utter
> >> nightmare since you would have to open up your systems to all those
> >> different repositories and sites hosting them instead of just one.
> >>
> >> You also cant simply make a copy of the content or analyze it in the way
> >> it manifests as binaries.
> >>
> >> I am not sure what you are looking for as benefits but from my point of
> >> view this is maybe a fun experiment but not something that will ever
> take
> >> off..
> >>
> >> Manfred
> >>
> >> -
> >> 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: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

Actually I'm proposing a predictable structure on 'central :

 g...@central.maven.org:
maven2/
wrote:

> Having worked with repository managers and the implementation for various
> formats on Nexus for years I think such a format is a bit like Bower. It is
> a registry format that in turn points to git repositories that have the
> content.
>
> From a corporate usage and implementation point of view this is a utter
> nightmare since you would have to open up your systems to all those
> different repositories and sites hosting them instead of just one.
>
> You also cant simply make a copy of the content or analyze it in the way
> it manifests as binaries.
>
> I am not sure what you are looking for as benefits but from my point of
> view this is maybe a fun experiment but not something that will ever take
> off..
>
> Manfred
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven-monitor still in use?

[Paul Hammant]

 Hervé,

Maven Monitor was a Maven 2 artifact [1]
> It was dropped in Maven 3 "as an artifact": code was moved to maven-core
> during the Great Refactoring (TM) [2]
>
>
Thanks - it's a total red herring to chase that component then.


> Then you'll see that EventMonitor has been deprecated, in favor of
> EventSpy in
> Maven 3.0.2 I think: we should probably improve the javadoc...
>
>
Thanks that's exactly what I wanted -
https://github.com/sandipchitale/maven-profiler being what I'll clone and
play with to bring myself up to speed.

- Paul

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

>
> I'm not sure I'm not mistaken for the read part: with the current repo
> format,
> one thing that is super easy is that each artifact version is just a path
> that
> you can use simultaneously in one build or in multiple builds
>

e.g.

build #1 using --classpath ~/.m2/repo/tw/xstream-1.4.3.jar
build #2 (concurrent or soon after) using --classpath
~/.m2/repo/tw/xstream-1.4.4.jar
other builds using one of those two (again) or more, concurrently or not.

Got it.


> With the proposed git repos, I don't get how read access to a tag is done
> without changing disk state, so you can access mutliple tags at the same
> time.
>

Without a *fanciful* change to java and javac, the toolchain is stilll
going to need to make
jars as we've always known them.

The toolchain for recreating jars (notwithstanding timestamps on class
files issues previously noted) from the blog entry:

git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 --branch
1.4.3
cd mc-xs-classes
rm -rf .git
jar cvfM ../xstream-1.4.3.jar .
cd ..
rm -rf mc-xs-classes

That might be faster for Java and the widely used JGit if it can be done in
memory. It took 3 secs for me, with 2 of that being the jar step.

On a development workstation, that style of use *exclusively* will mean you
can rebuild ~/.m2/repository as we know it today, jar by jar.
Specifically, you don't retain the jar .git folders per repo for things
pulled from from 'central at all.

Other people, optionally, could say then want to host their own .git/
centric cache of things pulled down from 'central.  That could be on a
network mount somehow, or (more realistically) an anemic Artifactory of
Nexus service. That could even be on their own box rather than for the
team, of they are happy to momentarily use *more* hard drive space than the
~/.m2/repository of today.

I think if had a local .git representation of things from 'central, I would
be deleting ~/.m2/repository every night when I wasn't using the machine. I
mean, in lieu of a more sophisticated solution.

Regards,

- Paul


>
>
> This "on read" question happens with "on write": but as you told the idea
> is
> more to consume releases from a central repository, and not on the desktop
> with SNAPSHOTs and so on, the write question is not really a question.
>
> Regards,
>
> Hervé
>
> >
> > - Paul
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

You know, I think it would be cool if there were file systems that would
implement a form of a 'link' as part of a content-based-storage mechanism
like Git itself.  Meaning if I ran the above git-clone/jar command twice in
two different directories it would only store the result once (assuming
idempotence).  Hard and soft links are not it because they need a canonical
version that the duplicates point to.  What you want is the thing stored
once, and regardless of the order of deletion, the last deletion means it
is truly gone.  The Mac's 'alias' feature is closer because it allows you
to at least move the original/canonical.

Kind of like String.intern(..) in Java.

People are, of course, pushing the file system science in the direction of
content-based (with dire/filenames a logical overlay).

https://dev.arvados.org/projects/arvados/wiki/Keep
https://github.com/ipfs/ipfs
https://en.wikipedia.org/wiki/Content-addressable_storage


- paul

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

Of course that content-based-storage system isn't a whole FS. That'll take
us back to where we were with some of the ClearCase modes of operaton where
all IO slowed down.  Or worse -  PVCS Dimensions in regular use. It's just
for read only pieces of our build-centric world.

-ph

On Thu, May 18, 2017 at 6:11 AM, Paul Hammant <p...@hammant.org> wrote:

> You know, I think it would be cool if there were file systems that would
> implement a form of a 'link' as part of a content-based-storage mechanism
> like Git itself.  Meaning if I ran the above git-clone/jar command twice in
> two different directories it would only store the result once (assuming
> idempotence).  Hard and soft links are not it because they need a canonical
> version that the duplicates point to.  What you want is the thing stored
> once, and regardless of the order of deletion, the last deletion means it
> is truly gone.  The Mac's 'alias' feature is closer because it allows you
> to at least move the original/canonical.
>
> Kind of like String.intern(..) in Java.
>
> People are, of course, pushing the file system science in the direction of
> content-based (with dire/filenames a logical overlay).
>
> https://dev.arvados.org/projects/arvados/wiki/Keep
> https://github.com/ipfs/ipfs
> https://en.wikipedia.org/wiki/Content-addressable_storage
>
>
> - paul
>

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

We can agree to differ on what I'm suggesting and what the impact of that
would be :)

On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu> wrote:

> Even more than redefining what Central does, you're effectively describing
> a new, unofficial java class packaging and distribution mechanism. This
> seems like it will violate signatures etc and make tracking of what you
> actually have a nightmare.
>
> On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> wrote:
>
> > this idea of putting everything in git is funny: not sure this will go
> very
> > far from this poc, but let's imagine...
> >
> > on classes branch, splitting the jar into individual .class has IMHO a
> big
> > drawback: we loose original jar and its signature
> >
> > On the other branches, the current poc shows commits for versions that
> are
> > perfectly linear: if there are multiple branches that are released in
> > parallel, the commit won't be so clean. I don't know if this will have an
> > impact on compression efficiency.
> >
> > Another issue with this idea: during development, with SNAPSHOTs, the git
> > repo
> > will be polluted: this idea IMHO could only be valid for releases
> >
> > not to speak about read concurrency when one requires to use multiple
> > versions
> > of a lib. And of course, write concurrency is even harder.
> >
> >
> > Definitely, the idea is funny, but I don't see how this could go very far
> > than
> > this funny idea (in addition to the complexity for implementing this
> > format in
> > tooling)
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 15 mai 2017, 21:45:00 CEST Paul Hammant a écrit :
> > > One more repo:
> > >
> > > https://github.com/paul-hammant/mc-xs-all/
> > >
> > > One branch for each of classes, javadoc, sources, and poms
> > >
> > > 15 javadoc original versions: 24.1M
> > >
> > > 16 sources original versions: 4.9M
> > >
> > > 27 classes original versions: 8.4M
> > >
> > > Afterwards git work the bare .git folder is: 8.4M
> > >
> > > *77.5% saving on storage*
> > >
> > > Any artifact, *including the poms,* can be pulled down via a single git
> > > command
> > >
> > > git clone https://github.com/paul-hammant/mc-xs-classes --depth 1
> > --branch
> > > TAGNAME
> > >
> > > 74 TAGNAMEs: classes-0.1, classes-0.2, classes-0.3, classes-0.5,
> > > classes-0.6, classes-1.0, classes-1.0.1, classes-1.0.2, classes-1.1,
> > > classes-1.1.1, classes-1.1.2, classes-1.1.3, classes-1.2,
> classes-1.2.1,
> > > classes-1.2.2, classes-1.3, classes-1.3.1, classes-1.4, classes-1.4.1,
> > > classes-1.4.2, classes-1.4.3, classes-1.4.4, classes-1.4.5,
> > classes-1.4.6,
> > > classes-1.4.7, classes-1.4.8, classes-1.4.9, javadoc-1.2,
> javadoc-1.2.1,
> > > javadoc-1.2.2, javadoc-1.3, javadoc-1.3.1, javadoc-1.4, javadoc-1.4.1,
> > > javadoc-1.4.2, javadoc-1.4.3, javadoc-1.4.4, javadoc-1.4.5,
> > javadoc-1.4.6,
> > > javadoc-1.4.7, javadoc-1.4.8, javadoc-1.4.9, pom-1.2, pom-1.2.1,
> > pom-1.2.2,
> > > pom-1.3, pom-1.3.1, pom-1.4, pom-1.4.1, pom-1.4.2, pom-1.4.3,
> pom-1.4.4,
> > > pom-1.4.5, pom-1.4.6, pom-1.4.7, pom-1.4.8, pom-1.4.9, sources-1.1.3,
> > > sources-1.2, sources-1.2.1, sources-1.2.2, sources-1.3, sources-1.3.1,
> > > sources-1.4, sources-1.4.1, sources-1.4.2, sources-1.4.3,
> sources-1.4.4,
> > > sources-1.4.5, sources-1.4.6, sources-1.4.7, sources-1.4.8,
> sources-1.4.9
> > >
> > >  - Paul
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Maven-monitor still in use?

[Paul Hammant]

Given the version spread of Maven-Monitor above (v2.0.5 and v2.0.9 needed
to build v2.2.1) I'd love to get some advice to how to attach breakpoints
in use to see the pertinent methods invoked during a build.  I mean I've
attached breakpoints and then done mvnDebug but the breakpoints are not hit.

I'm trying to work out what a phase listener would look like, and thought
that the closed API to something that participates in the phase traversal
is MavenMonitor.  Advice please?

- Paul

On Fri, May 12, 2017 at 6:01 AM, Paul Hammant <p...@hammant.org> wrote:

> I''m looking to make a build radiator. Something like this -
> https://www.stevefenton.co.uk/wp-content/uploads/2015/07/cruiser.jpg
>
> I don't want to scrape logs to detect maven phase changes, and
> corresponding pass/fail, I want to use a plugin. I think that plugin
> is Maven-monitor
>
> Online documentation for that is here http://maven.apache.org/ref/2.
> 2.1/maven-monitor/ and that doesn't say much, except to direct the user
> to subversion (where the plugin still resides).
>
> In use a few versions can be downloaded* - meaning even if I could make my
> own version of Maven monitor, I would struggle to get it used exclusively
> through the entire 'mvn' invocation.
>
> Advice ?
>
> * e.g.the build for maven-monitor-2.2.1 downloads v2.0.5 AND v2.0.9 of
> itself. Different projects are going to download/use multiple different
> versions of course.
>
> - Paul
>

Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

I was discussing this of the list today, and it may interest people on dev@

https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/

 "Maven Central as multiple Git repositories"

Enjoy,

- Paul

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

One more repo:

https://github.com/paul-hammant/mc-xs-all/

One branch for each of classes, javadoc, sources, and poms

15 javadoc original versions: 24.1M

16 sources original versions: 4.9M

27 classes original versions: 8.4M

Afterwards git work the bare .git folder is: 8.4M

*77.5% saving on storage*

Any artifact, *including the poms,* can be pulled down via a single git
command

git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 --branch
TAGNAME

74 TAGNAMEs: classes-0.1, classes-0.2, classes-0.3, classes-0.5,
classes-0.6, classes-1.0, classes-1.0.1, classes-1.0.2, classes-1.1,
classes-1.1.1, classes-1.1.2, classes-1.1.3, classes-1.2, classes-1.2.1,
classes-1.2.2, classes-1.3, classes-1.3.1, classes-1.4, classes-1.4.1,
classes-1.4.2, classes-1.4.3, classes-1.4.4, classes-1.4.5, classes-1.4.6,
classes-1.4.7, classes-1.4.8, classes-1.4.9, javadoc-1.2, javadoc-1.2.1,
javadoc-1.2.2, javadoc-1.3, javadoc-1.3.1, javadoc-1.4, javadoc-1.4.1,
javadoc-1.4.2, javadoc-1.4.3, javadoc-1.4.4, javadoc-1.4.5, javadoc-1.4.6,
javadoc-1.4.7, javadoc-1.4.8, javadoc-1.4.9, pom-1.2, pom-1.2.1, pom-1.2.2,
pom-1.3, pom-1.3.1, pom-1.4, pom-1.4.1, pom-1.4.2, pom-1.4.3, pom-1.4.4,
pom-1.4.5, pom-1.4.6, pom-1.4.7, pom-1.4.8, pom-1.4.9, sources-1.1.3,
sources-1.2, sources-1.2.1, sources-1.2.2, sources-1.3, sources-1.3.1,
sources-1.4, sources-1.4.1, sources-1.4.2, sources-1.4.3, sources-1.4.4,
sources-1.4.5, sources-1.4.6, sources-1.4.7, sources-1.4.8, sources-1.4.9

 - Paul

Re: Maven release plugin

[Paul Hammant]

Yup. I don't think I understand the problem, and shouldn't comment.

On Sat, Jun 24, 2017 at 4:59 PM, Petar Tahchiev <paranoia...@gmail.com>
wrote:

> Hi Paul,
>
> I think you misunderstood. The [BOM] is a separate project and the
> [PLATFORM] and [DEMO_STORE] are also separate projects, both of which
> declare as their parent the [BOM].
>
> @Robert: I have added the test-case:
> https://github.com/apache/maven-release/pull/18/commits/
> Release-aggregator is exactly what's missing. Is there an issue I can
> subscribe and track?
>
>
> 2017-06-24 14:15 GMT+03:00 Robert Scholte <rfscho...@apache.org>:
>
> > What we're still missing is a release-aggregator, which can release
> > multiple release-roots at once. That would probably be the preferred fix,
> > the suggested patch is just an easy work-around.
> > It is still on my todo-list.
> >
> > Robert
> >
> >
> > On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant <p...@hammant.org>
> wrote:
> >
> > Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
> >> sure if 'BOM' should mean anything to me) that includes only 'platform'
> as
> >> a child module.
> >>
> >>mvn release:prepare -PplatformOnly # etc
> >>
> >> Later when you're ready to do the demo store release, use another (from
> >> root):
> >>
> >>mvn release:prepare -PdemoOnly # etc
> >>
> >> Of course, you man not need to stuff demo in your Artifactory/Nexus/etc
> in
> >> which case just do your deploy fu after an 'install' w/o the release
> >> plugin
> >> involved or that second profile.
> >>
> >> - Paul
> >>
> >>
> >> On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev <paranoia...@gmail.com>
> >> wrote:
> >>
> >> Hey guys,
> >>>
> >>> I'm facing a number of challenges when I release the project at my
> >>> company.
> >>> Here's my setup:
> >>>
> >>> [BOM]
> >>>  /\
> >>>  [PLATFORM]  [DEMO_STORE]
> >>>
> >>> I have a master BOM project which holds all the version as defined
> >>> properties. This BOM is the parent to two other projects - [PLATFORM]
> and
> >>> [DEMO_STORE], The [PLATFORM] is a project with more than 60 modules
> >>> inside,
> >>> and the [DEMO_STORE] is a project that declares those modules as
> >>> dependencies.
> >>>
> >>> Now what I want is to release all three from Jenkins. I can release the
> >>> [BOM] with no problems, then I start release of the [PLATFORM] and all
> >>> of a
> >>> sudden Jenkins blocks because Maven asks me on the command line if I
> want
> >>> to resolve the SNAPSHOT dependencies (remember the parent of the
> >>> [PLATFORM]
> >>> is the [BOM] SNAPSHOT version).
> >>>
> >>> So I created this issue https://issues.apache.org/jira
> >>> /browse/MRELEASE-985
> >>> to be able to specify the [BOM] parent version when I start the release
> >>> of
> >>> [PLATFORM]. I think I also fixed it with this pull-request:
> >>> https://github.com/apache/maven-release/pull/18
> >>>
> >>> Can someone have a look at this pull request and tell me if it is OK?
> >>>
> >>> --
> >>> Regards, Petar!
> >>> Karlovo, Bulgaria.
> >>> ---
> >>> Public PGP Key at:
> >>> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >>>
> >>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

Re: Maven release plugin

[Paul Hammant]

Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
sure if 'BOM' should mean anything to me) that includes only 'platform' as
a child module.

   mvn release:prepare -PplatformOnly # etc

Later when you're ready to do the demo store release, use another (from
root):

   mvn release:prepare -PdemoOnly # etc

Of course, you man not need to stuff demo in your Artifactory/Nexus/etc in
which case just do your deploy fu after an 'install' w/o the release plugin
involved or that second profile.

- Paul


On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev 
wrote:

> Hey guys,
>
> I'm facing a number of challenges when I release the project at my company.
> Here's my setup:
>
> [BOM]
>  /\
>  [PLATFORM]  [DEMO_STORE]
>
> I have a master BOM project which holds all the version as defined
> properties. This BOM is the parent to two other projects - [PLATFORM] and
> [DEMO_STORE], The [PLATFORM] is a project with more than 60 modules inside,
> and the [DEMO_STORE] is a project that declares those modules as
> dependencies.
>
> Now what I want is to release all three from Jenkins. I can release the
> [BOM] with no problems, then I start release of the [PLATFORM] and all of a
> sudden Jenkins blocks because Maven asks me on the command line if I want
> to resolve the SNAPSHOT dependencies (remember the parent of the [PLATFORM]
> is the [BOM] SNAPSHOT version).
>
> So I created this issue https://issues.apache.org/jira/browse/MRELEASE-985
> to be able to specify the [BOM] parent version when I start the release of
> [PLATFORM]. I think I also fixed it with this pull-request:
> https://github.com/apache/maven-release/pull/18
>
> Can someone have a look at this pull request and tell me if it is OK?
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

Re: Migration of remaining plugins to Git

[Paul Hammant]

I think the plugins are descoped for a while.

How about  https://github.com/apache-maven/ ?

Luckily GitHub does 302s just find if things get renamed or moved between
orgs.

- Paul

On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik <bindulbhow...@gmail.com>
wrote:

> Paul,
>
> On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant <p...@hammant.org> wrote:
> > Back from Github's suggestions team: "Currently, we don't have the
> ability
> > to group repos beyond the organization level, but I'll definitely
> consider
> > this a feature request."
>
> Until such time, how about grouping the repositories by name, like
> https://github.com/apache/maven-plugin-
>
> A number of other projects in Apache have done this, for example
> https://git-wip-us.apache.org/repos/asf?a=project_list=
> incubator-predictionio
> or https://gitbox.apache.org/repos/asf?a=project_list=
> incubator-openwhisk
>
> - Bindul
>
> >
> > - Paul
> >
> > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant <p...@hammant.org> wrote:
> >>
> >> 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.
> >>
> >>
> >>
> >> ^ 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 <p...@hammant.org> 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 <p...@hammant.org> 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 <p...@hammant.org>
> >>> > > > > 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
> >>> > > > >

Re: Migration of remaining plugins to Git

[Paul Hammant]

Back from Github's suggestions team: "Currently, we don't have the ability
to group repos beyond the organization level, but I'll definitely consider
this a feature request."

- Paul

On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant <p...@hammant.org> wrote:

> 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 <p...@hammant.org> 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 <p...@hammant.org> 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 <p...@hammant.org>
>> 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:
>> > > > >

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

[Paul Hammant]

The tongue-stickty-outy thing was more about the fact that Maven would be
much better off shifting *all* of is documentation into something where
every page has an edit-this-page link. Even if that took the user to a GH
page, where you have to do a fork before you can edit some markdown to make
a PR, it would still be better than the current documentation structure.
Indeed README.md in root with Github's treatment of that is more powerful
than the classic gen'd ProjectInfo experience (despite the lack of
structure) for the same reason.  IMO.

Here's my maven extension - https://github.com/BuildRadiator/
BuildRadiatorMavenExtension.  No JavaDoc linked to. That's less important
these days given Intellij and Eclipse, and *very* unimportant for an
extension. Issues and Source are associated already, and not needing to be
linked to. I've added a link to 'central.  The Github people *acknowledged*
my suggestion to change to change way releases are done (https://github.com/
BuildRadiator/BuildRadiatorMavenExtension/releases) as there's a JDK
incompatible root folder in those zips, and *optionally* there need not be.
Pic: https://www.screencast.com/t/0Sg70Uqms

- Paul



On Fri, Jun 2, 2017 at 3:03 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Thu 1 Jun 2017 at 18:21, Paul Hammant <p...@hammant.org> wrote:
>
> > So the only one that worked as the -D arg to the maven invocation. I
> > checked the 10K jar into source control to avoid the bootstrap problem,
> and
> > Circle CI does exactly what I'd hope for. Proof being the intended
> result -
> > https://buildradiator.org/r#b7n63m6hcb9sm2ttdn/Build_
> Radiator_DotOrg_Master
> >
> > https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
> needs
> > an update methinks. If only Apache had a wiki :-P
>
>
> cwiki.apache.org has a Maven space
>
>
> >
> > - Paul
> >
> > On Thu, Jun 1, 2017 at 9:22 AM, Paul Hammant <p...@hammant.org> wrote:
> >
> > > OK, thanks.
> > >
> > > I'll kill the /build/extensions element of the pom, and try
> > > .mvn/extensions.xml
> > >
> > > - Paul
> > >
> > > On Thu, Jun 1, 2017 at 7:26 AM, Igor Fedorenko <i...@ifedorenko.com>
> > > wrote:
> > >
> > >> Build extensions are loaded too late to contribute event spies, see
> how
> > >> EventSpyDispatcher makes a copy of spies when it's created. And even
> if
> > >> EventSpyDispatcher didn't make the copy, I think build extensions are
> > >> not in scope to capture all events, i.e. things that happen
> before/after
> > >> individual project builds will not be captures.
> > >>
> > >> What should work is what I call "core extension" [1], which can be
> > >> configured in .mvn/extensions.xml in your project source tree and are
> > >> loaded very early during the build, before Maven core plexus container
> > >> is created.
> > >>
> > >> [1] http://takari.io/book/91-maven-classloading.html
> > >>
> > >> --
> > >> Regards,
> > >> Igor
> > >>
> > >> On Thu, Jun 1, 2017, at 06:22 AM, Paul Hammant wrote:
> > >> > This page:
> > >> > https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
> > >> >
> > >> > My problem: I have an extension that works just fine
> > >> > in ${maven.home}/lib/ext/ isn't activated when I do the all the
> things
> > >> > mentioned in the page.
> > >> >
> > >> > So my extension was copied from one the Takari EventSpy plugins
> > (trimmed
> > >> > down and started over). It all worked just fine, as I say, for the
> > ext/
> > >> > folder.  The I decided to investigate the  element per
> the
> > >> > page
> > >> > above, and now my extension isn't activated.
> > >> >
> > >> > Here's the diff between what worked befoe, and what doesn't work now
> > but
> > >> > dhered to the dvice of the page:
> > >> > https://github.com/BuildRadiator/BuildRadiatorMavenExtension
> > >> /commit/8b75fed6aff40907a482d9037794469eb663c6b3
> > >> >
> > >> > The advice I'd like to leave my users would be to add the following
> to
> > >> > their build (and set some env props - one of which I admit changed
> in
> > >> > that
> > >> > diff, but that's not the problem).
> > >> >
> > >> >   ...
> > >> >   
> > >>

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

[Paul Hammant]

Back to BuildRadator.org - last nights commit made the average time
proportional for each build -
https://buildradiator.org/r#b7n63m6hcb9sm2ttdn/Build_Radiator_DotOrg_Master

Circle CI has a whole bunch of docker setup, and runs " mvn
dependency:go-offline" before it runs the 'mvn package' build. All that
takes a minute and I can't represent that in the in the timeline just yet.
I can't at all with my Maven extension, but do have alternate curl commands
for all build step updates.

Anyway, I don't need to keep this list informed on progress, so maybe this
is the last time I mention it :)

- Paul

On Fri, Jun 2, 2017 at 6:47 AM, Paul Hammant <p...@hammant.org> wrote:

> The tongue-stickty-outy thing was more about the fact that Maven would be
> much better off shifting *all* of is documentation into something where
> every page has an edit-this-page link. Even if that took the user to a GH
> page, where you have to do a fork before you can edit some markdown to make
> a PR, it would still be better than the current documentation structure.
> Indeed README.md in root with Github's treatment of that is more powerful
> than the classic gen'd ProjectInfo experience (despite the lack of
> structure) for the same reason.  IMO.
>
> Here's my maven extension - https://github.com/BuildRadi
> ator/BuildRadiatorMavenExtension.  No JavaDoc linked to. That's less
> important these days given Intellij and Eclipse, and *very* unimportant
> for an extension. Issues and Source are associated already, and not needing
> to be linked to. I've added a link to 'central.  The Github people
> *acknowledged* my suggestion to change to change way releases are done (
> https://github.com/BuildRadiator/BuildRadiatorMavenExtension/releases) as
> there's a JDK incompatible root folder in those zips, and *optionally*
> there need not be. Pic: https://www.screencast.com/t/0Sg70Uqms
>
> - Paul
>
>
>
> On Fri, Jun 2, 2017 at 3:03 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> On Thu 1 Jun 2017 at 18:21, Paul Hammant <p...@hammant.org> wrote:
>>
>> > So the only one that worked as the -D arg to the maven invocation. I
>> > checked the 10K jar into source control to avoid the bootstrap problem,
>> and
>> > Circle CI does exactly what I'd hope for. Proof being the intended
>> result -
>> > https://buildradiator.org/r#b7n63m6hcb9sm2ttdn/Build_Radiato
>> r_DotOrg_Master
>> >
>> > https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>> needs
>> > an update methinks. If only Apache had a wiki :-P
>>
>>
>> cwiki.apache.org has a Maven space
>>
>>
>> >
>> > - Paul
>> >
>> > On Thu, Jun 1, 2017 at 9:22 AM, Paul Hammant <p...@hammant.org> wrote:
>> >
>> > > OK, thanks.
>> > >
>> > > I'll kill the /build/extensions element of the pom, and try
>> > > .mvn/extensions.xml
>> > >
>> > > - Paul
>> > >
>> > > On Thu, Jun 1, 2017 at 7:26 AM, Igor Fedorenko <i...@ifedorenko.com>
>> > > wrote:
>> > >
>> > >> Build extensions are loaded too late to contribute event spies, see
>> how
>> > >> EventSpyDispatcher makes a copy of spies when it's created. And even
>> if
>> > >> EventSpyDispatcher didn't make the copy, I think build extensions are
>> > >> not in scope to capture all events, i.e. things that happen
>> before/after
>> > >> individual project builds will not be captures.
>> > >>
>> > >> What should work is what I call "core extension" [1], which can be
>> > >> configured in .mvn/extensions.xml in your project source tree and are
>> > >> loaded very early during the build, before Maven core plexus
>> container
>> > >> is created.
>> > >>
>> > >> [1] http://takari.io/book/91-maven-classloading.html
>> > >>
>> > >> --
>> > >> Regards,
>> > >> Igor
>> > >>
>> > >> On Thu, Jun 1, 2017, at 06:22 AM, Paul Hammant wrote:
>> > >> > This page:
>> > >> > https://maven.apache.org/examples/maven-3-lifecycle-extensio
>> ns.html
>> > >> >
>> > >> > My problem: I have an extension that works just fine
>> > >> > in ${maven.home}/lib/ext/ isn't activated when I do the all the
>> things
>> > >> > mentioned in the page.
>> > >> >
>> > >> > So my extension was copied fr

Re: Looking for a collaborator to work on an experimental fork of the maven-dependency-plugin

[Paul Hammant]

Hi Plamen,

> Using GitHub as Maven repository?

Yup. At least to have it as a choice.

I'm imagining putting releases for my esoteric, long-tail ideas, on
Github *rather
than littering Maven Central.*  But also allowing Maven/Grade/Ivy projects
to source the deps from there directly.  The publishing binaries to Github
isn't the problem I'm trying to solve - it is the acquisition of deps as
builds needs them.  Want to take this offline ?

- Paul

On Mon, Jun 5, 2017 at 11:14 AM, Plamen Totev <plamen.iv.to...@gmail.com>
wrote:

> Hi,
>
> I think I had a similar idea. Could you please elaborate what you want to
> achieve? Using GitHub as Maven repository?
>
> I was looking at the matter myself. I didn't spend much time so I have only
> basic understanding of the problems involved and how to solve them.
> As far I know there are (even several) Maven plug-ins that allows you to
> publish Maven artifact to GitHub using the Releases API. But I didn't find
> a way to use GitHub Releases as Maven Repository.
>
> In any case I think the Wagon plug-in is the one that provides the
> transport
> and the one that should be extended in order to be able to reprieve
> artifacts from a new service, not the Dependency plug-in.
>
> Regards,
> Plamen Totev
>
> On Jun 4, 2017 14:23, "Paul Hammant" <p...@hammant.org> wrote:
>
> > So I have 27 releases of XStream unzipped and pushed to
> > https://github.com/paul-hammant/mc-xs-classes
> >
> > (8.4M of Jars is now 2.4M of bare .git repo)
> >
> > All the jars are still available - here -
> > https://github.com/paul-hammant/mc-xs-classes/releases
> >
> > Perfect except:
> >
> >
> >1. .zip suffix instead of .jar
> >2. there's a pesky root folder inside the zip, that matches the tag
> name
> >(GitHub's policy I guess for downloads).
> >3. the signatures won't match those for the originals up on 'Central.
> >
> > I want to fork (experimentally) maven-dependency-plugin (it's in
> Subversion
> > now, but the fork should be on GitHub of course), and sprinkle in some
> > https://github.com/zeroturnaround/zt-zip in order to (1) rename the zip
> on
> > download from GitHub, and (2) remove the root folder inside the zip
> without
> > a mechanical unzip/rezip ... then put theresult in ~/.m2/repository/ as
> > normal.
> >
> > There's probably some pom.xml creativity needed too.
> >
> > Any takers?
> >
> > - Paul
> >
>

Is the Maven 3 lifecycle extensions documentation page up to date?

[Paul Hammant]

This page:
https://maven.apache.org/examples/maven-3-lifecycle-extensions.html

My problem: I have an extension that works just fine
in ${maven.home}/lib/ext/ isn't activated when I do the all the things
mentioned in the page.

So my extension was copied from one the Takari EventSpy plugins (trimmed
down and started over). It all worked just fine, as I say, for the ext/
folder.  The I decided to investigate the  element per the page
above, and now my extension isn't activated.

Here's the diff between what worked befoe, and what doesn't work now but
dhered to the dvice of the page:
https://github.com/BuildRadiator/BuildRadiatorMavenExtension/commit/8b75fed6aff40907a482d9037794469eb663c6b3

The advice I'd like to leave my users would be to add the following to
their build (and set some env props - one of which I admit changed in that
diff, but that's not the problem).

  ...
  

  com.paulhammant
  buildradiatorextension
  1.1-SNAPSHOT

  
  ...

^ exception that doesn't do anything.

Worse, if I go back to the old way with the post-diff version (dropping the
jar into ext/) if doesn't work either.

TL;DR - EventSpy I made won't work with /build/extensions element.  Am
questioning the documentation.

Oh, I'm standing up https://buildradiator.org/ for the benefit of all.
Jooby/Java8/Vue.js and a 35 second Maven build including WebDriver tests
(tests in three executions from one compilation).

- Paul

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

[Paul Hammant]

So the only one that worked as the -D arg to the maven invocation. I
checked the 10K jar into source control to avoid the bootstrap problem, and
Circle CI does exactly what I'd hope for. Proof being the intended result -
https://buildradiator.org/r#b7n63m6hcb9sm2ttdn/Build_Radiator_DotOrg_Master

https://maven.apache.org/examples/maven-3-lifecycle-extensions.html needs
an update methinks. If only Apache had a wiki :-P

- Paul

On Thu, Jun 1, 2017 at 9:22 AM, Paul Hammant <p...@hammant.org> wrote:

> OK, thanks.
>
> I'll kill the /build/extensions element of the pom, and try
> .mvn/extensions.xml
>
> - Paul
>
> On Thu, Jun 1, 2017 at 7:26 AM, Igor Fedorenko <i...@ifedorenko.com>
> wrote:
>
>> Build extensions are loaded too late to contribute event spies, see how
>> EventSpyDispatcher makes a copy of spies when it's created. And even if
>> EventSpyDispatcher didn't make the copy, I think build extensions are
>> not in scope to capture all events, i.e. things that happen before/after
>> individual project builds will not be captures.
>>
>> What should work is what I call "core extension" [1], which can be
>> configured in .mvn/extensions.xml in your project source tree and are
>> loaded very early during the build, before Maven core plexus container
>> is created.
>>
>> [1] http://takari.io/book/91-maven-classloading.html
>>
>> --
>> Regards,
>> Igor
>>
>> On Thu, Jun 1, 2017, at 06:22 AM, Paul Hammant wrote:
>> > This page:
>> > https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>> >
>> > My problem: I have an extension that works just fine
>> > in ${maven.home}/lib/ext/ isn't activated when I do the all the things
>> > mentioned in the page.
>> >
>> > So my extension was copied from one the Takari EventSpy plugins (trimmed
>> > down and started over). It all worked just fine, as I say, for the ext/
>> > folder.  The I decided to investigate the  element per the
>> > page
>> > above, and now my extension isn't activated.
>> >
>> > Here's the diff between what worked befoe, and what doesn't work now but
>> > dhered to the dvice of the page:
>> > https://github.com/BuildRadiator/BuildRadiatorMavenExtension
>> /commit/8b75fed6aff40907a482d9037794469eb663c6b3
>> >
>> > The advice I'd like to leave my users would be to add the following to
>> > their build (and set some env props - one of which I admit changed in
>> > that
>> > diff, but that's not the problem).
>> >
>> >   ...
>> >   
>> > 
>> >   com.paulhammant
>> >   buildradiatorextension
>> >   1.1-SNAPSHOT
>> > 
>> >   
>> >   ...
>> >
>> > ^ exception that doesn't do anything.
>> >
>> > Worse, if I go back to the old way with the post-diff version (dropping
>> > the
>> > jar into ext/) if doesn't work either.
>> >
>> > TL;DR - EventSpy I made won't work with /build/extensions element.  Am
>> > questioning the documentation.
>> >
>> > Oh, I'm standing up https://buildradiator.org/ for the benefit of all.
>> > Jooby/Java8/Vue.js and a 35 second Maven build including WebDriver tests
>> > (tests in three executions from one compilation).
>> >
>> > - Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Looking for a collaborator to work on an experimental fork of the maven-dependency-plugin

[Paul Hammant]

So I have 27 releases of XStream unzipped and pushed to
https://github.com/paul-hammant/mc-xs-classes

(8.4M of Jars is now 2.4M of bare .git repo)

All the jars are still available - here -
https://github.com/paul-hammant/mc-xs-classes/releases

Perfect except:


   1. .zip suffix instead of .jar
   2. there's a pesky root folder inside the zip, that matches the tag name
   (GitHub's policy I guess for downloads).
   3. the signatures won't match those for the originals up on 'Central.

I want to fork (experimentally) maven-dependency-plugin (it's in Subversion
now, but the fork should be on GitHub of course), and sprinkle in some
https://github.com/zeroturnaround/zt-zip in order to (1) rename the zip on
download from GitHub, and (2) remove the root folder inside the zip without
a mechanical unzip/rezip ... then put theresult in ~/.m2/repository/ as
normal.

There's probably some pom.xml creativity needed too.

Any takers?

- Paul

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 <p...@hammant.org> 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 additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> --
> Sent from my phone
>

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 <p...@hammant.org> 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 <p...@hammant.org> 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
> > > > >
> > > 

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 <p...@hammant.org> 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 <p...@hammant.org> 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 <p...@hammant.org>
> 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
> > > >

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

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?

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

[Paul Hammant]

OK, thanks.

I'll kill the /build/extensions element of the pom, and try
.mvn/extensions.xml

- Paul

On Thu, Jun 1, 2017 at 7:26 AM, Igor Fedorenko <i...@ifedorenko.com> wrote:

> Build extensions are loaded too late to contribute event spies, see how
> EventSpyDispatcher makes a copy of spies when it's created. And even if
> EventSpyDispatcher didn't make the copy, I think build extensions are
> not in scope to capture all events, i.e. things that happen before/after
> individual project builds will not be captures.
>
> What should work is what I call "core extension" [1], which can be
> configured in .mvn/extensions.xml in your project source tree and are
> loaded very early during the build, before Maven core plexus container
> is created.
>
> [1] http://takari.io/book/91-maven-classloading.html
>
> --
> Regards,
> Igor
>
> On Thu, Jun 1, 2017, at 06:22 AM, Paul Hammant wrote:
> > This page:
> > https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
> >
> > My problem: I have an extension that works just fine
> > in ${maven.home}/lib/ext/ isn't activated when I do the all the things
> > mentioned in the page.
> >
> > So my extension was copied from one the Takari EventSpy plugins (trimmed
> > down and started over). It all worked just fine, as I say, for the ext/
> > folder.  The I decided to investigate the  element per the
> > page
> > above, and now my extension isn't activated.
> >
> > Here's the diff between what worked befoe, and what doesn't work now but
> > dhered to the dvice of the page:
> > https://github.com/BuildRadiator/BuildRadiatorMavenExtension/commit/
> 8b75fed6aff40907a482d9037794469eb663c6b3
> >
> > The advice I'd like to leave my users would be to add the following to
> > their build (and set some env props - one of which I admit changed in
> > that
> > diff, but that's not the problem).
> >
> >   ...
> >   
> > 
> >   com.paulhammant
> >   buildradiatorextension
> >   1.1-SNAPSHOT
> > 
> >   
> >   ...
> >
> > ^ exception that doesn't do anything.
> >
> > Worse, if I go back to the old way with the post-diff version (dropping
> > the
> > jar into ext/) if doesn't work either.
> >
> > TL;DR - EventSpy I made won't work with /build/extensions element.  Am
> > questioning the documentation.
> >
> > Oh, I'm standing up https://buildradiator.org/ for the benefit of all.
> > Jooby/Java8/Vue.js and a 35 second Maven build including WebDriver tests
> > (tests in three executions from one compilation).
> >
> > - Paul
>
> -
> 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]

OK, I tried something new.

*Goal*: all the plugins in one Git repo (less CI jobs to set up - just one
recursive multi-module maven build).
*Constraint*: Plugins must be independently releasable.

*Test:* Take two modules from the Svn repo and check them in to master (the
rest were deleted - test needs two and a parent pom in master).

*Repository*: https://github.com/paul-hammant/ph_testplugins

Of the two modules checked in, maven-changes-plugin is the one I attempted
to release to my com/paulhammant/ group on 'Central. The workflow for the
release of that single module is here
https://github.com/paul-hammant/ph_testplugins/blob/master/CHANGES_PLUGIN_RELEASE_WORKFLOW.md

*Result of Test:* failed, but in a surprising way and at a very late stage

During the release:perform stage the maven tried to push to
https://oss.sonatype.org/content/repositories/snapshots
/com/paulhammant/testplugins-ph-chgs-pi/3.0.0-SNAPSHOT/testplugins-ph-chgs-pi-3.0.0-20170627.234743-1.jar
which is nuts because I'm not trying to push to a SNAPSHOT, I'm trying to
do a proper release of 3.0.0 (of my renamed to an obscure name plugin).

The documentation for the  part of the pom says that it honors the
name of the local branch for the sequence of commits that the release
plugin does. Which is exactly what you'd want. I've already tested it a
dozen times and it does the right thing by way of tags too.  It's only that
SNAPSHOT weirdness during the upload that ends the experiment, and that's a
fairly late stage piece. My plan was to go onto oss.sonatype.org and delete
it from staging so it would ultimately go nowhere.

Barring that bug, this would work for all of the Maven plugins in a single
repo, meaning a lot less permutations for CI, albeit with a longer build
per commit. I don't think that last is a big issue for this proposed
repository.

Any of you could clone the repo I have made, and do the same steps as
CHANGES_PLUGIN_RELEASE_WORKFLOW.md document to get to the same place I got
to (a 401 error from Sonatype's DAV infra). And one of you could tell me
what I did wrong with the setup to encounter that snapshot issue :)

- Paul

Re: Maven Plugin that provides alternative repository

[Paul Hammant]

>
> This should be possible by providing WorkspaceReader implementation -
> @Component( role = WorkspaceReader.class, hint = "ide" )
>
> Note that Maven tries resolution from workspace *before* repositories -
> workspace reader has priority lower than reactor, but higher than remote
> repos known to Maven.

WorkspaceReader functionality is or is not a thing that can be set in
pom.xml files?

Are there any examples in public that use WorkspaceReader in use to
source a dep from outside of maven central (or the projects sibling
modules)?

- Paul

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

Re: Maven 4.0.0

[Paul Hammant]

>
>
>
> >
> > *3. More pluggable dependency resolver:*
> >
>
> I am willing to let this be optional scope for now. May be yanked if too
> risky or not ready in time
>
>
>
I don't see how you can even make it optional without a pom specified way
of saying "not maven central, this way/place instead"

Re: Maven 4.0.0

[Paul Hammant]

To add to scope for Maven 4, IMO:

*1.  tag could have an optional  arg:*


my-team,mycorp
com.thoughtworks.xstream
xstream
1.4.10



In the above, central is not checked at all.  my-team and my-corp are
defined elsewhere.

*2. GAV as a first class thing (optional):*


com.thoughtworks.xstream:xstream:1.4.10


or




For the first time ever people could do simple ack/ag/grep thru source
bases looking for things.

*3. More pluggable dependency resolver:*

I might want alternate places to source JARs from that are *not* HTTP
mounted system that match the Maven2 directory structure.

Like here - https://github.com/paul-hammant/xstream-jar/releases (and
associated blog entry -
https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/)

In particular I need to rework the jar as it is pulled into the local
~/.m2/repository cache - there's a root directory to remove.

- Paul

Re: Code-based exclusions

[Paul Hammant]

An example would be using Hibernate - it has code for MySql, Postgres,
SqlServer, Oracle (etc). In one particular deployment at one particular
time, a so-using compan is pretty sure that it is (say) Postgres for now.
Google do leave out (*exclude*) unused packages/classes from deployments.
At least from third party jars. For in-house stuff their use of Blaze
(Bazel) means that they never *include t*he sub-packages that are not
pertinent to the build target. Blaze is a directed graph build tool.

Shade (and its Maven plugin) is a tool that COULD leave out code that's not
used. How to calculate that for a recursive build tech like Maven?  Why
after test runs and code-coverage maps of course. So someone has to code
that. I for one would welcome it.

Caveat: I left Google in Jan of 2009 -
https://mike-bland.com/2012/07/10/test-mercenaries.html

One more thing - I'm advocating bytecode instrumentation, whereas you were
talking source code parsing. Mine is 100x easier to get perfect - sorry!

- Paul

On Fri, Jun 29, 2018 at 7:59 AM, Neacsu Bogdan  wrote:

> Hello,
>
> Recently, I was thinking at a pretty nice feature that would make the grat
> maven tool an awesome one: code-based exclusions.
> Why should this be needed? Because some libs have dependencies of their
> own, that are not really used by the final code.
> In theory, one should be able to create a maven option, to exclude all the
> imported jars that simply aren't really used in the project.
> This means that maven should be able to have a plugin that parses the
> code, searches in depth what libraries are indeed used by this code (and
> what libraries are used by those libraries etc.), and what are not, and
> should automatically add excludes for the unused ones.
> The only three problems I see with this implementation right now are:-
> obfuscated libs;- signed libs;- libs that use reflections to load classes
> (like spring).
> Does anybody know if this should be possible?
>
> Thanks,Bogdan Neacsu
>



-- 
Paul Hammant DevOps <https://devops.paulhammant.com> Let me give your
enterprise a step by step plan to migrate from GitFlow (or worse) to
high-throughput CD on the essential DevOps foundation: Trunk-Based
Development.

Re: [Proposal] When Old Meets New: Turning Maven into a High Scalable, Resource Efficient, Cloud Ready Microservice

[Paul Hammant]

Related to Incremental - idempotent builds would be good.

Having been exposed to Google's Blaze (now Bazel in OSSland) and directed
graph build system science (as opposed to recursive build systems) there's
a great efficiency from skipping parts of a build that don't need to be
done.

Also related to incremental -
https://github.com/khmarbaise/incremental-module-builder goes some way.  It
doesn't do changes in dep triggering a build (or not), I don't think. It
also can't work out the difference between the heavy phases of a module's
build that are independently skipable (compile, test compile, jar, shade,
etc).

- Paul

Re: RFC: Maven to raise a notification if downloading vulnerable content

[Paul Hammant]

Personally, I think vulnerable packages could be retained locally and was
subscribable. Dealing with it during a build would be a local operation.

Here's a repo of all Maven Meta data (I wrote some stuff in Python and
Herve redid it in Java) -> https://github.com/hboutemy/mcmm-yaml/

While vulnerability info could be woven into that repo with extra
attributes, it might be better that there were a separate repo that listed
vulnerbilities only. That Git repo would have the same structure but be
limited to information around artifacts vulns only, and only the root cause
vulns.

For example CVE-2017-15707 says the REST Plugin for Apache Struts 2.5 to
2.5.14 is vulnerable, but it is really certain versions of JSON-lib that is
vulnerabilities

https://github.com/hboutemy/mcmm-yaml/blob/master/org/apache/struts/struts2-core.yaml
https://github.com/hboutemy/mcmm-yaml/blob/master/net/sf/json-lib/json-lib.yaml

Thus a revised vulnerability plugin would check against the local Git repo
of vulns, AND have an option of doing a git-pull for the repo again of the
determination.

mvn vuln:report
mvn vuln:fail
mvn vuln:report -DupdateVulnDB
mvn vuln:fail -DupdateVulnDB

Being a git repo allows for mirrors. Also, git pull (especially for
--depth=1) is quick.  Interestingly this git repo could operate bare (no
working copy on the local) as you're not going to change the files in an
edit/commit/push cycle

-ph


On Tue, Mar 6, 2018 at 7:12 AM, Peter Muryshkin <murysh...@gmail.com> wrote:

> Hi, all,
>
> currently you can run OWASP dependency check plugin against your projects.
>
> Though, this seems to make security more or less optional: unaware either
> lightheaded teams could miss this.
>
> What if a package repository would integrate with this dependency checking
> and issue a warning, say a special HTTP response code or a header?
>
> Then, Maven would raise the warning in the console log, like "this
> component is known to have CVE-XYZ! consider upgrading"
>
> What do you think?
>



-- 
Paul Hammant DevOps <https://devops.paulhammant.com> Let me give your
enterprise a step by step plan to get out of the hell of crazy branching
models (ClearCase maybe?) and into the world of high-throughput CD on
DevOps foundations.

Re: Speeding up Maven

[Paul Hammant]

Mark,

Assuming a pre-filled Maven local cache, I've a 16 second build that's only
longer when I run a screen recorder in order to make the video show here -
https://paulhammant.com/2017/02/05/a-16-second-java-webapp-build-including-webdriver-tests/

That one runs three WebDriver tests too after the unit and service tests -
meaning (implicitly) it's testing JavaScript as well as Java in that time.

In order to make it fast I've abandoned the fail-safe plugin and do all
parts of the test-pyramid in surefire (see the pom).

- Paul

On Fri, Apr 13, 2018 at 3:20 PM, Mark Raynsford <
org.apache.maven.u...@io7m.com> wrote:

> Hello.
>
> Is there any way I might speed up Maven? I've been using it for years
> and, for the first time, I'm actually executing it from an IDE rather
> than using the IDE's built-in compiler. It seems like there's a rather
> large and apparently fixed amount of overhead per invocation. Take the
> following "could not be simpler" project:
>
>   https://github.com/io7m/maven-minimal-20180413
>
> I piped the output through tai64n [1] to give a better indication of
> exactly how long everything is taking. That's a project that compiles a
> single Java file and produces a jar. It doesn't run any tests, it
> doesn't include any resources. 16 seconds total execution [2]!
>
> Now for an infrequent command-line build, that's not *too* obnoxious.
> For a "click a button in the IDE because I want to try this bit of code
> now" build, that's a world of suffering.
>
> It seems like Maven first spends ten entire seconds doing not very
> much. That cannot be attributed to JVM startup time (Hello World on my
> system takes about 100ms to reach user code, and even the largest Java
> application I still takes less than a second to reach user code after
> all the classes have loaded).
>
> Is there anything I can do to cut this down? If not, is this something
> that's intended to be addressed in the near future?
>
> [1] http://cr.yp.to/daemontools/tai64n.html
> [2] The Maven output claims 6 seconds, but that doesn't include the
> time it took for the build to start.
>
> --
> Mark Raynsford | http://www.io7m.com
>
>


-- 
Paul Hammant DevOps <https://devops.paulhammant.com> Let me give your
enterprise a step by step plan to get out of the hell of crazy branching
models (ClearCase maybe?) and into the world of high-throughput CD on
DevOps foundations.

Re: Speeding up Maven

[Paul Hammant]

Can you yourself try another dissimilar machine?

Re: Help with testing on OS/X 10

[Paul Hammant]

OS/X == OS X (former OS name) == macOS (current OS name) ?

10 == 10.10.x ?

Re: Are snapshots available in some Maven repo?

[Paul Hammant]

Obligatory, "Trunk-Based Development  (with short-lived feature branches if
you like) is best" -
https://trunkbaseddevelopment.com/short-lived-feature-branches/ - *shout
out*.

- Paul (majority author of the above site).

Re: Accessing a maven repository programatically (in 2019)

[Paul Hammant]

There's shades of https://en.wikipedia.org/wiki/XY_problem to what you
posting. I, for one, an interested in what your trying to make after you've
solved this problem :)

Re: Ojdbc7 dependency issue

[Paul Hammant]

Does 'central' need to be immutable though?  Feels like an arbitrary policy
to me. Or should there be workflows to remove items from there, and replace
with a 302?  While that could be to repos elswhere, they could also be to
HTML pages with mvn.exe handling that and communicating that clearly in the
build log.

Some ten years ago a mal-configured WebSense at an airline was flling a
corporate Maven cache jars and poms suffixes that were actually HTML error
pages. Maven choked silently then and I'm not sure it has ever been fixed.
In a quick test now, if I do "ls > ~/.m2/repository/foo/bar/baz.pom" (and
jar), the build fails with a proximate cause message. The jars and poms are
not checked again for correctness once in the cache. Anyway the jar/pom
ingesting side of Maven could easily handle deprecation, obsolesence and
outright deletion better than it does.

Re: Ojdbc7 dependency issue

[Paul Hammant]

It is probably up to Oracle (not Apache) as to what is uploaded into Maven
Central - https://mvnrepository.com/search?q=ojdbc7

It could be that they have decided to not upload artifacts - "Last Release
on Oct 30, 2017" - anymore.

Re: JavaLand

[Paul Hammant]

Make sure there's a slide on speedily processing pull-requests -
https://github.com/apache/maven/pulls - ;-) :-P

On Mon, Mar 18, 2019 at 12:03 PM Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> I would like to please you if you have simple task to do it would be
> great if you could create an appropriate JIRA ticket for it and mark it
> with the label "up-for-grabs".
>
> This would be ideal for contributors as an introduction step into Open
> Source contribution.
>
> I will do a workshop on JavaLand in Brühl (near Cologne) Germany how to
> contribute to Open Source Projects.
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Build DAG traversal.

[Paul Hammant]

The depth first DAG traversal of Maven modules in a build is a great and
under appreciated thing, but sometimes I wish for a different way of
working. Particularly for CI, I'd want to compile everything first, *then*
run tests. Two DAG traversals, if you like. This is possible, like so:

mvn clean install -DskipTests
-Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY
mvn surefire:test -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY

I'm separating out the local maven repo bcause SNAPSHOT items can drop in
on the "install" action, but still later fail tests. And I'd not want other
builds on the same machine to utilize those jars of dubious quality (even
if they are over written a lot).

Question: Anyway, is there a critical (but subtle) goal/phase that's going
to be skipped with this way of working?

- Paul

Re: Build DAG traversal.

[Paul Hammant]

Yeah, maybe that makes sense.

On Thu, Feb 14, 2019 at 1:45 PM Mykola Nikishov  wrote:

> Paul Hammant  writes:
>
> > mvn clean install -DskipTests
> -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY
>
> This would compile and test-compile for the first time...
>
> > mvn surefire:test -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY
>
> Run compile and test-compile one more time, on the same sources, for
> artifacts that had been just installed. Does it make sense to skip them
> with '-Dmaven.main.skip=true -Dmaven.test.skip=true' [1]?
>
> [1]
> https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#skipMain
>
> --
> Mykola
>
> Libre/Free Java Software Engineer
> https://manandbytes.gitlab.io/
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Hacking my own version of Maven that'd forgive missing sub-modules

[Paul Hammant]

Class
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder is
where "Child module  of  does not exist" causes the build
to cease.  I'd like to make that optional for myself for huge-monorepo and
sparse-checkout-coolness reasons.  Is that the best place to make Maven
more forgiving for mussing modules in a multi-module project?

Background:
https://paulhammant.com/2017/02/08/further-experiments-with-expanding-contracting-monorepos/

- Paul

Re: Hacking my own version of Maven that'd forgive missing sub-modules

[Paul Hammant]

Nice, thanks :)

Re: [DISCUSS] configuration for Reproducible Builds

[Paul Hammant]

Hunter wrote:

 What if that timestamp was based upon the scm's last commit timestamp
> instead of the time of the build?
>

Folks: remember that Subversion works differently to Git. With subversion
there's no hash, just an integer that goes up constantly for everything in
the larger repo. Your trunk/master/release-branch may not have changed in
10 mins, but the repo might have done for an unrelated project/dir.

You're best to make a merkle tree for all files in the checkout (ignoring
target/). You can do that with Subversion too of course even though it does
not itself maintain a Merkle tree of the current set of files nor the
history (as Git goes).  Full disclosure - I am obsessed with Merkle trees
(but not blockchain).

Re: Next Generation Integration Testing for Plugins/Core

[Paul Hammant]

Integration test choices include the excellent Spock as mentioned. I've
used it and it's very solid. Two more choices include:

Another choice is Cuppa - https://github.com/cuppa-framework/cuppa
I've used this too, and it's great - no right-click-run-this-one in
Intellij though. I wish it had more forward momentum, and I'd use the heck
out of it if it did.

Also, there is a segmented use of otherwise *vanilla surefire*:
https://github.com/BuildRadiator/BuildRadiator/blob/master/radiator/pom.xml#L158
is an example.

In that pom, there's three executions of surefire. First unit tests (no
threads, no IO, no FS), Second a few service tests (RestAssured poking a
per-test stood up Jooby web app), Third are a few WebDriver tests with the
same per-test bounce of the Jooby server.

When I first made the above, I made a quick build that shows it all
running. If target/classes/ is full already "mcn install" was 16 seconds
(compile and all three of those test stages). On my old MacBookAir with the
video recorder on, that slowed to 30s. then I refactored it to multi-module
and it is longer still. I'm still pleased with the 16s version though and
roll back the repo to demo that when needed.

I'm quite sure I'll never use Failsafe again.

Re: Next Generation Integration Testing for Plugins/Core

[Paul Hammant]

Oops. Blog entry linking to video of 16s build -
https://paulhammant.com/2017/02/05/a-16-second-java-webapp-build-including-webdriver-tests/

Re: Did you see dependabot?

[Paul Hammant]

Summary ?

Re: Did you see dependabot?

[Paul Hammant]

Here's an interesting co-incidence. A chg I donated to Google's Cloud bits
and pieces -
https://github.com/GoogleCloudPlatform/google-cloud-datastore/pull/205/files
*required
and received* a CLA.

@elharo just marked it as not needed, which is quite correct as this lib
has been succeeded by something else.  *Humans quality controlling bot
actions :)*

Re: Did you see dependabot?

[Paul Hammant]

I think you agree that the thesis has no bearing on the actions that
Dependabot recommends.

Worked Dependabot example
https://github.com/jbehave/jbehave-tutorial/pull/19/files (I consumed this
one for the JBehave team).

^ That was not copyrightable. It is not *original expression*, if it was
and Dependabot beat me to an upgrade, and did not also grant me a copyright
for the same, I would be legally prevented from effecting the same upgrade
be retyping the same two-character change. Patch upgrades like this are in
the "obvious" and "could not be done any other way" that are decades old as
considered dilemmas and well and truly answered in law. The alternative
would be skip 1.4.6 as an upgrade and wait for 1.4.7 - hoping to beat
dependabot to the punch??



On Tue, Oct 29, 2019 at 4:19 PM Martijn Dashorst 
wrote:

> The conclusion of the paper itself is 3 pages (no paragraphs, so it
> might be written by an AI ;-).
>
> - Dutch (and international) copyright law don't require a copyright
> holder to be human
> - so the work itself needs to be evaluated, two criteria that factor
> into this; requirement of reflecting an original expression and the
> carrying of a personal imprint
> - original expression is feasible for AIs (according to author)
>
> The author lost me at the reasoning for "personal imprint".
>
> Martijn
>
> On Tue, Oct 29, 2019 at 11:18 AM Paul Hammant  wrote:
> >
> > Summary ?
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Did you see dependabot?

[Paul Hammant]

Pretty sure that small changes that could not be done any other way are not
subject to copyright claims.

s/1.199/1.200/g

^ Being an example.

On Sat, Oct 19, 2019 at 7:51 PM Enrico Olivelli  wrote:

> I see value in it.
> But from a legal point of viewthere is no human who sends the PR, so in
> theory we cannot accept such patches, can we?
>
> Enrico
>
> Il sab 19 ott 2019, 20:26 Tibor Digana  ha
> scritto:
>
> > The dependabot looks interesting, cli has more possibilities than a pure
> > button on GUI.
> > >> does anyone enabled it
> > I am all the ear how it can be enabled.
> >
> > On Fri, Oct 18, 2019 at 3:32 PM Enrico Olivelli 
> > wrote:
> >
> > > Hey guys,
> > > Did you see dependabot on our repos?
> > >
> > > Like this automatic PR
> > >
> > >
> >
> https://github.com/apache/maven-plugins/pull/147#pullrequestreview-303889692
> > >
> > > I feel this is very useful, but... does anyone enabled it?
> > >
> > > Do we have to set a policy, this suggestions are security related
> fixes,
> > we
> > > could give them some kind of high priority?
> > >
> > > Enrico
> > >
> >
>

Re: Suggestions for improvements of current maven version

[Paul Hammant]

Without breaking backwards compatibility, it could be a choice for the Pom.
Sure that’s an addition, but it it not like the format can never change.
It’s an excellent idea.

On Thu, Nov 28, 2019 at 5:28 PM Robert Scholte  wrote:

> As mentioned by Elliotte this won't fit in the current pom model version.
> And it will effect dependency resolution. The current order of
> dependencies in the pom reflects the order on the classpath.
> As long as there are no duplicate classes you should be fine, but the real
> world shows us differently.
> So with any proposal to regroup dependencies, people should be able to
> control the final order.
>
> thanks,
> Robert
> On 28-11-2019 14:14:49, Elliotte Rusty Harold  wrote:
> It's not a bad idea if we were starting from a green field. I'm not
> sure how the broader community would feel about changing the structure
> of the pom.xml file at this point. These things are very broadly used,
> and my gut is that the small improvement would not justify the pain of
> the transition.
>
> On Wed, Nov 27, 2019 at 5:37 PM diku gabriell
> wrote:
> >
> > Hello,
> >
> > My name is Gabriel Dicu.I am currently working with apache maven and I’d
> like to make a suggestion about improving maven dependency structure.In my
> opinion, dependencies should be organized better, because is difficult to
> spot dependencies for different scopes.I think it is a good approach to
> group dependencies by their scopes, thus having parent tags for each scope
> like:
> >
> >
> >
> > …
> > …
> > …
> >
> >
> >
> >
> >
> > …
> > …
> > …
> >
> >
> >
> >
> > …
> > …
> > …
> >
> >
> >
> >
> > In this way you can organize better the dependencies and spot easily the
> different scopes.It also can help identify the runtime/compile/etc..
> production dependencies and separate them from testing ones, which can be
> less important in many cases.
> >
> > Thanks for taking the time for reading this, and if this approach can be
> feasible,
> > I can be reached at the following email address dikugabri...@yahoo.com
> for more details.
> >
> > Sent from Mail for Windows 10
> >
>
>
> --
> 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: Suggestions for improvements of current maven version

[Paul Hammant]

Great suggestion

On Wed, Nov 27, 2019 at 10:37 PM diku gabriell
 wrote:

> Hello,
>
> My name is Gabriel Dicu.I am currently working with apache maven and I’d
> like to make a suggestion about improving maven dependency structure.In my
> opinion, dependencies should be organized better, because is difficult to
> spot dependencies for different scopes.I think it is a good approach to
> group dependencies by their scopes, thus having parent tags for each scope
> like:
> 
> 
>
> …
> …
> …
>
> 
> 
> 
> 
> …
> …
> …
>
> 
> 
> 
> …
> …
> …
>
>  
> 
>
> In this way you can organize better the dependencies and spot easily the
> different scopes.It also can help identify the runtime/compile/etc..
> production dependencies and separate them from testing ones, which can be
> less important in many cases.
>
> Thanks for taking the time for reading this, and if this approach can be
> feasible,
> I can be reached at the following email address dikugabri...@yahoo.com
> for more details.
>
> Sent from Mail for Windows 10
>
>

Re: [DISCUSS] Maven 3.7.0

[Paul Hammant]

Would jdk 8 for maven itself and a target of 7 for the compiler (etc) for
maven-using projects be ok?

On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold 
wrote:

> Strong -1 on Java 8 as the minimum version. Google Cloud Platform has
> lots of products and customers that still require Java 7. If Maven
> requires Java 8, we'd have to stick to the latest of whichever release
> does support Java 7 for at least a year and I'm guessing longer.
>
> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte 
> wrote:
> >
> > Hi,
> >
> > TLDR; introduce maven.experimental.buildconsumer and push Java
> requirement
> > to Java 8
> >
> > now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> didn't
> > face real regressions.
> > The only one might be tricky is the issue related to Tycho.
> >
> > However, I think we're ready to push Maven to the next level.
> >
> > For those actively reading this list, they should recognize the need for
> > splitting up the pom as it is on the local system versus the pom being
> > uploaded. Once we truly control this mechanism we can think of
> > improvements on model 5.0.0 and new fileformats.
> >
> > I've created and implemented MNG-6656[1]. It also contains a zip with an
> > example (original, patched, README) to understand what's happening.
> >
> > In order to make this successful, we need IDEs and CI Servers to
> > understand and support these changes. The likely need to implement one of
> > the interfaces[2].
> > The new interface uses Java8 Functions (and especially SAXEventFactory is
> > way easier to read+maintain with Java 8). I've tried to keep Maven Java 7
> > compatible, but that was too hard to do.
> > So I'd like to use this opportunity to move Maven forward and start
> > requiring Java 8.
> >
> > There are some other improvements I'd like to add (those messages will
> > follow), so this will imply that it will take some time before we do a
> new
> > release.
> >
> > WDTY,
> > Robert
> >
> > [1] https://issues.apache.org/jira/browse/MNG-6656
> > [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
> >
> > -
> > 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: [DISCUSS] Maven 3.7.0

[Paul Hammant]

Who codes for 18 months before discovering that qa/prod are not compatible,
anymore? Especially if Google ship a use-this-Pom starter.

On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold 
wrote:

> Theoretically that would work. In practice though, every project I've
> seen convert to Java 8 rapidly starts adding lambdas that make the
> code more obfuscated for no good reason and soon introduces hard
> dependencies on Java 8, intentionally or otherwise. At a bare minimum,
> a CI environment that runs Java 7 is required.
>
> On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant  wrote:
> >
> > Would jdk 8 for maven itself and a target of 7 for the compiler (etc) for
> > maven-using projects be ok?
> >
> > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold  >
> > wrote:
> >
> > > Strong -1 on Java 8 as the minimum version. Google Cloud Platform has
> > > lots of products and customers that still require Java 7. If Maven
> > > requires Java 8, we'd have to stick to the latest of whichever release
> > > does support Java 7 for at least a year and I'm guessing longer.
> > >
> > > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > TLDR; introduce maven.experimental.buildconsumer and push Java
> > > requirement
> > > > to Java 8
> > > >
> > > > now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> > > didn't
> > > > face real regressions.
> > > > The only one might be tricky is the issue related to Tycho.
> > > >
> > > > However, I think we're ready to push Maven to the next level.
> > > >
> > > > For those actively reading this list, they should recognize the need
> for
> > > > splitting up the pom as it is on the local system versus the pom
> being
> > > > uploaded. Once we truly control this mechanism we can think of
> > > > improvements on model 5.0.0 and new fileformats.
> > > >
> > > > I've created and implemented MNG-6656[1]. It also contains a zip
> with an
> > > > example (original, patched, README) to understand what's happening.
> > > >
> > > > In order to make this successful, we need IDEs and CI Servers to
> > > > understand and support these changes. The likely need to implement
> one of
> > > > the interfaces[2].
> > > > The new interface uses Java8 Functions (and especially
> SAXEventFactory is
> > > > way easier to read+maintain with Java 8). I've tried to keep Maven
> Java 7
> > > > compatible, but that was too hard to do.
> > > > So I'd like to use this opportunity to move Maven forward and start
> > > > requiring Java 8.
> > > >
> > > > There are some other improvements I'd like to add (those messages
> will
> > > > follow), so this will imply that it will take some time before we do
> a
> > > new
> > > > release.
> > > >
> > > > WDTY,
> > > > Robert
> > > >
> > > > [1] https://issues.apache.org/jira/browse/MNG-6656
> > > > [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
> > > >
> > > > -
> > > > 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
> > >
> > >
>
>
>
> --
> 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: Maven feature request

[Paul Hammant]

Selenium co-creator here (albeit v1),

WebElement is pubic API and not impl-detail.  If you're making a library
for downstream *testing* teams to use, then selenium-java jumps from
test-scope to prod-scope of course and is now a transitive dep. Many
build/test tools makers are in the same place for "what is our prod code vs
test code".

And in that we-ship-a-lib-that-uses-selenium space, then perhaps there
you're wanting to wrap WebElement. I do so for FluentSelenium -
https://github.com/SeleniumHQ/fluent-selenium/blob/master/java/src/main/java/org/seleniumhq/selenium/fluent/FluentWebElement.java
- but even then I make a getWebElement() for situations where they *really
frickin want to*.

If not a we-ship-a-lib-that-uses-selenium case, then I'm not following -
Selenium is classically a test-scoped thing.

If you're worried about hacker teams quietly promoting selenium-java from
test-scope to no-scope and then those jars quietly being zipped into the
(say) WAR file that heads to production, just use mvn-dependency:tree and
python to discover that's happened, or unzip the uber/shade jar to look for
verbotten classes, and then fail the CI build.



On Thu, Jan 23, 2020 at 11:00 PM Scott Wilson  wrote:

> Hi Paul
>
> I write test automation and try to stick to a solid design. I find others
> break solid design principles so having a  scope will prevent people
> from breaking some basic principles.
>
> For example, if using Selenium I've seen multiple people expose WebElement
> in a public method (that should be a private implementation detail). This
> is just an example of horrible implementation I've seen multiple people do
> without thinking. The new  scope will not prevent that however it
> will prevent the following.
>
> I've seen people create src/tst/java/helloworld/MyTest.java which accesses
> a WebElement directly in their Junit / TestNG class. The new  scope
> will prevent stuff like that from happening. What they should really do is
> create src/main/java/helloworld/MyPage.java which implements the
> functionality using WebElement, then get an instance of MyPage from their
> src/tst/java/helloworld/MyTest.java.
>
> That is just one obvious example but I've seen other poor implementations
> using other dependencies which are as obvious what is good vs bad design
> unless this principle is understood.
>
> Scott
>
>
>
> On Wed, Jan 22, 2020 at 11:43 PM Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> > On 23.01.20 00:59, Scott Wilson wrote:
> > > *Hi Robert and devs*
> > >
> > >
> > > *I have been using maven for a few years and I LOVE it!*
> > >
> > >
> > > *I have a feature request.*
> > >
> > >
> > > *(1) When adding a dependency to pom.xml the default scope is
> everywhere*
> > >
> > > *ie src/main/java/*
> > >
> > > *and src/tst/java/...*
> > >
> > >
> > > *(2) When adding  as the scope then the dependency can ONLY be
> used
> > > under src/tst/java...*
> > >
> > > *If referencing the dependency in src/main/java/... then it will not
> > > compile* >
> > >
> > > *(3) My feature request:*
> > >
> > > *I want the exact opposite. I'd like a new scope called *
> > >
> > > *If the scope is  then the dependency can ONLY be used under
> > > src/main/java/...*
> > >
> > > *If referencing the dependency in tst/main/java/ then it will not
> > > compile*
> >
> > This would result in the problem that you neever can run / compile your
> > unit- and integration tests cause something is missing on the classpath
> > so in result your project would be unusable...
> >
> >
> >
> > >
> > >
> > > *I read up on scopes
> > > (**
> >
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> > > <
> >
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> > >)
> > > *and
> > > AFAIK this is not currently supported, but I have a specific reason for
> > > wanting this.
> >
> > It would be great if you could shared this with us
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> > >
> > >
> > > *I'd really appreciate if someone can add that for me and let me know
> > when
> > > it's done.*
> > >
> > > *Please let me know if you have any questions.*
> > >
> > >
> > > *Regards*
> > >
> > > *Scott Wilson*
> > >
> > > *http://linkedin.com/in/hockeyeh *
> > >
> >
>

Re: Maven feature request

[Paul Hammant]

I'm interested in your need for this. Like, why do you need this?

On Thu, Jan 23, 2020 at 7:17 AM Scott Wilson  wrote:

> *Hi Robert and devs*
>
>
> *I have been using maven for a few years and I LOVE it!*
>
>
> *I have a feature request.*
>
>
> *(1) When adding a dependency to pom.xml the default scope is everywhere*
>
> *ie src/main/java/*
>
> *and src/tst/java/...*
>
>
> *(2) When adding  as the scope then the dependency can ONLY be used
> under src/tst/java...*
>
> *If referencing the dependency in src/main/java/... then it will not
> compile*
>
>
> *(3) My feature request:*
>
> *I want the exact opposite. I'd like a new scope called *
>
> *If the scope is  then the dependency can ONLY be used under
> src/main/java/...*
>
> *If referencing the dependency in tst/main/java/ then it will not
> compile*
>
>
> *I read up on scopes
> (**
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> <
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> >)
> *and
> AFAIK this is not currently supported, but I have a specific reason for
> wanting this.
>
>
> *I'd really appreciate if someone can add that for me and let me know when
> it's done.*
>
> *Please let me know if you have any questions.*
>
>
> *Regards*
>
> *Scott Wilson*
>
> *http://linkedin.com/in/hockeyeh *
>

Re: Abandoned project

[Paul Hammant]

https://github.com/mojohaus/buildnumber-maven-plugin has been worked on
*since* Codehaus closed up. Ask these people -
https://github.com/mojohaus/buildnumber-maven-plugin/commits/master - what
their intentions are.

Re: is it legal to shade "gson" packages in Maven?

[Paul Hammant]

Shade has option exclude rules if you wanted to slim down that side of it,
and still stick with Jackson.

Shading itself should alter the should or shouldn't aspect of
library/package linkage within a app/lib/service/plugin/solution. You're
guided by imports in Java-land - Apache license stuff can't import GPL2 and
still be adhering. And others. "What is linkage" is primarily import with
Java, but there are other ways linkage can be set up and still entangled in
license considerations/debates.

- Paul

Re: [DISCUSS] Merging small plugins

[Paul Hammant]

> We have tens of plugins, most of them are rarely updated and released

... is the key problem you're trying to solve right?

Team to actively process issues and PRs and push releases minor releases
efficiently is the real wish, right?

Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?

[Paul Hammant]

Relates to Trunk-Based Development (I maintain
https://trunkbaseddevelopment.com) . Some of my clients do "branch for
release". Every cherry pick from trunk to the release branch (bug fix)
would wake up Jenkins. By default that'd do a full build and then artifacts
get pushed into artifactory/nexus and from there a deployment into UAT -
bouncing whichever services have been changed.

The build pass/fail gate will fail though, *if* the versions (in the POMs)
have been published already - Nexus/Artifactory will  correctly object.
What I want to do is effect a system that *only the changed modules *will
be blocked on a second publication attempt. Unchanged ones will be skipped
for publication. Say there were 100 modules (services, applications, their
deps) that the build would compile/test. If there were a bug fix to just
one module, I would want Jenkins to note the failing publication attempt
for that one only.  If builds are reproducible (hard for Maven I realize *)
then the SHA-1 of the binary can guide whether it needs to go to the
remote repo or be skipped. The pseudocode covers that. The release engineer
would then change *one* POM version (say 4.3.0 to 4.3.1) in the release
branch, commit, Jenkins is triggered, full build - but only one changed
item gets pushed up to the remote binary repo - to a new GAV - and all
others are skipped.

"Branch for release" within trunk-based development is just one way of
working and suits a range of release cadences for teams.

* https://maven.apache.org/guides/mini/guide-reproducible-builds.html

- Paul

Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?

[Paul Hammant]

Thanks for that. Me 15 years ago would have know the answer as bells are
ringing now :)

Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?

[Paul Hammant]

I can't find where the HTTP-PUT logic is for deployment of Maven artifacts
to remote repos.

I was looking in 'maven-deploy-plugin' and 'maven-artifact-transfer' but
could not see the logic that pushes artifacts up to maven-central (or any
other properties-specified repo).

I'm wanting to play with the code and make an enhancement. No guarantees
it'd get accepted back of course. My goal of writing the code and tests
feels quite simple, but I'm stymied by not knowing where this logic is.
Pseudocode:

calc jar sha1 & md5
calc pom sha1 & md5
push up jar & pom and their md5 & sha1
if sources exist {
calc sources sha1 & md5
push up sources jar and its md5 & sha1
}
if javadoc exist {
calc javadoc sha1 & md5
push up javadoc jar and its md5 & sha1
}


Well, I forget the sig file too, but you get what I'm after. Does anyone
know which repo/plugin this is in?

- Paul

Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?

[Paul Hammant]

I'm still clicking around trying to find the piece of code I'm interested
in. I've found

MessageDigest(string).getInstance(“SHA-1”).update(various), but not
succinctly how it links to the upload/publish process.


I've already made the change I want for GraknLab's
"bazel-distribution" (Python) bazel rule for publishing to maven central (
commit
)
and also for the official bazel rule "rules_jvm_external" for the same (
commit

-
Java). Those were 80 and 100 LoC changes.  The Python one (of course) is
closest to the pseudocode I wrote above.


Maybe my alternate approach to making the same change (my own forks) is
adding a breakpoint the actual upload method and working backwards to note
all the moving parts and work out how many method signatures would need to
change in multiple abstractions/impls and module's to achieve this.


What's the 2021 best-practice for cloning all core maven modules in one go,
and loading that all into Intellij meaningfully.  It is not svn co
http://svn.apache.org/repos/asf/maven/trunk/ anymore is in?


- Paul

Re: Maven deploy logic .. that does upload of pom, jar, sha1, md5 ?

[Paul Hammant]

Thanks Tamás

After building that all, Is there a trick to instantiating mvnDebug using
those snapshots ?

- Paul