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

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

[GitHub] maven-release pull request #11: MRELEASE-979: Allow VersionPolicies to manag...

[hgschmie]

GitHub user hgschmie opened a pull request:

https://github.com/apache/maven-release/pull/11

MRELEASE-979: Allow VersionPolicies to manage Branch and Tag names

Adds a new method to the VersionPolicy interface to allow
configuration of Branch and Tag names in a version policy.

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

$ git pull https://github.com/hgschmie/maven-release MRELEASE-979

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

https://github.com/apache/maven-release/pull/11.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #11


commit 00be62111fd7fb1f1b46a79558fd9a20d5756bc6
Author: Henning Schmiedehausen 
Date:   2017-01-25T01:13:05Z

implements MRELEASE-979: Allow VersionPolicies to manage Branch and Tag 
names

Adds a new method to the VersionPolicy interface to allow
configuration of Branch and Tag names in a version policy.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven-release pull request #10: [MRELEASE-977] makes the release:branch goal...

[hgschmie]

Github user hgschmie closed the pull request at:

https://github.com/apache/maven-release/pull/10


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [VOTE] Release Apache Maven Invoker version 3.0.0 (shared component)

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le dimanche 22 janvier 2017, 21:03:31 CET Robert Scholte a écrit :
> Hi,
> 
> We solved 9 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922
> rsion=12331463=Text
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317922%20AND%20
> %20component%20%3D%20maven-invoker%20AND%20status%20%3D%20Open%20ORDER%20BY%
> 20key%20DESC%2C%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1316
> https://repository.apache.org/content/repositories/maven-1316/org/apache/mav
> en/shared/maven-invoker/3.0.0/maven-invoker-3.0.0-source-release.zip
> 
> Source release checksum(s):
> maven-invoker-3.0.0-source-release.zip sha1:
> d8b39d6b91f571e8d304feec09b9e955ac7b75d0
> 
> Staging site:
> https://maven.apache.org/shared-archives/maven-invoker-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: Update Cwiki Roadmap 2017

[Stephen Connolly]

done

On 24 January 2017 at 19:26, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Well they should show up in the jira table once the issues have been
> changed to have Fix Version 3.5.0. I can clear out the bits of hard code
> from the wiki page later if Hervé doesn't beat me to it
>
> On 24 January 2017 at 19:01, Michael Osipov  wrote:
>
>> No, I don't. Read-only. I will create an INFRA ticket. Can you meanwhile
>> update the page?
>>
>> Thank you!
>>
>>
>> Am 2017-01-24 um 19:45 schrieb Hervé BOUTEMY:
>>
>>> you don't have edit karma on Confluence?
>>> if you need it, please open a Jira issue for INFRA like I did for
>>> Christian
>>> [1]: we learned that Confluence is not tied to LDAP yet, then require
>>> manual
>>> addition of account into maven-committers group.
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> [1] https://issues.apache.org/jira/browse/INFRA-13311
>>>
>>> Le mardi 24 janvier 2017, 18:39:17 CET Michael Osipov a écrit :
>>>
 Hi Hervé, Stephen,

 another bus load of candidates have been seconded/blessed for FIX-3.5.0
 recently by Karl Heinz, me, Christian and you two. Can you update the
 wiki page accordingly?

 I'd like to continue to work on agreed changes.

 Michael


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

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

Re: [VOTE] Release Apache Maven Artifact Resolver version 1.0.3

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le dimanche 22 janvier 2017, 16:41:44 CET Hervé BOUTEMY a écrit :
> Hi,
> 
> We solved 1 issue: we renamed Aether to Maven Artifact Resolver, with exact
> same code as Aether 1.0.2.
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1315/
> https://repository.apache.org/content/repositories/maven-1315/org/apache/
> maven/resolver/maven-resolver/1.0.3/maven-resolver-1.0.3-source-release.zip
> 
> Source release checksum(s):
> maven-resolver-1.0.3-source-release.zip sha1:
> 9818cfe6aca1035e9ae36d61869ce3b8ad1bbd07
> 
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: Jenkins Jobs

[Stephen Connolly]

We probably can delete those jobs.

I'll do an inventory and put the proposal the the list

On Tue 24 Jan 2017 at 19:43, Karl Heinz Marbaise  wrote:

