Fwd: Re: [maven] removed XSD generation since it is not published (19247f3)

2014-05-25 Thread Hervé BOUTEMY
there are interesting discussion happening on github, but they are not routed 
to any mailing-list, so they stay completely personal: this is not good for 
community, IMHO

is there a way to have such discussions sent to dev@?

Regards,

Hervé

--  Message transmit  --

Sujet : Re: [maven] removed XSD generation since it is not published (19247f3)
Date : dimanche 25 mai 2014, 02:29:12
De : Dave Moten notificati...@github.com
À : apache/maven ma...@noreply.github.com
CC : Hervé Boutemy herve.bout...@free.fr

I was interested in writing tooling around composing plugins maximising
type safety for example but was disappointed that the definition of a
plugin's configuration was not something I could reverse engineer
satisfactorily from the plugin.xml and in the process discovered that the
plugin.XML didn't have an xsd making more guesswork out of the process. I
used xpath to get stuff out of it in the end but I stopped work when I
realised that my only hope was parsing plugins' source code.

I'm a big fan of XML always having an xsd but I probably won't be able to
check out modello and get an xsd happening in the near future and I'm
assuming for my interests that it won't help much either. I wonder if real
type information for configuration will turn up in plugin.xml sometime?

Thanks for chasing it.
D
On 25 May 2014 18:14, Hervé Boutemy notificati...@github.com wrote:

 on a pure principle, I know it looks awkward
 on a practical one:
 1. did you ever try to write a plugin descriptor by hand? or do you always
 let plugin-tools generate the descriptor (like the vast majority of plugin
 developers)?
 2. are you able to give us a xsd description for the configuration element
 content? and that fits into Modello descriptor, since Modello generates the
 xsd from .mdo?

 I'm not a big xsd expert: any help appreciated to fix the plugin.mdo I
 wrote to at least document the descriptor from a human point of view (ie
 not seeing in general that I had to cheat with configuration element)

 —
 Reply to this email directly or view it on 
GitHubhttps://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a#commitcomment-6439921
 .


---
Reply to this email directly or view it on GitHub:
https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a#commitcomment-6440111
-

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



Re: Fwd: Re: [maven] removed XSD generation since it is not published (19247f3)

2014-05-25 Thread Arnaud Héritier
With a virtual account using this address and subscribing to github 
notifications ?—
Sent from Mailbox

On Sun, May 25, 2014 at 12:00 PM, Hervé BOUTEMY herve.bout...@free.fr
wrote:

 there are interesting discussion happening on github, but they are not routed 
 to any mailing-list, so they stay completely personal: this is not good for 
 community, IMHO
 is there a way to have such discussions sent to dev@?
 Regards,
 Hervé
 --  Message transmit  --
 Sujet : Re: [maven] removed XSD generation since it is not published (19247f3)
 Date : dimanche 25 mai 2014, 02:29:12
 De : Dave Moten notificati...@github.com
 À : apache/maven ma...@noreply.github.com
 CC : Hervé Boutemy herve.bout...@free.fr
 I was interested in writing tooling around composing plugins maximising
 type safety for example but was disappointed that the definition of a
 plugin's configuration was not something I could reverse engineer
 satisfactorily from the plugin.xml and in the process discovered that the
 plugin.XML didn't have an xsd making more guesswork out of the process. I
 used xpath to get stuff out of it in the end but I stopped work when I
 realised that my only hope was parsing plugins' source code.
 I'm a big fan of XML always having an xsd but I probably won't be able to
 check out modello and get an xsd happening in the near future and I'm
 assuming for my interests that it won't help much either. I wonder if real
 type information for configuration will turn up in plugin.xml sometime?
 Thanks for chasing it.
 D
 On 25 May 2014 18:14, Hervé Boutemy notificati...@github.com wrote:
 on a pure principle, I know it looks awkward
 on a practical one:
 1. did you ever try to write a plugin descriptor by hand? or do you always
 let plugin-tools generate the descriptor (like the vast majority of plugin
 developers)?
 2. are you able to give us a xsd description for the configuration element
 content? and that fits into Modello descriptor, since Modello generates the
 xsd from .mdo?

 I'm not a big xsd expert: any help appreciated to fix the plugin.mdo I
 wrote to at least document the descriptor from a human point of view (ie
 not seeing in general that I had to cheat with configuration element)

 —
 Reply to this email directly or view it on 
 GitHubhttps://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a#commitcomment-6439921
 .

 ---
 Reply to this email directly or view it on GitHub:
 https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a#commitcomment-6440111
 -
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: Fwd: Re: [maven] removed XSD generation since it is not published (19247f3)

