Re: Model Version 5.0.0
exactly. by that way, not only simplify pom. Also for one maven build, could identify project dependency hierarchy easier. base on that, could do further things: 1. to ensure whether could parallel build for module projects. 2. provide analysis report for developers to show their dependency hierarchy to help them improve their structure. ... Regards Simon 2014-06-12 21:02 GMT+08:00 Arnaud Héritier aherit...@gmail.com: http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:project_dependencies ??? The idea behind it may be that by default we can declare in a multi-projects build some dependencies without groupId and version. In that case they are using automatically the module groupId and and version asking for the dep (2 lines less in your pom for each dep like this). On Thu, Jun 12, 2014 at 8:21 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: any reference to what you call project dependency? how is it different from a classic dependency? a dependency in a reactor? Regards, Hervé Le mercredi 11 juin 2014 17:18:05 Simon Wang a écrit : Since we're thinking about model-5.0. Is it possible to support project dependency in 5.0? Project dependency could benefit users a lot. They needn't care about whether others dependent projects(might changed) are installed or not. And users needn't always run maven build with parent pom. Regards Simon 2014-03-25 18:41 GMT+08:00 Nigel Magnay nigel.mag...@gmail.com: On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus bmat...@batmat.net wrote: FWIW, I'm aware it's easily feasible to add that checksum validation in a plugin, but you'll still have to repeat the coordinates. And that very thing was my point: I don't think having to repeat those coordinates to add metadata is great. Not even saying this *must* go in modelVersion 5, I just wanted that debate to happen at least for future reference if people wonder why maven pom can't store that dependency metadata (DRY'ly alongside its data, I mean). There's all sorts of other per-dependency information that would be useful, for example - flex applications needing to store RSL deployment paths and policy file urls. The 'maven way' seems to be sentenced to perennially repeat yourself, and live with the fact your plugin config and your dependency list can drift out of sync. Or to suffer some kind of excuse of 'just specify the dependencies you want to apply this metadata to with some kind of regular expression (!)'. XML even has a well-understood extension mechanism for this kind of thing. ... dependency security:sha1=1234567890abcdef groupIdcom.woo/groupId artifactIdyay/artifactId version1.0/version flex:rslInfo flex:deployment-path/blah/blah/flex:deployment-path flex:policy-file/woo/policy.xml/flex:policy-file /flex:rslInfo /dependency plugins plugin /// some plugin that enforces security:sha1 etc etc etc If your tooling doesn't understand namespaced nodes, it's trivial to strip them. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: enforcer-rules: standard vs. extra-enforcer-rules
May I know who is handling this PR? https://github.com/apache/maven-enforcer/pull/13 any comments or concerns? Regards Simon 2014-05-30 10:38 GMT+08:00 Wang YunFeng wangyf2...@gmail.com: Hi, Karl, Real case happened in our company is: There are bunch of repositories using. For specific application, need to limit specific set of repositories. Those invalid repositories could be defined anywhere. like settings.xml, application's pom files or even in dependency's pom files. So point is: this rule will ban repositories from maven session level, instead of only application pom and its parent. Also attached some comments below from Paul. I create a demo project to show how to use this rule: 1. clone https://github.com/wangyf2010/maven-enforcer, mvn clean install -DskipTests it. 2. clone https://github.com/wangyf2010/maven-shared/tree/banned-repos/maven-dependency-analyzer 3. run mvn enforcer:enforce for maven-dependency-analyzer. Of course, you can try to add banned repositories into settings.xml as well. Regards Simon I think banning repositories is a great idea. The example givem may not be too useful -- the system architects should just turn off access to the repo they don't want anyone to acesss -- but I more than once wanted to stop some live repos (out of my control) from being accessed. +1. Cheers, Paul 2014-05-30 2:36 GMT+08:00 Karl Heinz Marbaise khmarba...@gmx.de: Hi Simon, after diving into this a little bit more... Can you give an real example of the use case for your rule, cause if you are in an enterprise environment you should use already a repository manager which means only having a mirror entry in your settings.xml (usually looks like this here: http://books.sonatype.com/ nexus-book/reference/maven-sect-single-group.html) no repositories in your pom's (which can be checked by the requireNoRepositories rule). Apart from that I have tried your rule, but unfortunately it does not identify repositories defined in the pom file (ok that was not the intention) nor does it realize that i have defined supplemental repositories in my settings.xml file May be you can give an full example in which cases it will help...or may be i mistaken things here... Kind regards Karl-Heinz Marbaise On 5/29/14 4:24 PM, Wang, Simon wrote: Hi, Robert, Karl asked same question, please refer below mail about this question. Hope that help. Regards Simon Hi, Karl, Thanks for your comments. I did dig into requireNoRepositories.html, the purpose for that rule is: detect whether pom and pom’s parents contains repositories definition. That make sense to guide users to use correct convention (not define repositories in pom files). But “BannedRepositories” is different purpose, it’s just like “BannedDependencies”. This rule is major for those “maven repository migration” case. Some users used to have old repositories, those repositories might be defined in pom.xml or settings.xml. This rule could benefit on these cases a lot. It will detect banned repositories from maven session context instead of only pom.xml and parents. After all, requireNoRepositories.html is trying to help users to follow correct maven convention. but “BannedRepositories” is trying to avoid misuse incorrect repositories. Especially in enterprise environment. Regards Simon Hi Simon, I have taken a look into your suggestions I have a couple of thoughts about it ... First there exists already a rule to avoid repositories ( http://maven.apache.org/enforcer/enforcer-rules/ requireNoRepositories.html) which can be used and is has an option to allow particular repositories by using a white-list of allowed repository based on the repository id. like this: requireNoRepositories allowedRepositories allowedRepositorycodehausSnapshots/allowedRepository /allowedRepositories ... /requireNoRepositories So the question is why adding a complete new rule instead of enhancing the existing by your idea using the url as identification for the repository which i think is a really good idea...so users are not able to forge the repository they use by using a different id only the url is used to identify the allowed repositories. Kind regards Karl-Heinz Marbaise On May 29, 2014, at 10:15 PM, Robert Scholte rfscho...@apache.org wrote: http://maven.apache.org/enforcer/enforcer-rules/ requireNoRepositories.html seems to cover this, right? Robert Op Wed, 28 May 2014 22:19:07 +0200 schreef Mirko Friedenhagen mfriedenha...@gmail.com: Hello everybody, there is an outstanding MENFORCER-193[0] request for a new standard rule, which will allow to ban repositories. What is your opinion about adding new standard rules in enforcer vs. adding to Mojo's extra-enforcer-rules? Regards Mirko [0] https://jira.codehaus.org/browse/MENFORCER-193 -- http://illegalstateexception.blogspot.com/
Re: Model Version 5.0.0
Since we're thinking about model-5.0. Is it possible to support project dependency in 5.0? Project dependency could benefit users a lot. They needn't care about whether others dependent projects(might changed) are installed or not. And users needn't always run maven build with parent pom. Regards Simon 2014-03-25 18:41 GMT+08:00 Nigel Magnay nigel.mag...@gmail.com: On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus bmat...@batmat.net wrote: FWIW, I'm aware it's easily feasible to add that checksum validation in a plugin, but you'll still have to repeat the coordinates. And that very thing was my point: I don't think having to repeat those coordinates to add metadata is great. Not even saying this *must* go in modelVersion 5, I just wanted that debate to happen at least for future reference if people wonder why maven pom can't store that dependency metadata (DRY'ly alongside its data, I mean). There's all sorts of other per-dependency information that would be useful, for example - flex applications needing to store RSL deployment paths and policy file urls. The 'maven way' seems to be sentenced to perennially repeat yourself, and live with the fact your plugin config and your dependency list can drift out of sync. Or to suffer some kind of excuse of 'just specify the dependencies you want to apply this metadata to with some kind of regular expression (!)'. XML even has a well-understood extension mechanism for this kind of thing. ... dependency security:sha1=1234567890abcdef groupIdcom.woo/groupId artifactIdyay/artifactId version1.0/version flex:rslInfo flex:deployment-path/blah/blah/flex:deployment-path flex:policy-file/woo/policy.xml/flex:policy-file /flex:rslInfo /dependency plugins plugin /// some plugin that enforces security:sha1 etc etc etc If your tooling doesn't understand namespaced nodes, it's trivial to strip them.
Re: Apachecon in budapest ?
I can't attend it, but +1. ^_^ Things are changing faster. Maven need to change also. It's better to have a considerate roadmap for maven: I tried about one month on gradle, lots of interesting ideas that maven could reference: 1. stable incremental build 2. project dependency support 3. elegant and intensive profile(performance or others insight information of maven session) report 4. flexible dependency resolution strategies. (dependency resolution strategy should be plug-able instead hard-coded) 5. think about parallel distributed Regards Simon 2014-06-11 17:08 GMT+08:00 Tamás Cservenák ta...@cservenak.net: +1 thanks, ~t~ (mobile) On Jun 11, 2014 7:54 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I've been considering attending apachecon in Budapest, and I would be really interested in creating a meet up to discuss future maven (for one or more days). It would be interesting to see if we'd be capable of using such an occasion to determine a little more about the big picture future of maven, possibly even discuss a proper 4.0 release and/or work through the reality of revised pom versions/formats. Like a lot of us I seem to be having trouble finding time for more than incremental (minor) improvements. It also seems like a lot of the stuff on the current 4.0 list is quite minor stuff and I'd really enjoy an occasion to investigate big changes :) Anyone else interested ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: enforcer-rules: standard vs. extra-enforcer-rules
^_^ sorry for that, just don't know what's the status for it. Regards Simon 2014-06-12 5:54 GMT+08:00 Karl Heinz Marbaise khmarba...@gmx.de: Hi Simon, you seemed to be very impatient... Kind regards Karl-Heinz... BTW: I will take care within the next few days... May I know who is handling this PR? https://github.com/apache/maven-enforcer/pull/13 any comments or concerns? Regards Simon 2014-05-30 10:38 GMT+08:00 Wang YunFeng wangyf2...@gmail.com mailto:wangyf2...@gmail.com: Hi, Karl, Real case happened in our company is: There are bunch of repositories using. For specific application, need to limit specific set of repositories. Those invalid repositories could be defined anywhere. like settings.xml, application's pom files or even in dependency's pom files. So point is: this rule will ban repositories from maven session level, instead of only application pom and its parent. Also attached some comments below from Paul. I create a demo project to show how to use this rule: 1. clone https://github.com/wangyf2010/maven-enforcer, mvn clean install -DskipTests it. 2. clone https://github.com/wangyf2010/maven-shared/tree/banned- repos/maven-dependency-analyzer 3. run mvn enforcer:enforce for maven-dependency-analyzer. Of course, you can try to add banned repositories into settings.xml as well. Regards Simon I think banning repositories is a great idea. The example givem may not be too useful -- the system architects should just turn off access to the repo they don't want anyone to acesss -- but I more than once wanted to stop some live repos (out of my control) from being accessed. +1. Cheers, Paul 2014-05-30 2:36 GMT+08:00 Karl Heinz Marbaise khmarba...@gmx.de mailto:khmarba...@gmx.de: Hi Simon, after diving into this a little bit more... Can you give an real example of the use case for your rule, cause if you are in an enterprise environment you should use already a repository manager which means only having a mirror entry in your settings.xml (usually looks like this here: http://books.sonatype.com/__nexus-book/reference/maven-__ sect-single-group.html http://books.sonatype.com/nexus-book/reference/maven- sect-single-group.html) no repositories in your pom's (which can be checked by the requireNoRepositories rule). Apart from that I have tried your rule, but unfortunately it does not identify repositories defined in the pom file (ok that was not the intention) nor does it realize that i have defined supplemental repositories in my settings.xml file May be you can give an full example in which cases it will help...or may be i mistaken things here... Kind regards Karl-Heinz Marbaise On 5/29/14 4:24 PM, Wang, Simon wrote: Hi, Robert, Karl asked same question, please refer below mail about this question. Hope that help. Regards Simon Hi, Karl, Thanks for your comments. I did dig into requireNoRepositories.html, the purpose for that rule is: detect whether pom and pom’s parents contains repositories definition. That make sense to guide users to use correct convention (not define repositories in pom files). But “BannedRepositories” is different purpose, it’s just like “BannedDependencies”. This rule is major for those “maven repository migration” case. Some users used to have old repositories, those repositories might be defined in pom.xml or settings.xml. This rule could benefit on these cases a lot. It will detect banned repositories from maven session context instead of only pom.xml and parents. After all, requireNoRepositories.html is trying to help users to follow correct maven convention. but “BannedRepositories” is trying to avoid misuse incorrect repositories. Especially in enterprise environment. Regards Simon Hi Simon, I have taken a look into your suggestions I have a couple of thoughts about it ... First there exists already a rule to avoid repositories (http://maven.apache.org/__enforcer/enforcer-rules/__ requireNoRepositories.html http://maven.apache.org/enforcer/enforcer-rules/ requireNoRepositories.html) which can be used and is has an option to allow particular repositories by using a white-list