> Hi the Jenkins Job:
>
>
>
>
> https://builds.apache.org/job/maven-master-release-status-test-plugins-windows/36/console
>
>
>
> hangs with Exception in thread "main" java.lang.OutOfMemoryError:
>
> PermGen space
>
>
>
> for a little bit longer time (3 Days ...)..
>
>
>
> I have aborted that job...
>
>
>
> Kind regards
>
> Karl Heinz Marbaise
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: svn commit: r1779527 - in /maven/plugins/trunk/maven-checkstyle-plugin: ./ src/main/java/org/apache/maven/plugin/ src/main/java/org/apache/maven/plugins/ src/main/java/org/apache/maven/plugins/che

[Robert Scholte]

Done

On Tue, 24 Jan 2017 20:54:20 +0100, Guillaume Boué   
wrote:


Could the 2.18 version on JIRA be renamed to 3.0.0? I'll close the issue  
and start looking at all the others we can fix with this upgrade (like  
MCHECKSTYLE-275 for a start).


Guillaume


Le 20/01/2017 à 16:37, Robert Scholte a écrit :

Very nice, another plugin moving forward

Robert

On Thu, 19 Jan 2017 22:06:24 +0100,  wrote:


Author: gboue
Date: Thu Jan 19 21:06:23 2017
New Revision: 1779527

URL: http://svn.apache.org/viewvc?rev=1779527=rev
Log:
[MCHECKSTYLE-335] Migrate plugin to Maven 3.0

Upgrading the Maven version to 3.0 in the POM:
 - Passing version to 3.0.0-SNAPSHOT to mark the upgrade
 - Renaming the packages to org.apache.maven.plugins
 - Removing Maven 2 specific quirks



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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le  
logiciel antivirus Avast.

https://www.avast.com/antivirus


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


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

Re: svn commit: r1779527 - in /maven/plugins/trunk/maven-checkstyle-plugin: ./ src/main/java/org/apache/maven/plugin/ src/main/java/org/apache/maven/plugins/ src/main/java/org/apache/maven/plugins/che

[Guillaume Boué]

Could the 2.18 version on JIRA be renamed to 3.0.0? I'll close the issue 
and start looking at all the others we can fix with this upgrade (like 
MCHECKSTYLE-275 for a start).


Guillaume


Le 20/01/2017 à 16:37, Robert Scholte a écrit :

Very nice, another plugin moving forward

Robert

On Thu, 19 Jan 2017 22:06:24 +0100,  wrote:


Author: gboue
Date: Thu Jan 19 21:06:23 2017
New Revision: 1779527

URL: http://svn.apache.org/viewvc?rev=1779527=rev
Log:
[MCHECKSTYLE-335] Migrate plugin to Maven 3.0

Upgrading the Maven version to 3.0 in the POM:
 - Passing version to 3.0.0-SNAPSHOT to mark the upgrade
 - Renaming the packages to org.apache.maven.plugins
 - Removing Maven 2 specific quirks



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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Update Cwiki Roadmap 2017

[Michael Osipov]

https://issues.apache.org/jira/browse/INFRA-13388

Am 2017-01-24 um 20:39 schrieb Guillaume Boué:

Hi Michael,

When you do, can you ask edit privileges for me as well? That would
avoid creating another one.

Thanks,
Guillaume

Le 24/01/2017 à 20:01, Michael Osipov a écrit :

No, I don't. Read-only. I will create an INFRA ticket. Can you
meanwhile update the page?

Thank you!

Am 2017-01-24 um 19:45 schrieb Hervé BOUTEMY:

you don't have edit karma on Confluence?
if you need it, please open a Jira issue for INFRA like I did for
Christian
[1]: we learned that Confluence is not tied to LDAP yet, then require
manual
addition of account into maven-committers group.

Regards,

Hervé

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

Le mardi 24 janvier 2017, 18:39:17 CET Michael Osipov a écrit :

Hi Hervé, Stephen,

another bus load of candidates have been seconded/blessed for FIX-3.5.0
recently by Karl Heinz, me, Christian and you two. Can you update the
wiki page accordingly?

I'd like to continue to work on agreed changes.

Michael


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




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






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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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






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

Jenkins Jobs

[Karl Heinz Marbaise]

Hi the Jenkins Job:

https://builds.apache.org/job/maven-master-release-status-test-plugins-windows/36/console

hangs with Exception in thread "main" java.lang.OutOfMemoryError: 
PermGen space


for a little bit longer time (3 Days ...)..

I have aborted that job...

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: Update Cwiki Roadmap 2017

[Guillaume Boué]

Hi Michael,

When you do, can you ask edit privileges for me as well? That would 
avoid creating another one.


Thanks,
Guillaume

