Re: Model version (was: Re: [DISCUSSION] finishing Aether import: help find a new name)

[Jason van Zyl]

The model version doesn’t necessarily have anything to do with resolution or 
any behavioral changes per se. I also don’t think a branch is necessary and we 
do branching by abstraction and figure out the feature toggles now and just 
keep it all in master.

> On Jul 28, 2016, at 2:11 PM, Christian Schulte  wrote:
> 
> Am 28.07.2016 um 19:18 schrieb Jason van Zyl:
>> I’m a vehement -1 to changing the artifactIds or structure without a plan.
> 
> +1
> 
> If something does not need to be renamed, then don't rename it. If something 
> needs to be renamed, don't choose some kind of trademarkish name no-one knows 
> what it stands for but something self-describing as much as possible.
> 
>> We have to change the groupId because we cannot deploy into Eclipse’s 
>> namespace but for anyone using this code just leave it how it is while 
>> making improvements.
> 
> +1
> 
>> The library as it stands functions and people are using it. We have 
>> something in Maven core that uses it and it’s pretty terrible but it’s a 
>> great place to start trying to flesh out something new because the ITs will 
>> catch most things.
> 
> We have recently discussed the addition of some kind of feature 
> toggles/switches/knobs and haven't come to a conclusion yet. I would like to 
> make the following proposal:
> 
> Rename the branch 'maven-3.x-next' to 'maven-next'. Use the model version to 
> decide about how Maven should behave when it comes to a change in behaviour 
> between a previous model version and the next model version. Update the model 
> version right now to the next model version on that 'maven-next' branch so 
> things can get going there (setup Jenkins and things like that e.g.) All I 
> need to know for this is what is the model version we will be using in that 
> 'maven-next' branch today. Is it a minor version increment (4.1) or a major 
> one (5.0). The reason I would like to use the model version instead of some 
> kind of feature toggle is to be able to deploy to central or somewhere else. 
> So that Maven can detect how to behave also for POMs it downloads from the 
> repositories instead of relying on some command line option.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Michael Osipov]

Am 2016-07-30 um 00:03 schrieb Hervé BOUTEMY:

I like the org.apache.maven.artifact.resolver idea added to "Maven Artifact
Resolver API" description

I prepared a projection based on this idea:
http://maven.apache.org/aether-archives/aether.html


Attention, we already have: 
https://maven.apache.org/shared/maven-artifact-resolver/


Though, this module has not been updates for years. We shall try to 
avoid confusion here.



Regards,

Hervé

Le jeudi 28 juillet 2016 09:35:08 Stephen Connolly a écrit :

I don't see that this needs a special name, so I am -1 on Akasha

I like Maven Artifact Resolver API... but my only concern with the "mara"
short form is that I'll keep replaying radio satire in my head every time I
say it, e.g. https://www.youtube.com/watch?v=d6ITDfkwKTA

What exactly is wrong with org.apache.maven.ara or
org.apache.maven.artifact.resolver.api if we compare with
org.apache.maven.mara to me the m in mara is redundant because we already
have the maven... so either if we want a short package name then `ara` is
better... or we want an understandable package name... same goes for
artifactIds

On 28 July 2016 at 08:13, Hervé BOUTEMY  wrote:

Hi,

The work on Aether import is progressing: as I commented on MNG-6007
recently,
we now have to find a new name for the component at Apache. Then we'll
update
poms, documentation and git repo accordingly and we'll be ready to make
releases.

We already have first ideas, found by the PMC while working in private on
the
topic:
- Akasha https://en.wikipedia.org/wiki/Akasha
- Maven Artifact Resolver API ("mara" when used as package name or
artifactid
or in maven-mara-provider)


Does anybody have another idea?
Is there a preference in the community?

Regards,

Hervé

-
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: [DISCUSSION] finishing Aether import: help find a new name

[Hervé BOUTEMY]

I like the org.apache.maven.artifact.resolver idea added to "Maven Artifact 
Resolver API" description

I prepared a projection based on this idea:
http://maven.apache.org/aether-archives/aether.html

WDYT?

Regards,

Hervé

