Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

[Christian Schulte]

Am 06/22/16 um 23:41 schrieb Hervé BOUTEMY:
> - move code to maven-shared-utils: the drawback here is to add jansi 
> dependency to the artifact.

+1

Just flag it 'optional' so that people not using the Ansi related
classes do not get it on the classpath and do not need to exclude it
everywhere. While at it, the jsr305 dependency could also be flagged
'optional' instead of using scope 'provided'.


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

Re: Extending Mavens Dependency-Resolution Strategy?

[Robert Scholte]

Have I look at https://issues.apache.org/jira/browse/MPLUGIN-302
This proposal will allow more scopes and plugins are able to select a set  
of dependencies based on the scope.

It looks like your problem could be solved with this implementation.

thanks,
Robert

On Wed, 22 Jun 2016 10:40:41 +0200, Christofer Dutz  
 wrote:



Hi,


I am working on a new Maven plugin for building Apache Flex projects.  
While the Flexmojos plugin I am also maintaining seems to still be  
working but requiring more and more hacks, I would like to drop that and  
make things cleaner in a new plugin.



The dependency scopes defined in Maven per default are tightly linked to  
Javas scopes. Unfortunately other languages tend to have more scopes.  
Flex for example compiles in code that is directly referenced to the  
output and had so-called "rsl" scope which results in something more  
similar to jars or DLLs. The opposite -"include" - results in something  
like static linking, including all (not only the referenced code parts).



Maven accepts scopes like this but outputs a warning in the beginning. I  
can live with that. In older versions of Maven if think unknown scopes  
were handled as "compile" scope, but this was fixed and in more recent  
versions I think all scopes of transitive dependencies that are not  
built in to maven automatically resolve to runtime or provided (Don't  
quite remember).



I know I could get rid of the warnings by providing a custom  
ModelValidator, but I guess the resolutions of dependencies would still  
not work correctly.



Is there an extension point where I could provide a  
".mvn/extensions.xml" entry to tell Maven how to resolve the other  
scopes? I think I stumbled over the component implementing the  
transitive resolutions one or two years ago, but I seem to be unable to  
find that again. I was planning on extending that component to work only  
on flex-type projects and to default back to the default if it's not a  
flex project.



Any other ideas, pointers, suggestions?


Chris


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

Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

[Hervé BOUTEMY]

thinking more about it.
Yes, having Maven core depending on maven-project-utils, which dependes on 
maven-core, will cause issues: I already had to add an exclusion to avoid a 
build tests failure...

Where to put AnsiUtils?
I see multiple options:
- a new Maven core module: the drawback I see is that it will be a really 
small artifact...
- move code to maven-plugin-api: it would be consistent. The drawback here is 
that we'll need to shade it into plugins to avoid Maven 3.4.0 requirement
- move code to maven-shared-utils: the drawback here is to add jansi 
dependency to the artifact.

Any preference? Any other idea?

Regards,

Hervé

Le mardi 21 juin 2016 08:33:48 Hervé BOUTEMY a écrit :
> Le lundi 20 juin 2016 20:33:26 Christian Schulte a écrit :
> > Am 06/20/16 um 19:15 schrieb Robert Scholte:
> > > Hi Christian,
> > > 
> > > when I introduced the maven-project-utils I had a library in mind with
> > > helpful MavenProject related methods for multiple plugins. For that
> > > reason
> > > I didn't make it part of the Maven distribution.
> > > With this commit the library suddenly is required.
> > > Instead I think you should use plain JAnsi or we should extract the
> > > logging part from the library.
> > 
> > Hervé committed this and is currently working on it.
> 
> yes, I'm the culprit here :)
> 
> > Colours disappeard
> > on current 'master' here.
> 
> same for me
> the code that checks for Maven version before activating colors does not
> work when run in Maven core...
> I just activated color explicitely in Maven core, but since this code will
> also be responsible for custom colors injection (later, I still didn't have
> time to implement it), I don't think this will be the right answer
> 
> > I am not sure using plain JAnsi is the way to
> > go. I would prefer having some kind of facade people can use which
> > allows us to replace JAnsi without the need to touch any code.
> 
> replacing JAnsi probably won't happen
> But this API is responsible for consistent and configable colors
> 
> > Currently
> > JAnsi still is on the compile classpath. That's like using classes of
> > some 'com.sun' package. We have no compiler warning people about direct
> > use of JAnsi. So it better disappears from any compile classpath to be
> > safe. Allowing direct use of JAnsi we also run into that 'everyone uses
> > colours in an inconsistent way' - like someone else already said - we
> > will get that rainbow console effect sometime in the future (when people
> > start providing colours in theire plugins).
> 
> this is where Java 9 modules would help...
> For the moment, I don't think hiding JAnsi is a priority: explaining the
> Maven color logging messages API is more important.
> 
> > The API Hervé is working on
> > looks promising. Maybe we make that a class in 'maven-core' instead of a
> > part of some library. Plugins already add 'maven-core' to theire compile
> > classpath.
> 
> if we do that, doing plugins working on every Maven version will require
> reflection: that's hard
> 
> > That could pull in some kind of Ansi Logging helper class as
> > well. No need for a separate library, I think.
> 
> If using maven-project-utils in core is not ok, yes, we'll need a separate
> library
> 
> Regards,
> 
> Hervé
> 
> > Regards,
> 
> -
> 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