Le 24/01/2017 à 20:01, Michael Osipov a écrit :
No, I don't. Read-only. I will create an INFRA ticket. Can you 
meanwhile update the page?


Thank you!

Am 2017-01-24 um 19:45 schrieb Hervé BOUTEMY:

you don't have edit karma on Confluence?
if you need it, please open a Jira issue for INFRA like I did for 
Christian
[1]: we learned that Confluence is not tied to LDAP yet, then require 
manual

addition of account into maven-committers group.

Regards,

Hervé

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

Le mardi 24 janvier 2017, 18:39:17 CET Michael Osipov a écrit :

Hi Hervé, Stephen,

another bus load of candidates have been seconded/blessed for FIX-3.5.0
recently by Karl Heinz, me, Christian and you two. Can you update the
wiki page accordingly?

I'd like to continue to work on agreed changes.

Michael


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




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






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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Update Cwiki Roadmap 2017

[Michael Osipov]

Thanks, this is what I was after. Didn't want to fiddle with 
issues/pages without consent first.


Am 2017-01-24 um 20:26 schrieb Stephen Connolly:

Well they should show up in the jira table once the issues have been
changed to have Fix Version 3.5.0. I can clear out the bits of hard code
from the wiki page later if Hervé doesn't beat me to it

On 24 January 2017 at 19:01, Michael Osipov  wrote:


No, I don't. Read-only. I will create an INFRA ticket. Can you meanwhile
update the page?

Thank you!


Am 2017-01-24 um 19:45 schrieb Hervé BOUTEMY:


you don't have edit karma on Confluence?
if you need it, please open a Jira issue for INFRA like I did for
Christian
[1]: we learned that Confluence is not tied to LDAP yet, then require
manual
addition of account into maven-committers group.

Regards,

Hervé

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

Le mardi 24 janvier 2017, 18:39:17 CET Michael Osipov a écrit :


Hi Hervé, Stephen,

another bus load of candidates have been seconded/blessed for FIX-3.5.0
recently by Karl Heinz, me, Christian and you two. Can you update the
wiki page accordingly?

I'd like to continue to work on agreed changes.

Michael


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





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






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








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

Re: Update Cwiki Roadmap 2017

[Stephen Connolly]

Well they should show up in the jira table once the issues have been
changed to have Fix Version 3.5.0. I can clear out the bits of hard code
from the wiki page later if Hervé doesn't beat me to it

On 24 January 2017 at 19:01, Michael Osipov  wrote:

> No, I don't. Read-only. I will create an INFRA ticket. Can you meanwhile
> update the page?
>
> Thank you!
>
>
> Am 2017-01-24 um 19:45 schrieb Hervé BOUTEMY:
>
>> you don't have edit karma on Confluence?
>> if you need it, please open a Jira issue for INFRA like I did for
>> Christian
>> [1]: we learned that Confluence is not tied to LDAP yet, then require
>> manual
>> addition of account into maven-committers group.
>>
>> Regards,
>>
>> Hervé
>>
>> [1] https://issues.apache.org/jira/browse/INFRA-13311
>>
>> Le mardi 24 janvier 2017, 18:39:17 CET Michael Osipov a écrit :
>>
>>> Hi Hervé, Stephen,
>>>
>>> another bus load of candidates have been seconded/blessed for FIX-3.5.0
>>> recently by Karl Heinz, me, Christian and you two. Can you update the
>>> wiki page accordingly?
>>>
>>> I'd like to continue to work on agreed changes.
>>>
>>> Michael
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Update Cwiki Roadmap 2017

[Michael Osipov]

No, I don't. Read-only. I will create an INFRA ticket. Can you meanwhile 
update the page?


Thank you!

Am 2017-01-24 um 19:45 schrieb Hervé BOUTEMY:

you don't have edit karma on Confluence?
if you need it, please open a Jira issue for INFRA like I did for Christian
[1]: we learned that Confluence is not tied to LDAP yet, then require manual
addition of account into maven-committers group.

Regards,

Hervé

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

Le mardi 24 janvier 2017, 18:39:17 CET Michael Osipov a écrit :

Hi Hervé, Stephen,

another bus load of candidates have been seconded/blessed for FIX-3.5.0
recently by Karl Heinz, me, Christian and you two. Can you update the
wiki page accordingly?

I'd like to continue to work on agreed changes.

Michael


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




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






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

Re: Update Cwiki Roadmap 2017

[Hervé BOUTEMY]