Le jeudi 28 juillet 2016 09:35:08 Stephen Connolly a écrit :
> I don't see that this needs a special name, so I am -1 on Akasha
> 
> I like Maven Artifact Resolver API... but my only concern with the "mara"
> short form is that I'll keep replaying radio satire in my head every time I
> say it, e.g. https://www.youtube.com/watch?v=d6ITDfkwKTA
> 
> What exactly is wrong with org.apache.maven.ara or
> org.apache.maven.artifact.resolver.api if we compare with
> org.apache.maven.mara to me the m in mara is redundant because we already
> have the maven... so either if we want a short package name then `ara` is
> better... or we want an understandable package name... same goes for
> artifactIds
> 
> On 28 July 2016 at 08:13, Hervé BOUTEMY  wrote:
> > Hi,
> > 
> > The work on Aether import is progressing: as I commented on MNG-6007
> > recently,
> > we now have to find a new name for the component at Apache. Then we'll
> > update
> > poms, documentation and git repo accordingly and we'll be ready to make
> > releases.
> > 
> > We already have first ideas, found by the PMC while working in private on
> > the
> > topic:
> > - Akasha https://en.wikipedia.org/wiki/Akasha
> > - Maven Artifact Resolver API ("mara" when used as package name or
> > artifactid
> > or in maven-mara-provider)
> > 
> > 
> > Does anybody have another idea?
> > Is there a preference in the community?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > -
> > 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: SCM-677

[Michael Osipov]

Am 2016-07-29 um 20:25 schrieb Johan Huylebroeck:

Hello,
I wasn't aware of this "--parent" option.
That is indeed the simplest solution.
Next 2 weeks I'm offline but after that I'll be happy to contribute to a patch.


Good. Prepare a patch, add appropriate unit tests and ping me in the 
ticket. I will review and apply.



-Original Message-
From: Michael Osipov [mailto:micha...@apache.org]
Sent: vrijdag 29 juli 2016 12:57
To: Maven Developers List 
Subject: Re: SCM-677

Am 2016-07-29 um 12:32 schrieb Johan Huylebroeck:

Hello,
I recently bumped into a known bug SCM-677 when using the scm plugin with 
subversion.
I think that a relatively easy, though svn specific, solution could be 
implemented by first adding all directories leading up to the file(s) before 
adding the file.
Suppose I want to add file A/B/c. The svnAddCommand could first do  "svn add -depth=empty A 
A/B" and then "svn add A/B/c"
This may result in some (harmless) warning if the directories are already in 
svn but is relatively simple to implement.
Would you be willing to accept a patch that implements this?


This is actually weird. Have you checked the targets file?
I have just replayed the issue without debugging it. I do assume that with A/ 
the directory is traversed and added to targets. --non-recursive is deprecated 
and your problem is that in A/ --parents is misisng.

What about dropping --non-recursive and adding --parents instead? This is easy 
to fix and can be checked with A and a/

WDYT?

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: SCM-677

[Johan Huylebroeck]

Hello,
I wasn't aware of this "--parent" option. 
That is indeed the simplest solution.
Next 2 weeks I'm offline but after that I'll be happy to contribute to a patch.

Kind regards,

Johan



-Original Message-
From: Michael Osipov [mailto:micha...@apache.org] 
Sent: vrijdag 29 juli 2016 12:57
To: Maven Developers List 
Subject: Re: SCM-677

Am 2016-07-29 um 12:32 schrieb Johan Huylebroeck:
> Hello,
> I recently bumped into a known bug SCM-677 when using the scm plugin with 
> subversion.
> I think that a relatively easy, though svn specific, solution could be 
> implemented by first adding all directories leading up to the file(s) before 
> adding the file.
> Suppose I want to add file A/B/c. The svnAddCommand could first do  "svn add 
> -depth=empty A A/B" and then "svn add A/B/c"
> This may result in some (harmless) warning if the directories are already in 
> svn but is relatively simple to implement.
> Would you be willing to accept a patch that implements this?

This is actually weird. Have you checked the targets file?
I have just replayed the issue without debugging it. I do assume that with A/ 
the directory is traversed and added to targets. --non-recursive is deprecated 
and your problem is that in A/ --parents is misisng.

What about dropping --non-recursive and adding --parents instead? This is easy 
to fix and can be checked with A and a/

WDYT?

Michael

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


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

RE: Build failed in Jenkins: core-it-maven-3-win #1233

[Martin Gainty]

MG>quick question below