2014-05-25 Thread Hervé BOUTEMY
anybody knows how it is done for PR?
because it works well here: don't know if it could be extended to discussions

trying to cross-post to infra@

Regards,

Hervé

Le dimanche 25 mai 2014 03:06:37 Arnaud Héritier a écrit :
 With a virtual account using this address and subscribing to github
 notifications ?— Sent from Mailbox
 
 On Sun, May 25, 2014 at 12:00 PM, Hervé BOUTEMY herve.bout...@free.fr
 
 wrote:
  there are interesting discussion happening on github, but they are not
  routed to any mailing-list, so they stay completely personal: this is not
  good for community, IMHO
  is there a way to have such discussions sent to dev@?
  Regards,
  Hervé
  --  Message transmit  --
  Sujet : Re: [maven] removed XSD generation since it is not published
  (19247f3) Date : dimanche 25 mai 2014, 02:29:12
  De : Dave Moten notificati...@github.com
  À : apache/maven ma...@noreply.github.com
  CC : Hervé Boutemy herve.bout...@free.fr
  I was interested in writing tooling around composing plugins maximising
  type safety for example but was disappointed that the definition of a
  plugin's configuration was not something I could reverse engineer
  satisfactorily from the plugin.xml and in the process discovered that the
  plugin.XML didn't have an xsd making more guesswork out of the process. I
  used xpath to get stuff out of it in the end but I stopped work when I
  realised that my only hope was parsing plugins' source code.
  I'm a big fan of XML always having an xsd but I probably won't be able to
  check out modello and get an xsd happening in the near future and I'm
  assuming for my interests that it won't help much either. I wonder if real
  type information for configuration will turn up in plugin.xml sometime?
  Thanks for chasing it.
  D
  
  On 25 May 2014 18:14, Hervé Boutemy notificati...@github.com wrote:
  on a pure principle, I know it looks awkward
  on a practical one:
  1. did you ever try to write a plugin descriptor by hand? or do you
  always
  let plugin-tools generate the descriptor (like the vast majority of
  plugin
  developers)?
  2. are you able to give us a xsd description for the configuration
  element
  content? and that fits into Modello descriptor, since Modello generates
  the
  xsd from .mdo?
  
  I'm not a big xsd expert: any help appreciated to fix the plugin.mdo I
  wrote to at least document the descriptor from a human point of view
  (ie
  not seeing in general that I had to cheat with configuration element)
  
  —
  Reply to this email directly or view it on
  
  GitHubhttps://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f40
  83fd890fc47a#commitcomment-6439921 
  .
  
  ---
  Reply to this email directly or view it on GitHub:
  https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890
  fc47a#commitcomment-6440111 -
  -
  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 pull request: MNG-4226 Detect JAVA_HOME on newer Mac OS X

2014-05-25 Thread Humbedooh
Github user Humbedooh commented on the pull request:

https://github.com/apache/maven/pull/11#issuecomment-44127870
  
Testing integration with the maven dev ML, please ignore :)


---
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: Fwd: Re: [maven] removed XSD generation since it is not published (19247f3)

2014-05-25 Thread Hervé BOUTEMY
Jira issue opened https://issues.apache.org/jira/browse/INFRA-7803[1] 
and configuration done by Humbedooh for every Maven repo mirrored to github

thank you Humbedooh

Hervé