you don't have edit karma on Confluence?
if you need it, please open a Jira issue for INFRA like I did for Christian 
[1]: we learned that Confluence is not tied to LDAP yet, then require manual 
addition of account into maven-committers group.

Regards,

Hervé

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

Le mardi 24 janvier 2017, 18:39:17 CET Michael Osipov a écrit :
> Hi Hervé, Stephen,
> 
> another bus load of candidates have been seconded/blessed for FIX-3.5.0
> recently by Karl Heinz, me, Christian and you two. Can you update the
> wiki page accordingly?
> 
> I'd like to continue to work on agreed changes.
> 
> Michael
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Update Cwiki Roadmap 2017

[Michael Osipov]

Hi Hervé, Stephen,

another bus load of candidates have been seconded/blessed for FIX-3.5.0 
recently by Karl Heinz, me, Christian and you two. Can you update the 
wiki page accordingly?


I'd like to continue to work on agreed changes.

Michael


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

Re: Maven Jenkinsfile Job is Gone

[Hervé BOUTEMY]

no mistake, I renamed it to better find it in the too long jobs list [1]: I 
just forgot to add it to the view definition, I just did it (Jenkins does not 
do it automatically when renaming, it seems)

We should probably do some cleanup between these core-integration-testing-
maven-3*, core-it-maven-3-win, maven-2.2.x, maven-3.0.x, maven-3.2-release-
status* and maven-3.x* jobs: there are too much jobs, and this maven-jenkins 
that was hidden near maven-jxr was just one ore noise.

NOtice that tonight, when merging MNG-3507 branch, I'll merge a change in 
Jenkinsfile to have better titles for notification emails: too many "Maven 
Jenkinsfile finished with null" emails, now we'll have "maven-3.x-jenkinsfile/
MNG-3507 - build #6 - null"

On the "null" at the end, I don't know what to do, but knowing that "null" 
means "SUCCESS" is sufficient to me currently.

Regards,

Hervé

[1] https://builds.apache.org/view/M-R/view/Maven/

Le mardi 24 janvier 2017, 13:34:45 CET Stephen Connolly a écrit :
> Somebody mistakenly renamed it:
> 
> https://builds.apache.org/job/maven-3.x-jenkinsfile/
> 
> On Tue 24 Jan 2017 at 13:25, Stephen Connolly <
> 
> stephen.alan.conno...@gmail.com> wrote:
> > I recommend filing a ticket with infra
> > 
> > On Tue 24 Jan 2017 at 13:11, Michael Osipov  wrote:
> >> Hi friends,
> >> 
> >> 
> >> 
> >> the pipeline Jenkinsfile job is gone from Jenkins. Can someone with the
> >> 
> >> appropriate permissions have a look?
> >> 
> >> 
> >> 
> >> Michael
> >> 
> >> 
> >> 
> >> -
> >> 
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> 
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >> 
> >> 
> >> 
> >> --
> > 
> > Sent from my phone



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

Always get the false value when calling org.apache.maven.shared.invoker.InvovationRequest.isUpdateSnapshots()

[Samuel Gaspari]

Hello,
Using the org.apache.maven.shared.invoker.InvovationRequest leads to get
always the false value, even if the "-U" or "--update-snapshots" option is
set.

InvocationRequest request = new DefaultInvocationRequest();
updateSnapshots = request.isUpdateSnapshots();

Posts @
http://maven.40175.n5.nabble.com/Plugin-Development-Injection-of-component-td5747607.html
don't explain exactly if it is possible to get the value of an option, it
seems to be used to set the value of an option.

Thanks a lot for your help.

Regards.

Samuel Gaspari

Re: Requesting a single Monorepo enhancement for Maven

[Jörg Schaible]

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

It is the last big problem, yes.

Sent from my iPhone

> On Jan 24, 2017, at 10:10 AM, Igor Fedorenko  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

Re: Requesting a single Monorepo enhancement for Maven

[Igor Fedorenko]

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

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

Re: Requesting a single Monorepo enhancement for Maven

[Stephen Connolly]

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

Re: Maven Jenkinsfile Job is Gone

[Stephen Connolly]

Shouldn't be 3.x as it will include 5.x when we start that and I was
planning a 2.x Jenkinsfile just for completeness and to assist re-checking
the integration tests against 2.x

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