> Subject: Re: Build failed in Jenkins: core-it-maven-3-win #1233
> To: dev@maven.apache.org
> From: c...@schulte.it
> Date: Thu, 28 Jul 2016 17:30:34 +0200
> 
> Can someone take a look, please?
> 
> Error: JAVA_HOME is set to an invalid directory.
> JAVA_HOME = "f:\jenkins\tools\java\latest-1.7-64"
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
> 
> 
> Am 07/28/16 um 17:27 schrieb Apache Jenkins Server:
> > See 
> > 
> > Changes:
> > 
> > [schulte] [MNG-5670] guard against ConcurrentModificationException 
> > [MNG-6053]
> > 
> > --
> > Started by an SCM change
> > [EnvInject] - Loading node environment variables.
> > Building remotely on windows-2012-1 (Windows) in workspace 
> > 
> >  > git rev-parse --is-inside-work-tree # timeout=10
> > Fetching changes from the remote Git repository
> >  > git config remote.origin.url 
> > https://git-wip-us.apache.org/repos/asf/maven.git # timeout=10
> > Fetching upstream changes from 
> > https://git-wip-us.apache.org/repos/asf/maven.git
> >  > git --version # timeout=10
> >  > git -c core.askpass=true fetch --tags --progress 
> > https://git-wip-us.apache.org/repos/asf/maven.git 
> > +refs/heads/*:refs/remotes/origin/*
> >  > git rev-parse "origin/master^{commit}" # timeout=10
> > Checking out Revision 53077505a7e9408565ec30a43ad243c41189a94e 
> > (origin/master)
> >  > git config core.sparsecheckout # timeout=10
> >  > git checkout -f 53077505a7e9408565ec30a43ad243c41189a94e
> >  > git rev-list 32ce34921cc3d71c4216781de4a574037fad532f # timeout=10
> >  > git rev-parse --is-inside-work-tree # timeout=10
> > Fetching changes from the remote Git repository
> >  > git config remote.origin.url 
> > https://git-wip-us.apache.org/repos/asf/maven-integration-testing.git # 
> > timeout=10
> > Pruning obsolete local branches
> > Fetching upstream changes from 
> > https://git-wip-us.apache.org/repos/asf/maven-integration-testing.git
> >  > git --version # timeout=10
> >  > git -c core.askpass=true fetch --tags --progress 
> > https://git-wip-us.apache.org/repos/asf/maven-integration-testing.git 
> > +refs/heads/*:refs/remotes/origin/* --prune
> >  > git rev-parse "origin/master^{commit}" # timeout=10
> > Checking out Revision 31780e49d00ad5be0dd80ee5b37483f624bbf394 
> > (origin/master)
> >  > git config core.sparsecheckout # timeout=10
> >  > git checkout -f 31780e49d00ad5be0dd80ee5b37483f624bbf394
> >  > git rev-list 31780e49d00ad5be0dd80ee5b37483f624bbf394 # timeout=10
> >  > git branch -a # timeout=10
> >  > git rev-parse "remotes/origin/MNG-2477^{commit}" # timeout=10
> >  > git rev-parse "remotes/origin/MNG-3205^{commit}" # timeout=10
> >  > git rev-parse "remotes/origin/embedder^{commit}" # timeout=10
> >  > git rev-parse "remotes/origin/master^{commit}" # timeout=10
> > [m3-its] $ cmd /c call C:\Windows\TEMP\hudson3181989308987956124.bat
> > 
> > rmdir> /S /Q 
> >  
> > The system cannot find the file specified.
> > 
> > rmdir> /S /Q 
> > 
> >  
> > The system cannot find the file specified.
> > 
> > exit> 0 
> > [m3-its] $ cmd.exe /C 
> > '"f:\jenkins\jenkins-slave\tools\hudson.tasks.Maven_MavenInstallation\maven-3.3.1\bin\mvn.cmd
> >  -f maven-3-trunk/pom.xml -DskipTests=true 
> > -Dmaven.home.exists.continue=true 
> > -DdistributionTargetFolder=
> >  
> > -Dmaven.repo.local=
> >  clean package -B -U -V && exit %%ERRORLEVEL%%"'

MG>can you insert -e -X on mvn.cmd so we can see which plugin is being executed 
and which env variables are available e.g.cmd.exe /C 
'"f:\jenkins\jenkins-slave\tools\hudson.tasks.Maven_MavenInstallation\maven-3.3.1\bin\mvn.cmd
 -e -X -f maven-3-trunk/pom.xml -DskipTests=true 
-Dmaven.home.exists.continue=true 
-DdistributionTargetFolder=
 
-Dmaven.repo.local=
 clean package -B -U -V && exit %%ERRORLEVEL%%"'MG>re-rerun with -e -X params 
and post results here> > Error: JAVA_HOME is set to an invalid directory. 
> > JAVA_HOME = "f:\jenkins\tools\java\latest-1.7-64" 
> > Please set the JAVA_HOME variable in your environment to match the 
> > location of your Java installation. 
> > 
> > Build step 'Invoke top-level Maven targets' marked build as failure
> > Recording test results
> > ERROR: Step ‘Publish JUnit 

Re: SCM-677

[Michael Osipov]

Am 2016-07-29 um 12:32 schrieb Johan Huylebroeck:

Hello,
I recently bumped into a known bug SCM-677 when using the scm plugin with 
subversion.
I think that a relatively easy, though svn specific, solution could be 
implemented by first adding all directories leading up to the file(s) before 
adding the file.
Suppose I want to add file A/B/c. The svnAddCommand could first do  "svn add -depth=empty A 
A/B" and then "svn add A/B/c"
This may result in some (harmless) warning if the directories are already in 
svn but is relatively simple to implement.
Would you be willing to accept a patch that implements this?


This is actually weird. Have you checked the targets file?
I have just replayed the issue without debugging it. I do assume that 
with A/ the directory is traversed and added to targets. --non-recursive 
is deprecated and your problem is that in A/ --parents is misisng.


What about dropping --non-recursive and adding --parents instead? This 
is easy to fix and can be checked with A and a/


WDYT?

Michael

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

SCM-677

[Johan Huylebroeck]

Hello,
I recently bumped into a known bug SCM-677 when using the scm plugin with 
subversion.
I think that a relatively easy, though svn specific, solution could be 
implemented by first adding all directories leading up to the file(s) before 
adding the file.
Suppose I want to add file A/B/c. The svnAddCommand could first do  "svn add 
-depth=empty A A/B" and then "svn add A/B/c"
This may result in some (harmless) warning if the directories are already in 
svn but is relatively simple to implement.
Would you be willing to accept a patch that implements this?

Kind regards,

Johan

[GitHub] maven-wagon issue #27: V2.10 rc

[soiff]

Github user soiff commented on the issue:

https://github.com/apache/maven-wagon/pull/27
  
add default filter


---
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-wagon pull request #27: V2.10 rc

[soiff]

GitHub user soiff opened a pull request:

https://github.com/apache/maven-wagon/pull/27

V2.10 rc

add extension for external downloader by specifying following properties:

```
external.loader=axel
external.filter=.*\\.jar
external.state=.st
```

which means one can download all jar resource through `axel`.

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

$ git pull https://github.com/soiff/maven-wagon v2.10-rc

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

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


commit 0af4562f4602981a0c86c0108b5091f6970bb3dd
Author: zhangh 
Date:   2016-07-29T07:15:58Z

add extension for external tool

commit 7f2da211ec3fe4dd80a5d131ae3dfa7f64ae9ecd
Author: zhangh 
Date:   2016-07-29T07:52:14Z

close InputStream if StreamWagonEx can handle

commit 164194f2dea6ea14e016f2451d7ccc8f2cf4529a
Author: zhangh 
Date:   2016-07-29T08:06:26Z

update checkstyle




---
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-wagon pull request #26: V2.10 rc

[soiff]

Github user soiff closed the pull request at:

https://github.com/apache/maven-wagon/pull/26


---
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-wagon pull request #26: V2.10 rc

[soiff]

GitHub user soiff opened a pull request:

https://github.com/apache/maven-wagon/pull/26

V2.10 rc

add extension for external downloader by specifying following properties:

```
external.loader=axel
external.filter=.*\\.jar
external.state=.st
```

which means one can download resource by `axel` and integrate it to maven.

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

$ git pull https://github.com/soiff/maven-wagon v2.10-rc

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

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


commit 0af4562f4602981a0c86c0108b5091f6970bb3dd
Author: zhangh 
Date:   2016-07-29T07:15:58Z

add extension for external tool

commit 7f2da211ec3fe4dd80a5d131ae3dfa7f64ae9ecd
Author: zhangh 
Date:   2016-07-29T07:52:14Z

close InputStream if StreamWagonEx can handle




---
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-wagon issue #25: add extension for external tool

[soiff]

Github user soiff commented on the issue:

https://github.com/apache/maven-wagon/pull/25
  
fix defect in new source


---
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-wagon pull request #25: add extension for external tool

[soiff]

Github user soiff closed the pull request at:

https://github.com/apache/maven-wagon/pull/25


---
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-wagon pull request #25: add extension for external tool

[soiff]

GitHub user soiff opened a pull request:

https://github.com/apache/maven-wagon/pull/25

add extension for external tool

Add extension for external download tool such as axel.

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

$ git pull https://github.com/soiff/maven-wagon v2.10-rc

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

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


commit 0af4562f4602981a0c86c0108b5091f6970bb3dd
Author: zhangh 
Date:   2016-07-29T07:15:58Z

add extension for external tool




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