Le dimanche 25 mai 2014 12:17:53 Hervé BOUTEMY a écrit :
 anybody knows how it is done for PR?
 because it works well here: don't know if it could be extended to
 discussions
 
 trying to cross-post to infra@
 
 Regards,
 
 Hervé
 
 Le dimanche 25 mai 2014 03:06:37 Arnaud Héritier a écrit :
  With a virtual account using this address and subscribing to github
  notifications ?— Sent from Mailbox
  
  On Sun, May 25, 2014 at 12:00 PM, Hervé BOUTEMY herve.bout...@free.fr
  
  wrote:
   there are interesting discussion happening on github, but they are not
   routed to any mailing-list, so they stay completely personal: this is
   not
   good for community, IMHO
   is there a way to have such discussions sent to dev@?
   Regards,
   Hervé
   --  Message transmit  --
   Sujet : Re: [maven] removed XSD generation since it is not published
   (19247f3) Date : dimanche 25 mai 2014, 02:29:12
   De : Dave Moten notificati...@github.com
   À : apache/maven ma...@noreply.github.com
   CC : Hervé Boutemy herve.bout...@free.fr
   I was interested in writing tooling around composing plugins maximising
   type safety for example but was disappointed that the definition of a
   plugin's configuration was not something I could reverse engineer
   satisfactorily from the plugin.xml and in the process discovered that
   the
   plugin.XML didn't have an xsd making more guesswork out of the process.
   I
   used xpath to get stuff out of it in the end but I stopped work when I
   realised that my only hope was parsing plugins' source code.
   I'm a big fan of XML always having an xsd but I probably won't be able
   to
   check out modello and get an xsd happening in the near future and I'm
   assuming for my interests that it won't help much either. I wonder if
   real
   type information for configuration will turn up in plugin.xml sometime?
   Thanks for chasing it.
   D
   
   On 25 May 2014 18:14, Hervé Boutemy notificati...@github.com wrote:
   on a pure principle, I know it looks awkward
   on a practical one:
   1. did you ever try to write a plugin descriptor by hand? or do you
   always
   let plugin-tools generate the descriptor (like the vast majority of
   plugin
   developers)?
   2. are you able to give us a xsd description for the configuration
   element
   content? and that fits into Modello descriptor, since Modello generates
   the
   xsd from .mdo?
   
   I'm not a big xsd expert: any help appreciated to fix the plugin.mdo I
   wrote to at least document the descriptor from a human point of view
   (ie
   not seeing in general that I had to cheat with configuration element)
   
   —
   Reply to this email directly or view it on
   
   
GitHubhttps://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f
   40
   83fd890fc47a#commitcomment-6439921
   
   .
   
   ---
   Reply to this email directly or view it on GitHub:
   
https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd8
   90
   fc47a#commitcomment-6440111 -
   -
   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



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


Re: Fwd: Re: [maven] removed XSD generation since it is not published (19247f3)

2014-05-25 Thread Hervé BOUTEMY
just for reference, here is the feature annoucement:
https://blogs.apache.org/infra/entry/improved_integration_between_apache_and

Regards,

Hervé

Le dimanche 25 mai 2014 12:36:59 Hervé BOUTEMY a écrit :
 Jira issue opened https://issues.apache.org/jira/browse/INFRA-7803[1]
 and configuration done by Humbedooh for every Maven repo mirrored to github
 
 thank you Humbedooh
 
 Hervé
 
 Le dimanche 25 mai 2014 12:17:53 Hervé BOUTEMY a écrit :
  anybody knows how it is done for PR?
  because it works well here: don't know if it could be extended to
  discussions
  
  trying to cross-post to infra@
  
  Regards,
  
  Hervé
  
  Le dimanche 25 mai 2014 03:06:37 Arnaud Héritier a écrit :
   With a virtual account using this address and subscribing to github
   notifications ?— Sent from Mailbox
   
   On Sun, May 25, 2014 at 12:00 PM, Hervé BOUTEMY herve.bout...@free.fr
   
   wrote:
there are interesting discussion happening on github, but they are not
routed to any mailing-list, so they stay completely personal: this is
not
good for community, IMHO
is there a way to have such discussions sent to dev@?
Regards,
Hervé
--  Message transmit  --
Sujet : Re: [maven] removed XSD generation since it is not published
(19247f3) Date : dimanche 25 mai 2014, 02:29:12
De : Dave Moten notificati...@github.com
À : apache/maven ma...@noreply.github.com
CC : Hervé Boutemy herve.bout...@free.fr
I was interested in writing tooling around composing plugins
maximising
type safety for example but was disappointed that the definition of a
plugin's configuration was not something I could reverse engineer
satisfactorily from the plugin.xml and in the process discovered that
the
plugin.XML didn't have an xsd making more guesswork out of the
process.
I
used xpath to get stuff out of it in the end but I stopped work when I
realised that my only hope was parsing plugins' source code.
I'm a big fan of XML always having an xsd but I probably won't be able
to
check out modello and get an xsd happening in the near future and I'm
assuming for my interests that it won't help much either. I wonder if
real
type information for configuration will turn up in plugin.xml
sometime?
Thanks for chasing it.
D