> Somebody mistakenly renamed it:
>
> https://builds.apache.org/job/maven-3.x-jenkinsfile/
>
> On Tue 24 Jan 2017 at 13:25, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> I recommend filing a ticket with infra
>
> On Tue 24 Jan 2017 at 13:11, Michael Osipov  wrote:
>
> Hi friends,
>
>
>
> the pipeline Jenkinsfile job is gone from Jenkins. Can someone with the
>
> appropriate permissions have a look?
>
>
>
> Michael
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
> Sent from my phone
>
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: Maven Jenkinsfile Job is Gone

[Stephen Connolly]

Somebody mistakenly renamed it:

https://builds.apache.org/job/maven-3.x-jenkinsfile/

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

> I recommend filing a ticket with infra
>
> On Tue 24 Jan 2017 at 13:11, Michael Osipov  wrote:
>
>> Hi friends,
>>
>>
>>
>> the pipeline Jenkinsfile job is gone from Jenkins. Can someone with the
>>
>> appropriate permissions have a look?
>>
>>
>>
>> Michael
>>
>>
>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>> --
> Sent from my phone
>
-- 
Sent from my phone

Re: 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  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  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 
> >
> > > 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,  / http://about.me/aldrinleal
> >
> > > > >
> >
> > > > > 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 -
> >
> > > > > >
> >
> > > > > >   
> >
> 

Re: Maven Jenkinsfile Job is Gone

[Stephen Connolly]

I recommend filing a ticket with infra

On Tue 24 Jan 2017 at 13:11, Michael Osipov  wrote:

> Hi friends,
>
>
>
> the pipeline Jenkinsfile job is gone from Jenkins. Can someone with the
>
> appropriate permissions have a look?
>
>
>
> Michael
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: Requesting a single Monorepo enhancement for Maven

[Stephen Connolly]

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  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  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 
>
> > 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,  / http://about.me/aldrinleal
>
> > > >
>
> > > > 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.
>
> > > > >
>
> > > >
>
> > >
>
> >
>
> --
Sent from my phone

Maven Jenkinsfile Job is Gone

[Michael Osipov]

Hi friends,

the pipeline Jenkinsfile job is gone from Jenkins. Can someone with the 
appropriate permissions have a look?


Michael

-
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

[Robert Scholte]

Hi Paul,

the problem with the proposals is that it doesn't fit the modelversion  
4.0.0 (XSD)
However, what I could think of having a module with a protocol and provide  
an extension which can locate the actual module locations. The extension  
kicks in at startup while creating the BuildPlan.


e.g.

 def:.full-module-list.txt


One question: suppose there's an issue in production, how can we get  
exactly the same setup of the project to reproduce that issue? Or do you  
accept that if you can't reproduce it on the master/trunk it is not an  
issue anymore?


thanks,
Robert

On Tue, 24 Jan 2017 06:05:07 +0100, 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

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  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 
> 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,  / http://about.me/aldrinleal
> > >
> > > 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.
> > > >
> > >
> >
>

Always get the false value when calling org.apache.maven.shared.invoker.InvovationRequest.isUpdateSnapshots()

[Samuel Gaspari]

Hello,
Using the org.apache.maven.shared.invoker.InvovationRequest leads to get
always the false value, even if the "-U" or "--update-snapshots" option is
set.

InvocationRequest request = new DefaultInvocationRequest();
updateSnapshots = request.isUpdateSnapshots();

Posts @http://maven.40175.n5.nabble.com/Plugin-Development-
Injection-of-component-td5747607.html don't explain exactly if it is
possible to get the value of an option, it seems to be used to set the
value of an option.

Thanks a lot for your help.

Regards.

Samuel Gaspari

Re: Requesting a single Monorepo enhancement for Maven

[Stephen Connolly]

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  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  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,  / http://about.me/aldrinleal
> >
> > 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.
> > >
> >
>

Re: [VOTE] Maven Shade Plugin 3.0.0

[Arnaud Héritier]

+1

On Tue, Jan 24, 2017 at 4:34 AM, Olivier Lamy  wrote:

> Hi
> We solved 13 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12331395=Text=12317921=Create
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1319/
> https://repository.apache.org/content/repositories/maven-
> 1319/org/apache/maven/plugins/maven-shade-plugin/3.0.0/
> maven-shade-plugin-3.0.0-source-release.zip
>
> Source release checksum(s):
>
> curl
> https://repository.apache.org/content/repositories/maven-
> 1319/org/apache/maven/plugins/maven-shade-plugin/3.0.0/
> maven-shade-plugin-3.0.0-source-release.zip.sha1
> Staging site:
> https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>



-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

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  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,  / http://about.me/aldrinleal
>
> 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.
> >
>