Fwd: Re: [maven] removed XSD generation since it is not published (19247f3)
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)
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)
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
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)
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)
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)
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?
Herve, can we get a release of maven-dependecy-tree? William
Processing Pull Request
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
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
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
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