On 25 May 2014 18:14, Hervé Boutemy notificati...@github.com wrote:
on a pure principle, I know it looks awkward
on a practical one:
1. did you ever try to write a plugin descriptor by hand? or do you
always
let plugin-tools generate the descriptor (like the vast majority of
plugin
developers)?
2. are you able to give us a xsd description for the configuration
element
content? and that fits into Modello descriptor, since Modello
generates
the
xsd from .mdo?

I'm not a big xsd expert: any help appreciated to fix the plugin.mdo
I
wrote to at least document the descriptor from a human point of
view
(ie
not seeing in general that I had to cheat with configuration element)

—
Reply to this email directly or view it on
 
 GitHubhttps://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f
 
40
83fd890fc47a#commitcomment-6439921

.

---
 
Reply to this email directly or view it on GitHub:
 https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd8
 
90
fc47a#commitcomment-6440111 -
-
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
 
 
 [1] https://issues.apache.org/jira/browse/INFRA-7803


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



Re: [maven] removed XSD generation since it is not published (19247f3)

2014-05-25 Thread Daniel Kulp

We need to file a request with infrastructure to have all the maven repos 
upgraded to the latest “github goodies”.   Pull requests should have more 
information in them, comments on pull requests should come back to this list, 
etc….   I know that’s all working for the CXF pull requests.  For example:

http://cxf.547215.n5.nabble.com/GitHub-cxf-pull-request-PR-fix-CXF-5719-tt5744323.html

And note how that then integrates with JIRA:

https://issues.apache.org/jira/browse/CXF-5719

although that would require getting all our JIRA projects moved to apache.

Dan


On May 25, 2014, at 6:06 AM, Arnaud Héritier aherit...@gmail.com wrote:

 With a virtual account using this address and subscribing to github 
 notifications ?—
 Sent from Mailbox
 
 On Sun, May 25, 2014 at 12:00 PM, Hervé BOUTEMY herve.bout...@free.fr
 wrote:
 
 there are interesting discussion happening on github, but they are not 
 routed 
 to any mailing-list, so they stay completely personal: this is not good for 
 community, IMHO
 is there a way to have such discussions sent to dev@?
 Regards,
 Hervé
 --  Message transmit  --
 Sujet : Re: [maven] removed XSD generation since it is not published 
 (19247f3)
 Date : dimanche 25 mai 2014, 02:29:12
 De : Dave Moten notificati...@github.com
 À : apache/maven ma...@noreply.github.com
 CC : Hervé Boutemy herve.bout...@free.fr
 I was interested in writing tooling around composing plugins maximising
 type safety for example but was disappointed that the definition of a
 plugin's configuration was not something I could reverse engineer
 satisfactorily from the plugin.xml and in the process discovered that the
 plugin.XML didn't have an xsd making more guesswork out of the process. I
 used xpath to get stuff out of it in the end but I stopped work when I
 realised that my only hope was parsing plugins' source code.
 I'm a big fan of XML always having an xsd but I probably won't be able to
 check out modello and get an xsd happening in the near future and I'm
 assuming for my interests that it won't help much either. I wonder if real
 type information for configuration will turn up in plugin.xml sometime?
 Thanks for chasing it.
 D
 On 25 May 2014 18:14, Hervé Boutemy notificati...@github.com wrote:
 on a pure principle, I know it looks awkward
 on a practical one:
 1. did you ever try to write a plugin descriptor by hand? or do you always
 let plugin-tools generate the descriptor (like the vast majority of plugin
 developers)?
 2. are you able to give us a xsd description for the configuration element
 content? and that fits into Modello descriptor, since Modello generates the
 xsd from .mdo?
 
 I'm not a big xsd expert: any help appreciated to fix the plugin.mdo I
 wrote to at least document the descriptor from a human point of view (ie
 not seeing in general that I had to cheat with configuration element)
 
 —
 Reply to this email directly or view it on 
 GitHubhttps://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a#commitcomment-6439921
 .
 
 ---
 Reply to this email directly or view it on GitHub:
 https://github.com/apache/maven/commit/19247f363bee07d1afc6f8902f4083fd890fc47a#commitcomment-6440111
 -
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


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



Release of maven-dependency-tree?

2014-05-25 Thread William Ferguson
Herve,

can we get a release of maven-dependecy-tree?

William


Processing Pull Request

2014-05-25 Thread Michael Osipov