[RESULT] [VOTE] Release Apache Maven Source Plugin version 3.0.1

[Karl Heinz Marbaise]

Hi,

The vote has passed with the following result:

+1 : Michael Osipov, Olivier Lamy, Hervé Boutemy

PMC quorum: reached.

I will promote the artifacts to the central repo.

Kind regards
Karl Heinz Marbaise


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

[GitHub] maven-integration-testing pull request #14: MNG-6049: Adds integration tests...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/maven-integration-testing/pull/14


---
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 pull request #70: MNG-6049: Adds version range result filter behaviour

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/maven/pull/70


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

[RESULT] [VOTE] Release Apache Maven JAR Plugin version 3.0.2

[Karl Heinz Marbaise]

Hi,

The vote has passed with the following result:

+1 : Olivier Lamy, Hervé Boutemy, Karl Heinz Marbaise

PMC quorum: reached.

I will promote the artifacts to the central repo.

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: Contributing to Apache Maven

[Karl Heinz Marbaise]

Hi,


On 6/21/16 9:15 PM, Rajiv Jain wrote:

Hi

I have created a JIRA account and wish to assign myself a JIRA ticket.


Ok...

> How can I assign a ticket to myself?

Have you tried to do a "Assign to me" ?

If not possible one of the DEV's could do so...


> It mentions on the wiki, that I should add a comment so that people
>  know that you are working on this issue.

sounds good...

> Is this correct or am I looking at outdated information?



Secondly, if I would like to make fixes as per the JIRA issues.


This is the only way to do fixes...You can take a look where the
JIRA locations...this can be found on the plugin pages or the shared 
component pages


https://maven.apache.org/shared/
https://maven.apache.org/plugins/

The JIRA links are also on those pages



>  So, if I use Git what is the branching model you use?

This depends on where you like to make contributions

on Maven Core Yes than you can use Git

https://maven.apache.org/ref/3.3.9/
https://git-wip-us.apache.org/repos/asf/maven.git You can of course use 
the mirrored version on github: https://github.com/apache/maven/

where you can make a fork and there you can make pull requests...

For other parts of the Maven project for example plugins you have to use 
Subversion or git.


http://maven.apache.org/plugins/

here you can see where it is located...git/svn ?

Also some informations about:

http://maven.apache.org/guides/development/guide-helping.html




Thanks.

Regards,
Rajiv


Kind regards
Karl Heinz

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

Contributing to Apache Maven

[Rajiv Jain]

Hi

I have created a JIRA account and wish to assign myself a JIRA ticket. How can 
I assign a ticket to myself? It mentions on the wiki, that I should add a 
comment so that people know that you are working on this issue. Is this correct 
or am I looking at outdated information?

Secondly, if I would like to make fixes as per the JIRA issues. So, if I use 
Git what is the branching model you use?

Thanks.

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

Re: VOTE] Release Apache Maven Source Plugin version 3.0.1

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le samedi 18 juin 2016 16:49:19 Karl Heinz Marbaise a écrit :
> Hi,
> 
> We solved 8 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924
> rsion=12335588
> 
> There are still one issue left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSOURCES%20AND%20
> status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1280
> https://repository.apache.org/content/repositories/maven-1280/org/apache/mav
> en/plugins/maven-source-plugin/3.0.1/maven-source-plugin-3.0.1-source-releas
> e.zip
> 
> Source release checksum(s):
> maven-source-plugin-3.0.1-source-release.zip sha1:
> fb9b07870d5a9c8b12622f18c426893a932a3334
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-source-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org


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

Re: [VOTE] Release Apache Maven JAR Plugin version 3.0.2

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le samedi 18 juin 2016 16:24:24 Karl Heinz Marbaise a écrit :
> Hi,
> 
> We solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526
> rsion=12336062=Text
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJAR%20AND%20stat
> us%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1279
> https://repository.apache.org/content/repositories/maven-1279/org/apache/mav
> en/plugins/maven-jar-plugin/3.0.2/maven-jar-plugin-3.0.2-source-release.zip
> 
> Source release checksum(s):
> maven-jar-plugin-3.0.2-source-release.zip sha1:
> 2aa4c89fc550ff3bd4bcb3ff163644b2e9e7be67
> 
> Staging site:
> http://maven.apache.org/plugins-archives/maven-jar-plugin-LATEST/
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 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

[GitHub] maven-scm issue #31: SCM-706 finer-grained handling of file rename status fo...

[sergei-ivanov]

Github user sergei-ivanov commented on the issue:

https://github.com/apache/maven-scm/pull/31
  
@YogiKhan Unfortunately, I haven't got the resources to actively work on 
this issue. I've already spent an awful lot of time debugging it, and still 
have no clear idea where exactly it goes wrong. At some point I had an 
suspicion that we were relativising the wrong way round, but when I played 
around again yesterday, it kind of made sense what was going on there. What 
scares me is that this code appears to be quite sensitive to changes, and any 
change in working directory logic may cause unwanted side effects elsewhere. 
Feel free to fork my fork and experiment. I guess the way to go might be by 
rigging proper integration tests to cover all cases we are dealing with.


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

Extending Mavens Dependency-Resolution Strategy?

[Christofer Dutz]

Hi,


I am working on a new Maven plugin for building Apache Flex projects. While the 
Flexmojos plugin I am also maintaining seems to still be working but requiring 
more and more hacks, I would like to drop that and make things cleaner in a new 
plugin.


The dependency scopes defined in Maven per default are tightly linked to Javas 
scopes. Unfortunately other languages tend to have more scopes. Flex for 
example compiles in code that is directly referenced to the output and had 
so-called "rsl" scope which results in something more similar to jars or DLLs. 
The opposite -"include" - results in something like static linking, including 
all (not only the referenced code parts).


Maven accepts scopes like this but outputs a warning in the beginning. I can 
live with that. In older versions of Maven if think unknown scopes were handled 
as "compile" scope, but this was fixed and in more recent versions I think all 
scopes of transitive dependencies that are not built in to maven automatically 
resolve to runtime or provided (Don't quite remember).


I know I could get rid of the warnings by providing a custom ModelValidator, 
but I guess the resolutions of dependencies would still not work correctly.


Is there an extension point where I could provide a ".mvn/extensions.xml" entry 
to tell Maven how to resolve the other scopes? I think I stumbled over the 
component implementing the transitive resolutions one or two years ago, but I 
seem to be unable to find that again. I was planning on extending that 
component to work only on flex-type projects and to default back to the default 
if it's not a flex project.


Any other ideas, pointers, suggestions?


Chris

[GitHub] maven-scm issue #31: SCM-706 finer-grained handling of file rename status fo...

[YogiKhan]

Github user YogiKhan commented on the issue:

https://github.com/apache/maven-scm/pull/31
  
@sergei-ivanov can you take a look at what @rfscholte suggested.

After running it manually suggested by you, things works for root but not 
working for submodules.
Also release-pom.xml should not get checked-in, thats why i think we had 
the git rm to remove those.
Once we add the pom and release-pom.xml to git tag, we need to remove the 
release-pom.xml from tag.



---
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-integration-testing issue #14: MNG-6049: Adds integration tests for ve...

[barthel]

Github user barthel commented on the issue:

https://github.com/apache/maven-integration-testing/pull/14
  
@michael-o Done. ITs passed. Merge conflict solved.


---
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 issue #70: MNG-6049: Adds version range result filter behaviour

[talios]

Github user talios commented on the issue:

https://github.com/apache/maven/pull/70
  
@barthel Maybe, I'm running 3.4.0-SNAPSHOTs anyway, and might pull in your 
PR to play with and see if it helps with what I'm doing.  My currently problem 
is that IntelliJ IDEA doesn't seem to execute any lifecycle extensions, so 
things that affect dependency resolution don't get reflected in IntelliJ ( my 
process is currently injecting user properties, but I suspect a pluggable 
dependency selector may also not get picked up ).


---
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-integration-testing issue #14: MNG-6049: Adds integration tests for ve...

[barthel]

Github user barthel commented on the issue:

https://github.com/apache/maven-integration-testing/pull/14
  
@michael-o Rename already done. ITs running locally right now.


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