Hi,

does it take special permissions on Github to process pull requests?

Neither am I allowed to perform the merge from the website directly, nor 
does it display the command line steps as described in the GH help. 
Close is not available to me too.


I simply pulled (PL 14) into my local repo and then pushed, asfgit 
processed but the PL is still on merged but not closed.


Is there any writeup how a PL should happen in the project?
Maven Git Convention [1] does not provide any valueable information.

Michael

[1] http://maven.apache.org/developers/conventions/git.html

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



Re: Processing Pull Request

2014-05-25 Thread Benson Margulies
You add special comments to a commit to close a PR. I only have my phone I
can't supply details.
On May 25, 2014 6:04 PM, Michael Osipov mosi...@gmx.de wrote:

 Hi,

 does it take special permissions on Github to process pull requests?

 Neither am I allowed to perform the merge from the website directly, nor
 does it display the command line steps as described in the GH help. Close
 is not available to me too.

 I simply pulled (PL 14) into my local repo and then pushed, asfgit
 processed but the PL is still on merged but not closed.

 Is there any writeup how a PL should happen in the project?
 Maven Git Convention [1] does not provide any valueable information.

 Michael

 [1] http://maven.apache.org/developers/conventions/git.html

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




[GitHub] maven-scm pull request: [SCM-750]: support TFS checkin-policies

2014-05-25 Thread OhadR
Github user OhadR closed the pull request at:

https://github.com/apache/maven-scm/pull/13


---
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-scm pull request: [SCM-750]: support TFS checkin-policies

2014-05-25 Thread OhadR
GitHub user OhadR reopened a pull request:

https://github.com/apache/maven-scm/pull/13

[SCM-750]: support TFS checkin-policies

https://jira.codehaus.org/browse/SCM-750 : 
In TFS, there is an option of checkin policies. In this case, whenever a 
developer checks-in his code, another dialog pops-up , and asks to enter a 
comment. I really do not know who really uses this feature and actually enters 
a real comment (since the comment that is related to the check-in was entered 
in a previous dialog), but in my case the organization's SCM forces this 
extra-dialog. The problem: when I try to check in a file using a command line, 
I HAVE TO add an extra argument to the command (see example below). Hence, the 
scm-tfs plugin does not work, since it lacks this 'extra' argument. As far as i 
saw the code, I understand that the command is hard-coded, and unfortunately it 
is not configurable,
This is an example command-line for check-in (only a single pom.xml):
tf checkin -noprompt -comment:[maven-release-plugin] prepare release 
some-comment-for-checkin D:\.\pom.xml /override:;Auto-Build: Version 
Update;
in this example, '/override:;Auto-Build: Version Update;' is the 
extra-argument.

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

$ git pull https://github.com/OhadR/maven-scm master

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

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


commit ee87b13e87f6b2bcae275c0911afefe330509c4c
Author: OhadR ohadr.develo...@gmail.com
Date:   2014-05-19T10:01:06Z

support TFS checkin-policies

commit f8cc479e589ef7e68ed5558324bd75b7c8844dfc
Author: OhadR ohadr.develo...@gmail.com
Date:   2014-05-19T15:27:17Z

https://jira.codehaus.org/browse/SCM-750: support TFS checkin-policies

https://jira.codehaus.org/browse/SCM-750: support TFS checkin-policies

commit b21b6468aa444018202088af64521cf581bc1989
Author: OhadR ohadr.develo...@gmail.com
Date:   2014-05-24T21:01:08Z

[SCM-750] support checkin policies

commit d82b96a31c884214b9629538e9b7ff55ce3925e5
Author: OhadR ohadr.develo...@gmail.com
Date:   2014-05-24T21:04:49Z

[scm-750] checkin policies

commit c174d0b5e07e49fcce0510e4c47e0677346b64fe
Author: OhadR ohadr.develo...@gmail.com
Date:   2014-05-24T21:41:07Z

[SCM-750] checkin policies

commit bbda4b39aa9abad48e7ccc2038594c0dd5131223
Author: OhadR ohadr.develo...@gmail.com
Date:   2014-05-24T21:45:53Z

[SCM_750]: extract const

commit e80f2d3d02fe77441ac1c46c67a4046203d014fd
Author: OhadR ohadr.develo...@gmail.com
Date:   2014-05-25T13:01:32Z

[SCM-752] : edit mode is required in TFS !




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