Re: Armed with a collection of Artifacts, what is the Maven Way™ to resolve them?
Does http://svn.codehaus.org/mojo/trunk/mojo/extra-enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractResolveDependencies.java help you? Cheers 2014/1/6 Laird Nelson ljnel...@gmail.com On Sun, Jan 5, 2014 at 3:56 PM, Laird Nelson ljnel...@gmail.com wrote: What is the Maven Way™ to resolve these Artifacts? For completeness, I also looked at http://maven.apache.org/guides/introduction/introduction-to-artifact-resolution.htmlbut this didn't seem to have ever been completed. Thanks, Best, Laird -- http://about.me/lairdnelson -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Using Plugin Truncated Name
I have written my own maven mojo plugin and wish to use the truncated name instead of the long name to invoke it, like so: Instead of mvn org.apache.maven.plugins:maven-pce-plugin:pull I want use: mvn pce:pull But even though I put it under group 'org.apache.maven.plugins' and named it maven-pce-plugin I still get error message: No plugin found for prefix 'pce' in the current project and in the plugin groups [*org.apache.maven.plugins*, org.codehaus.mojo] available from the repositories [local (C:\Users\omar\.m2\repository), central ( http://repo.maven.apache.org/maven2)] What am I doing wrong? thanks for the help.
Re: Using Plugin Truncated Name
On 6 January 2014 12:40, Omar@Gmail omarnet...@googlemail.com wrote: I have written my own maven mojo plugin and wish to use the truncated name instead of the long name to invoke it, like so: Instead of mvn org.apache.maven.plugins:maven-pce-plugin:pull I want use: mvn pce:pull But even though I put it under group 'org.apache.maven.plugins' and named it maven-pce-plugin I still get error message: No don't put it there... you don't own that group Id. Put it in your own groupId and then in your settings.xml just add your group Id as the pluginGroups http://maven.apache.org/settings.html#Plugin_Groups No plugin found for prefix 'pce' in the current project and in the plugin groups [*org.apache.maven.plugins*, org.codehaus.mojo] available from the repositories [local (C:\Users\omar\.m2\repository), central ( http://repo.maven.apache.org/maven2)] What am I doing wrong? thanks for the help.
Re: Maven Central Opinion
Hello again, OK, I suspected that I get a lot of replies on this :-). From experience in other forums I also expected to have people tell me to go screw myself, but that has not happened. There are apparently only professionals here! That said, there some very good replies and explanations but also some I do react to. I'll start with the latter. The arguments about quality I just don't buy. We are only talking poms here. Whatever is in the poms says nothing about the quality of the software itself. What is really bothering me however is the argument that if you don't have your things in the way we think they should be, you are not serious enough. It hasn't been said straight out but implied. The word that pops into my head here is Moralizing! I take my work very seriously and I take my open source work even more seriously (since in that case I'm allowed the time for it :-)). That if I have one file that is not up to someones liking I'm not taking releasing of my software seriously is just absurd. ___ From one of the replies: As I said in a previous message, deploying to the remote repo is just a matter of mvn deploy, using either the maven-deploy-plugin (by default) or the nexus-staging-maven-plugin. That is good, that is how easy it should be! You'll have to configure the GPG plugin to sign your artifacts though, as it's a requirement to deploy to Central. No problem! I'm going to go though the documentation again and solve the easy way to do it :-). And If I can't find a page that explains this clearly I will create such! I have gotten very much information here to go on. Someone also pointed out that local webserver repositories are good enough for small projects. I basically agree with that. I only considered maven central since someone asked me. But it is easier to have things in central and not have to add multiple repository specifications in your pom/settings. OK, you can use nexus to merge several repositories into one and then use that. But if submission to central can be made easy then it is worth to do it. Software does not have to be large apache projects to be useful. There are some truly useful software out there that comes from single individuals. Here is my view of how I would want a maven repository to be: - No requirements of javadoc or sources. If you want to include those, no problem, but if you don't it is up to you. Personally I like to have sources available in the repository for the third party software I'm using so I would also submit sources to my software, but that is entirely up to me. - Tags on submitted software (not required - can be empty). - Searchable data in addition to group and artifact: - Tags - Descriptions - A browsable (navigable) web gui, not just searches. - A standardized documentation zip containing PDFs and/or markdown. - Quality indication: - The possibility to star artifacts just like you can star repos in github. Also for group level. - Download statistics (filtered on ip-address, multiple downloads from the same ip-address only count as one). - A quality value based on these two as sorting order for search results. - When an artifact or group is selected in the web gui the following should be displayed: - Dependency tags for the artifact (obviously :-)) - Pom information like description, web url, developers, scm url, etc. - Stars and download stats. - Any submitted docs. With so much software available in one place it would be very nice to have it more searchable and on more useful criteria, and also to have the ability to get more details on the software at the same place. Tommy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Opinion
I'll start with the latter. The arguments about quality I just don't buy. We are only talking poms here. Whatever is in the poms says nothing about the quality of the software itself. I agree the pom says nothing about the quality of the software. However, having a standard mechanism for describing in small detail software releases. By ensuring that this is consistent, it ensures that the quality of searching for artifacts in Maven central is maintained, it also ensures that when someone finds an artifact they can look at the pom to see what it does and who to contact should they have a problem. I consider that a small investment. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Opinion
The arguments about quality I just don't buy. We are only talking poms here. Whatever is in the poms says nothing about the quality of the software itself. Quality of metadata. POM serve as metadata in this case, so, I'd rather say Central enforces quality of metadata (ie. POM properly filled in, using proper and proven/owned groupId, sane artifactId, etc, minimal set of fields are given, file signatures, checksums are present, no update of already deployed stuff happens [ie. your deploy request would overwrite something in Cenral] etc). Still, you can deploy a jar full of zeroes to Central if you wish, all until you use proper GA, the checksums and signatures matches, and POM fulfills minimal requirements :) My 5 cents
Re: Maven Central Opinion
6 jan 2014 kl. 14:10 skrev Tamás Cservenák ta...@cservenak.net: The arguments about quality I just don't buy. We are only talking poms here. Whatever is in the poms says nothing about the quality of the software itself. Quality of metadata. POM serve as metadata in this case, so, I'd rather say Central enforces quality of metadata (ie. POM properly filled in, using proper and proven/owned groupId, sane artifactId, etc, minimal set of fields are given, file signatures, checksums are present, no update of already deployed stuff happens [ie. your deploy request would overwrite something in Cenral] etc). Still, you can deploy a jar full of zeroes to Central if you wish, all until you use proper GA, the checksums and signatures matches, and POM fulfills minimal requirements :) And I think that is a good thing! It would be rather stupid to do that, but that is beside the point :-). My 5 cents - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using Plugin Truncated Name
Thanks Stephen, What you suggest sounds like good practice (not sure why though) however not a fix for my issue. The fix is as follows: - somehow your response inspired me :) In the pom.xml file of the custom plugin there is a plugin configured maven-plugin-plugin in that plugin add configuration goalPrefixpce/goalPrefix I then installed the plugin and I tried mvn pce:pull and that worked fine. Job done. On 6 January 2014 12:44, Stephen Connolly stephen.alan.conno...@gmail.comwrote: On 6 January 2014 12:40, Omar@Gmail omarnet...@googlemail.com wrote: I have written my own maven mojo plugin and wish to use the truncated name instead of the long name to invoke it, like so: Instead of mvn org.apache.maven.plugins:maven-pce-plugin:pull I want use: mvn pce:pull But even though I put it under group 'org.apache.maven.plugins' and named it maven-pce-plugin I still get error message: No don't put it there... you don't own that group Id. Put it in your own groupId and then in your settings.xml just add your group Id as the pluginGroups http://maven.apache.org/settings.html#Plugin_Groups No plugin found for prefix 'pce' in the current project and in the plugin groups [*org.apache.maven.plugins*, org.codehaus.mojo] available from the repositories [local (C:\Users\omar\.m2\repository), central ( http://repo.maven.apache.org/maven2)] What am I doing wrong? thanks for the help.
Re: Armed with a collection of Artifacts, what is the Maven Way™ to resolve them?
On Mon, Jan 6, 2014 at 1:05 AM, Baptiste Mathus bmat...@batmat.net wrote: Does http://svn.codehaus.org/mojo/trunk/mojo/extra-enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractResolveDependencies.java help you? Yes; I see that it uses maven-artifact-resolver. If indeed the ArtifactResolver class from version 2.1 of maven-artifact-resolver is the way to go, won't be deprecated, handles the Eclipse/Sonatype Aether split transparently, etc. then that's what I'll use. Thanks! Best, Laird -- http://about.me/lairdnelson
Re: Armed with a collection of Artifacts, what is the Maven Way™ to resolve them?
On Mon, Jan 6, 2014 at 5:44 AM, Laird Nelson ljnel...@gmail.com wrote: On Mon, Jan 6, 2014 at 1:05 AM, Baptiste Mathus bmat...@batmat.netwrote: Does http://svn.codehaus.org/mojo/trunk/mojo/extra-enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractResolveDependencies.java help you? Yes; I see that it uses maven-artifact-resolver. If indeed the ArtifactResolver class from version 2.1 of maven-artifact-resolver is the way to go, won't be deprecated, handles the Eclipse/Sonatype Aether split transparently, etc. then that's what I'll use. Thanks! (Meant to say maven-artifact-resolver version 1.0.) Best, Laird -- http://about.me/lairdnelson
Re: Maven Central Opinion
I am assuming that you are putting this in Central so I can easily use it without having to worry about the effect on my build process or without having to get into your sources and dependencies to build my app and I have appropriate license agreements included so I know what I am incorporating into my app. In that case, I would like you to follow the Maven Best Practices for deploying to Central. Using the Release plug-in may save you some steps if you do not already have a private repo for releasing software internally. It seems to me that if you are already releasing to your own repo prior to trying to upload it to Central, you are probably going to find that the Release plug-in is not the best practice. We would be in the same situation if we ever decided to put some of our utilities into Maven Central. We have already done the release and our SCM is in the state in which we want it. We would probably have to look at our parent POM/child POM structure to be sure that it met Maven Central requirements. I think that you did the right thing by raising your concerns here and I think that you got some very good advice and concrete suggestions. This is a very good group that is usually well-mannered when approached in the way that you did. You were very clear about what you wanted to do and you raised very specified issues that you wanted to discuss. You also reacted to the advice in a positive way that encouraged a factual discussion rather than a personal attack. Ron On 06/01/2014 7:49 AM, Tommy Svensson wrote: Hello again, OK, I suspected that I get a lot of replies on this :-). From experience in other forums I also expected to have people tell me to go screw myself, but that has not happened. There are apparently only professionals here! That said, there some very good replies and explanations but also some I do react to. I'll start with the latter. The arguments about quality I just don't buy. We are only talking poms here. Whatever is in the poms says nothing about the quality of the software itself. What is really bothering me however is the argument that if you don't have your things in the way we think they should be, you are not serious enough. It hasn't been said straight out but implied. The word that pops into my head here is Moralizing! I take my work very seriously and I take my open source work even more seriously (since in that case I'm allowed the time for it :-)). That if I have one file that is not up to someones liking I'm not taking releasing of my software seriously is just absurd. ___ From one of the replies: As I said in a previous message, deploying to the remote repo is just a matter of mvn deploy, using either the maven-deploy-plugin (by default) or the nexus-staging-maven-plugin. That is good, that is how easy it should be! You'll have to configure the GPG plugin to sign your artifacts though, as it's a requirement to deploy to Central. No problem! I'm going to go though the documentation again and solve the easy way to do it :-). And If I can't find a page that explains this clearly I will create such! I have gotten very much information here to go on. Someone also pointed out that local webserver repositories are good enough for small projects. I basically agree with that. I only considered maven central since someone asked me. But it is easier to have things in central and not have to add multiple repository specifications in your pom/settings. OK, you can use nexus to merge several repositories into one and then use that. But if submission to central can be made easy then it is worth to do it. Software does not have to be large apache projects to be useful. There are some truly useful software out there that comes from single individuals. Here is my view of how I would want a maven repository to be: - No requirements of javadoc or sources. If you want to include those, no problem, but if you don't it is up to you. Personally I like to have sources available in the repository for the third party software I'm using so I would also submit sources to my software, but that is entirely up to me. - Tags on submitted software (not required - can be empty). - Searchable data in addition to group and artifact: - Tags - Descriptions - A browsable (navigable) web gui, not just searches. - A standardized documentation zip containing PDFs and/or markdown. - Quality indication: - The possibility to star artifacts just like you can star repos in github. Also for group level. - Download statistics (filtered on ip-address, multiple downloads from the same ip-address only count as one). - A quality value based on these two as sorting order for search results. - When an artifact or group is selected in the web gui the following should be displayed: - Dependency tags for the artifact (obviously :-)) - Pom information like description, web url, developers, scm url, etc. - Stars and
short and snappy description of what Maven is
on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Having problem with Maven and POM file
I running a test using intelliJ13 and it would not run I did a mvn clean test and got the following results (see video) https://www.dropbox.com/s/44geyj4bhthi8mb/Pom%20File%20problem%20in%20maven. mp4 How do I fix this. Speak soon Jacqueline George
Re: short and snappy description of what Maven is
Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: short and snappy description of what Maven is
When people ask me what Maven is, I tell them it's a build and library management tool. If I take it a step further I explain it manages library and dependency versions akin to how SCM systems manage source code. It's not a perfect analogy but I find it works for a lay description. Richard Sand | CEO IDF Connect, Inc. 2207 Concord Ave, #359 Wilmington | Delaware 19803 | USA Office: +1 888 765 1611 | Fax: +1 866 765 7284 Mobile: +1 267 984 3651 -Original Message- From: Russell Gold [mailto:russell.g...@oracle.com] Sent: Monday, January 06, 2014 12:57 PM To: Maven Users List Subject: Re: short and snappy description of what Maven is Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It's not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: short and snappy description of what Maven is
The goal is to put this on the front page so that people know enough to decide if they need/want to dig deeper On Monday, 6 January 2014, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.comjavascript:; wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; -- Sent from my phone
Re: short and snappy description of what Maven is
The mention of convention over configuration really is key. The biggest problem I see when people switch from Ant to Maven is they really don't want to buy into the convention philosophy. Even if they are willing to do so, their project usually is not laid out in a complimentary way and it is likely they do not manage third party libraries outside the context of the project (ie. a nexus/artifactory repo). Because of this, they either waste a lot of time trying to contort Maven into working like Ant, or they spend much more time than anticipated re-arranging their projects and weaving the idea of jar repo into their processes and infrastructure, neither of which leaves people with a happy experience. As a few others have mentioned, the features and goals of the various build tools are nearly the same. It's the driving philosophy that makes the difference. Understanding that it is more of a philosophical comparison/change rather than just a tool/feature comparison I think is critical to people starting up with Maven with proper expectations. Robert Kuropkat On 01/06/2014 12:43 PM, Lyons, Roy wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: short and snappy description of what Maven is
I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Ron On 06/01/2014 12:57 PM, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: short and snappy description of what Maven is
On Monday, 6 January 2014, Ron Wheeler wrote: I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Yes that is the idea Ron On 06/01/2014 12:57 PM, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Sent from my phone
Re: short and snappy description of what Maven is
Several sentences sounds good. But here’s another question. Comparing Maven to ant is almost too easy in terms of advantages. Is gradle now a serious competitor (I had been working on converting an enormous project to maven, but the architect decided to switch to gradle, so I am particularly sensitive to the issue). I can see some superficial advantages of gradle that might appeal to some projects. Is it better to ignore or address this? On Jan 6, 2014, at 3:02 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Monday, 6 January 2014, Ron Wheeler wrote: I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Yes that is the idea Ron On 06/01/2014 12:57 PM, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Sent from my phone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: short and snappy description of what Maven is
On 06/01/2014 3:08 PM, Russell Gold wrote: Several sentences sounds good. But here’s another question. Comparing Maven to ant is almost too easy in terms of advantages. Is gradle now a serious competitor (I had been working on converting an enormous project to maven, but the architect decided to switch to gradle, so I am particularly sensitive to the issue). I can see some superficial advantages of gradle that might appeal to some projects. Is it better to ignore or address this? The more that can be said to relate Maven to what the reader already knows or is considering, the more useful the paragraph. There is no reason why the following paragraphs could not point deeper into the documentation for comparisons with Ant or Gradle. I would suggest that the first paragraph not include links so that the reader can at least get through one clear section before starting to jump around and get carried off into the world of hyperlinks. Ron On Jan 6, 2014, at 3:02 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Monday, 6 January 2014, Ron Wheeler wrote: I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Yes that is the idea Ron On 06/01/2014 12:57 PM, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: short and snappy description of what Maven is
I missed this earlier - I agree. The biggest advantage I find with Maven over tools that have adopted its dependency management philosophy is that every build essentially follows a predictable pattern, rather than being free form. A new developer automatically knows how to invoke it. That is most definitely not guaranteed to be true with any other build system that I know of. So something like: Maven is a build tool which not only simplifies the common tasks of defining a build, but also makes it easy for new developers to know how to use the created build. On Jan 6, 2014, at 3:02 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Is Gradle a competitor to Maven?
Hi Russell, Russell Gold wrote: Is gradle now a serious competitor (I had been working on converting an enormous project to maven, but the architect decided to switch to gradle, so I am particularly sensitive to the issue). I can see some superficial advantages of gradle that might appeal to some projects. Is it better to ignore or address this? Software architects are faced with a choice between Maven or Gradle (or other systems) when structuring their projects. So I would definitely call them competitors. I am currently in a similar situation to yours, in that the architect of one of the large development teams with which I collaborate prefers Gradle to Maven, and is planning to switch to it rather than Maven itself. Members of that team have a stated dislike Maven's our way or the highway approach to builds, and believe Gradle offers most of Maven's benefits without Maven's (perceived) inflexibility. Gradle produces Maven-compatible artifacts, so this decision is not the end of the world. However, see this thread: http://mail-archives.apache.org/mod_mbox/maven-users/201209.mbox/%3cb8d164bed956c5439875951895cb4b220eee1...@waboth9msgusr8c.itservices.sbc.com%3E I agree with the OP's assessment: One of the disadvantages of Gradle is the same as Ant, which is that it's very easy to have two people do similar things in a completely different way. Gradle makes it easier to reuse things, but it doesn't seem like it nudges you that hard in that direction. So even if Gradle is more beautiful and/or succinct (I wish Maven POMs supported JSON!), I personally like the standardization that Maven brings to the table, especially after having designed relatively complex build systems in Ant and then getting stuck maintaining them for many years. Maven does everything (and much more! extensibly!) that my custom build system does, largely in a much better way, without reinventing the wheel, and hence without new developers suffering another learning curve. Regards, Curtis On Mon, Jan 6, 2014 at 2:08 PM, Russell Gold russell.g...@oracle.comwrote: Several sentences sounds good. But here’s another question. Comparing Maven to ant is almost too easy in terms of advantages. Is gradle now a serious competitor (I had been working on converting an enormous project to maven, but the architect decided to switch to gradle, so I am particularly sensitive to the issue). I can see some superficial advantages of gradle that might appeal to some projects. Is it better to ignore or address this? On Jan 6, 2014, at 3:02 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Monday, 6 January 2014, Ron Wheeler wrote: I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Yes that is the idea Ron On 06/01/2014 12:57 PM, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build
Two Resource Files In Same Dir ... One Having Property Replaced, Another Does Not
Hi there,
I have two resource files in the same dir: a.job and b.job. They have the
following line in both of them:
snip
mongo.home=${mongo.cli.home}
/snip
where mongo.cli.home is a property defined in a filter file.
When I run clean package, a.job gets filtered, the other does not. This is
baffling to me.
When running mvn -X -P staging resources:resources I see this curtailed
output:
[DEBUG] file a.job has a filtered file extension
[DEBUG] filering /Users/adilaijaz/workspace/apps/target/jobs/a.job to
/Users/adilaijaz/workspace/apps/target/classes/jobs/a.job
[DEBUG] file b.job has a filtered file extension
[DEBUG] filering /Users/adilaijaz/workspace/apps/target/jobs/b.job to
/Users/adilaijaz/workspace/apps/target/classes/jobs/b.job
When I look at filtered a.job, I see this output:
snip
mongo.home=/opt/mongo
/snip
And b.job looks like:
snip
mongo.home=${mongo.cli.home}
/snip
I am stumped. Any pointers will be helpful. I am using the following version
of maven:
[adilaijaz@ ~/workspace]$ mvn -version
Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /usr/share/maven
Java version: 1.6.0_41, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x, version: 10.8.2, arch: x86_64, family: mac
--
View this message in context:
http://maven.40175.n5.nabble.com/Two-Resource-Files-In-Same-Dir-One-Having-Property-Replaced-Another-Does-Not-tp5780640.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Jarsigner 1.3.1 Released
The Maven team is pleased to announce the release of the Apache Maven Jarsigner, version 1.3.1 This component provides some utilities to sign/verify jars/files in your Mojos. http://maven.apache.org/shared/maven-jarsigner/ To use the Maven Jarsigner, add the following dependency to your project: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-jarsigner/artifactId version1.3.1/version /dependency Release Notes - Maven Shared Components - Version maven-jarsigner-1.3.1 ** Bug * [MSHARED-315] - Unsign jars are still not ok Enjoy, -The Maven team tony. -- Tony Chemit tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: che...@codelutin.com twitter: https://twitter.com/tchemit - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Jarsigner Plugin 1.3.1 Released
The Maven team is pleased to announce the release of the Maven Jarsigner Plugin, version 1.3.1. This plugin signs and verifies the project artifacts using the jarsigner tool. See the plugin's site for more details: http://maven.apache.org/plugins/maven-jarsigner-plugin/ This plugin is meant to supercede the existing jar:sign and jar:verify goals from the Maven Jar Plugin which will be deprecated in a future release. To use the updated plugin in your projects, you need to add the following snippet to the plugins or plugin management section of your POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jarsigner-plugin/artifactId version1.3.1/version executions ... /executions /plugin Release Notes - Maven Jar Signer Plugin - Version 1.3.1 ** Bug * [MJARSIGNER-33] - Sign already signed jar still does not work Enjoy, The Maven team. -- Tony Chemit tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: che...@codelutin.com twitter: https://twitter.com/tchemit - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Jarsigner Plugin 1.3.1 Released
The Maven team is pleased to announce the release of the Maven Jarsigner Plugin, version 1.3.1. This plugin signs and verifies the project artifacts using the jarsigner tool. See the plugin's site for more details: http://maven.apache.org/plugins/maven-jarsigner-plugin/ This plugin is meant to supercede the existing jar:sign and jar:verify goals from the Maven Jar Plugin which will be deprecated in a future release. To use the updated plugin in your projects, you need to add the following snippet to the plugins or plugin management section of your POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jarsigner-plugin/artifactId version1.3.1/version executions ... /executions /plugin Release Notes - Maven Jar Signer Plugin - Version 1.3.1 ** Bug * [MJARSIGNER-33] - Sign already signed jar still does not work Enjoy, The Maven team. -- Tony Chemit tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: che...@codelutin.com twitter: https://twitter.com/tchemit - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Jarsigner plugin vs Apache Maven Shared Jarsigner
Can someone explain what is the difference between these two plugins. Based on the description, they do the same This plugin signs and verifies the project artifacts using the jarsigner tool. See the plugin's site for more details: vs This component provides some utilities to sign/verify jars/files in your Mojos. What I am actually looking for is a way in maven to UNsign jars. In the release notes of maven shared jarsigner i see a fixed bug [MSHARED-314] - Unsigning a jar is not correct This gives me hope that there is already a way to unsign jars but i can't find how to do it Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: Maven Jarsigner plugin vs Apache Maven Shared Jarsigner
Ok, forget about the first question. I get know what is meant by shared. i usually call this common so i missed it. But still, the second question remains: how to just clear all signatures from a jar. The removeExistingSignatures parameter states that the resulting JAR will appear as being signed only once. whereas i just want to remove any existing signature Alejandro Endo | Software Designer/Concepteur de logiciels From: Alejandro Endo/MontrealMIR/BeldenCDT To: users@maven.apache.org, Date: 2014-01-06 03:58 PM Subject:Maven Jarsigner plugin vs Apache Maven Shared Jarsigner Can someone explain what is the difference between these two plugins. Based on the description, they do the same This plugin signs and verifies the project artifacts using the jarsigner tool. See the plugin's site for more details: vs This component provides some utilities to sign/verify jars/files in your Mojos. What I am actually looking for is a way in maven to UNsign jars. In the release notes of maven shared jarsigner i see a fixed bug [MSHARED-314] - Unsigning a jar is not correct This gives me hope that there is already a way to unsign jars but i can't find how to do it Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: short and snappy description of what Maven is
I don't want a religious war. If Gradle or ANT are a better fit for the way some people think about building software... well good for them... and the faster we can help them realise that Maven takes a different tack the better. I happen to believe that the power of Maven comes from being model driven rather than procedural, which ultimately allows for a richer IDE experience, but consequently you lose some flexibility in your build process. It is a tradeoff I happen to like the Maven balance of, but I am not so arrogant to presume that Maven's balance suits everyone. The Maven repository has grown beyond just Maven, so that is no longer a key differentiator for Maven. The differentiator is in the declarative build rather than procedural build... With Ant you have a mostly pure procedural build. With Maven you have a mostly pure declarative build. With Gradle you have a hodge-podge mix of both. (By declarative, I mean packagingjar/packaging is all I need to declare, maven knows how everything fits into that) So let's let others go to the tools that suit their tastes, and the faster that we help them there, the less bitching about how Maven is crap (because it doesn't suit my taste) we will hear. It's like marmite: you either love it or hate it! On 6 January 2014 20:08, Russell Gold russell.g...@oracle.com wrote: Several sentences sounds good. But here’s another question. Comparing Maven to ant is almost too easy in terms of advantages. Is gradle now a serious competitor (I had been working on converting an enormous project to maven, but the architect decided to switch to gradle, so I am particularly sensitive to the issue). I can see some superficial advantages of gradle that might appeal to some projects. Is it better to ignore or address this? On Jan 6, 2014, at 3:02 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Monday, 6 January 2014, Ron Wheeler wrote: I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Yes that is the idea Ron On 06/01/2014 12:57 PM, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Maven Jarsigner plugin vs Apache Maven Shared Jarsigner
maven-jarsigner-plugin is a plugin apache maven shared jarsigner is the common dependency that is used by the plugin... because signing jars is something that other plugins may want to do, this dependency provides an API to do that signing On 6 January 2014 20:56, alejandro.e...@miranda.com wrote: Can someone explain what is the difference between these two plugins. Based on the description, they do the same This plugin signs and verifies the project artifacts using the jarsigner tool. See the plugin's site for more details: vs This component provides some utilities to sign/verify jars/files in your Mojos. What I am actually looking for is a way in maven to UNsign jars. In the release notes of maven shared jarsigner i see a fixed bug [MSHARED-314] - Unsigning a jar is not correct This gives me hope that there is already a way to unsign jars but i can't find how to do it Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: Maven Central Opinion
Hi Tommy et al, here's another option for you: You can leverage bintray.com to sync to Maven Central from there. For starter, you'll just get your artifacts to Maven Central in more sane way - no parent poms, no maven-release-plugin, no 20 pages guides. Just get your artifacts to Bintray, include them in the JCenter repo (which is a superset of central, btw), and voila, once your pom is good (all the needed tags like description, developers, etc), your artifacts are in Central. But that's just a start. You'll probably discover some nice features of Bintray by its own merit - near real-time stats, packages watching and inclusion, organizations support, fast CDN downloads, etc. Anyway, give it a try, your opinion on a painful Maven Central onboading might change. Baruch. P.S. I am very much affiliated with Bintray and proud of it :) -- JFrog Developer Advocate www.jfrog.com +972544954353F @jbaruch https://twitter.com/jbaruch/ http://linkd.in/jbaruch http://jax.de/node/901 I am assuming that you are putting this in Central so I can easily use it without having to worry about the effect on my build process or without having to get into your sources and dependencies to build my app and I have appropriate license agreements included so I know what I am incorporating into my app. In that case, I would like you to follow the Maven Best Practices for deploying to Central. Using the Release plug-in may save you some steps if you do not already have a private repo for releasing software internally. It seems to me that if you are already releasing to your own repo prior to trying to upload it to Central, you are probably going to find that the Release plug-in is not the best practice. We would be in the same situation if we ever decided to put some of our utilities into Maven Central. We have already done the release and our SCM is in the state in which we want it. We would probably have to look at our parent POM/child POM structure to be sure that it met Maven Central requirements. I think that you did the right thing by raising your concerns here and I think that you got some very good advice and concrete suggestions. This is a very good group that is usually well-mannered when approached in the way that you did. You were very clear about what you wanted to do and you raised very specified issues that you wanted to discuss. You also reacted to the advice in a positive way that encouraged a factual discussion rather than a personal attack. Ron On 06/01/2014 7:49 AM, Tommy Svensson wrote: Hello again, OK, I suspected that I get a lot of replies on this :-). From experience in other forums I also expected to have people tell me to go screw myself, but that has not happened. There are apparently only professionals here! That said, there some very good replies and explanations but also some I do react to. I'll start with the latter. The arguments about quality I just don't buy. We are only talking poms here. Whatever is in the poms says nothing about the quality of the software itself. What is really bothering me however is the argument that if you don't have your things in the way we think they should be, you are not serious enough. It hasn't been said straight out but implied. The word that pops into my head here is Moralizing! I take my work very seriously and I take my open source work even more seriously (since in that case I'm allowed the time for it :-)). That if I have one file that is not up to someones liking I'm not taking releasing of my software seriously is just absurd. ___ From one of the replies: As I said in a previous message, deploying to the remote repo is just a matter of mvn deploy, using either the maven-deploy-plugin (by default) or the nexus-staging-maven-plugin. That is good, that is how easy it should be! You'll have to configure the GPG plugin to sign your artifacts though, as it's a requirement to deploy to Central. No problem! I'm going to go though the documentation again and solve the easy way to do it :-). And If I can't find a page that explains this clearly I will create such! I have gotten very much information here to go on. Someone also pointed out that local webserver repositories are good enough for small projects. I basically agree with that. I only considered maven central since someone asked me. But it is easier to have things in central and not have to add multiple repository specifications in your pom/settings. OK, you can use nexus to merge several repositories into one and then use that. But if submission to central can be made easy then it is worth to do it. Software does not have to be large apache projects to be useful. There are some truly useful software out there that comes from single individuals. Here is my view of how I would want a maven repository to be: - No requirements of javadoc or sources. If you want to include those, no problem, but if you
Re: short and snappy description of what Maven is
Le 6 janv. 2014 22:34, Stephen Connolly stephen.alan.conno...@gmail.com a écrit : I don't want a religious war. If Gradle or ANT are a better fit for the way some people think about building software... well good for them... and the faster we can help them realise that Maven takes a different tack the better. I happen to believe that the power of Maven comes from being model driven rather than procedural, which ultimately allows for a richer IDE experience, but consequently you lose some flexibility in your build process. It is a tradeoff I happen to like the Maven balance of, but I am not so arrogant to presume that Maven's balance suits everyone. The Maven repository has grown beyond just Maven, so that is no longer a key differentiator for Maven. The differentiator is in the declarative build rather than procedural build... I disagree (when comparing with Gradle). The differentiator to me is going beyond the build tool: project management and comprehension tool. Things like the m-release-p, m-scm-p, m-site-p, etc. No other tool has those AFAICT, and not everybody wants or needs them. On the negative side: linear lifecycle, fixed number of classpaths (scopes) that forces you to use separate modules (not a problem per se) thus put files in separate folder trees (more of an issue, even if it means losing IDE support), etc. Many of which contribute to making it really hard to migrate from Ant to Maven. With Ant you have a mostly pure procedural build. With Maven you have a mostly pure declarative build. With Gradle you have a hodge-podge mix of both. (By declarative, I mean packagingjar/packaging is all I need to declare, maven knows how everything fits into that) apply plugin: java is all you need to declare in Gradle ;-) (OK, you also need a couple other lines to deploy to a Maven or Ivy repo, but no more than in a POM) So let's let others go to the tools that suit their tastes, and the faster that we help them there, the less bitching about how Maven is crap (because it doesn't suit my taste) we will hear. It's like marmite: you either love it or hate it! On 6 January 2014 20:08, Russell Gold russell.g...@oracle.com wrote: Several sentences sounds good. But here’s another question. Comparing Maven to ant is almost too easy in terms of advantages. Is gradle now a serious competitor (I had been working on converting an enormous project to maven, but the architect decided to switch to gradle, so I am particularly sensitive to the issue). I can see some superficial advantages of gradle that might appeal to some projects. Is it better to ignore or address this? On Jan 6, 2014, at 3:02 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Monday, 6 January 2014, Ron Wheeler wrote: I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Yes that is the idea Ron On 06/01/2014 12:57 PM, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Siteit says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool.
Re: short and snappy description of what Maven is
On 6 January 2014 22:18, Thomas Broyer t.bro...@gmail.com wrote: Le 6 janv. 2014 22:34, Stephen Connolly stephen.alan.conno...@gmail.com a écrit : I don't want a religious war. If Gradle or ANT are a better fit for the way some people think about building software... well good for them... and the faster we can help them realise that Maven takes a different tack the better. I happen to believe that the power of Maven comes from being model driven rather than procedural, which ultimately allows for a richer IDE experience, but consequently you lose some flexibility in your build process. It is a tradeoff I happen to like the Maven balance of, but I am not so arrogant to presume that Maven's balance suits everyone. The Maven repository has grown beyond just Maven, so that is no longer a key differentiator for Maven. The differentiator is in the declarative build rather than procedural build... I disagree (when comparing with Gradle). The differentiator to me is going beyond the build tool: project management and comprehension tool. Things like the m-release-p, m-scm-p, m-site-p, etc. No other tool has those AFAICT, and not everybody wants or needs them. On the negative side: linear lifecycle, fixed number of classpaths (scopes) that forces you to use separate modules (not a problem per se) thus put files in separate folder trees (more of an issue, even if it means losing IDE support), etc. Many of which contribute to making it really hard to migrate from Ant to Maven. With Ant you have a mostly pure procedural build. With Maven you have a mostly pure declarative build. With Gradle you have a hodge-podge mix of both. (By declarative, I mean packagingjar/packaging is all I need to declare, maven knows how everything fits into that) apply plugin: java is all you need to declare in Gradle ;-) (OK, you also need a couple other lines to deploy to a Maven or Ivy repo, but no more than in a POM) *but* if you see a maven build, you know it pretty much has to be declarative... if you see a gradle build it can add a whole procedural set of steps quite trivially on top.. (you can also add procedural stuff to maven, but it is hard and ugly because of the syntax and the way maven forces you to work) Basically I view the main advantage of gradle as it's main disadvantage... others are free to invert that point of view if/as they see fit, but I have yet to see the benefits of the flexibility that gradle adds... I have only seen downsides... I'll not go ramming my PoV down your mouth... as long as you don't try and ram your PoV down mine ;-) So let's let others go to the tools that suit their tastes, and the faster that we help them there, the less bitching about how Maven is crap (because it doesn't suit my taste) we will hear. It's like marmite: you either love it or hate it! On 6 January 2014 20:08, Russell Gold russell.g...@oracle.com wrote: Several sentences sounds good. But here’s another question. Comparing Maven to ant is almost too easy in terms of advantages. Is gradle now a serious competitor (I had been working on converting an enormous project to maven, but the architect decided to switch to gradle, so I am particularly sensitive to the issue). I can see some superficial advantages of gradle that might appeal to some projects. Is it better to ignore or address this? On Jan 6, 2014, at 3:02 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Monday, 6 January 2014, Ron Wheeler wrote: I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Yes that is the idea Ron On 06/01/2014 12:57 PM, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my
Re: short and snappy description of what Maven is
Le 6 janv. 2014 23:25, Stephen Connolly stephen.alan.conno...@gmail.com a écrit : On 6 January 2014 22:18, Thomas Broyer t.bro...@gmail.com wrote: Le 6 janv. 2014 22:34, Stephen Connolly stephen.alan.conno...@gmail.com a écrit : I don't want a religious war. If Gradle or ANT are a better fit for the way some people think about building software... well good for them... and the faster we can help them realise that Maven takes a different tack the better. I happen to believe that the power of Maven comes from being model driven rather than procedural, which ultimately allows for a richer IDE experience, but consequently you lose some flexibility in your build process. It is a tradeoff I happen to like the Maven balance of, but I am not so arrogant to presume that Maven's balance suits everyone. The Maven repository has grown beyond just Maven, so that is no longer a key differentiator for Maven. The differentiator is in the declarative build rather than procedural build... I disagree (when comparing with Gradle). The differentiator to me is going beyond the build tool: project management and comprehension tool. Things like the m-release-p, m-scm-p, m-site-p, etc. No other tool has those AFAICT, and not everybody wants or needs them. On the negative side: linear lifecycle, fixed number of classpaths (scopes) that forces you to use separate modules (not a problem per se) thus put files in separate folder trees (more of an issue, even if it means losing IDE support), etc. Many of which contribute to making it really hard to migrate from Ant to Maven. With Ant you have a mostly pure procedural build. With Maven you have a mostly pure declarative build. With Gradle you have a hodge-podge mix of both. (By declarative, I mean packagingjar/packaging is all I need to declare, maven knows how everything fits into that) apply plugin: java is all you need to declare in Gradle ;-) (OK, you also need a couple other lines to deploy to a Maven or Ivy repo, but no more than in a POM) *but* if you see a maven build, you know it pretty much has to be declarative... if you see a gradle build it can add a whole procedural set of steps quite trivially on top.. Ack. (you can also add procedural stuff to maven, but it is hard and ugly because of the syntax and the way maven forces you to work) Basically I view the main advantage of gradle as it's main disadvantage... others are free to invert that point of view if/as they see fit, but I have yet to see the benefits of the flexibility that gradle adds... I have only seen downsides... I'll not go ramming my PoV down your mouth... as long as you don't try and ram your PoV down mine ;-) I respect your PoV ;-) So let's let others go to the tools that suit their tastes, and the faster that we help them there, the less bitching about how Maven is crap (because it doesn't suit my taste) we will hear. It's like marmite: you either love it or hate it! On 6 January 2014 20:08, Russell Gold russell.g...@oracle.com wrote: Several sentences sounds good. But here’s another question. Comparing Maven to ant is almost too easy in terms of advantages. Is gradle now a serious competitor (I had been working on converting an enormous project to maven, but the architect decided to switch to gradle, so I am particularly sensitive to the issue). I can see some superficial advantages of gradle that might appeal to some projects. Is it better to ignore or address this? On Jan 6, 2014, at 3:02 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Monday, 6 January 2014, Ron Wheeler wrote: I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Yes that is the idea
Re: Misunderstanding modules: Two or more projects in the reactor have the same identifier
Barrie Treloar wrote When you build Product X the libraries A, B and C should already exist. You dont want to rebuild them just to build Product X, that will slow down your development process. Ideally A, B, and C are released versions, but if you find a bug in them then you will be using SNAPSHOT versions, which will need to be released separately prior to releasing Product X. If developers are rarely touching the libraries then its better to let your continuous build system (e.g. Jenkins) build the libraries and Maven will automatically pull down the latest SNAPSHOT for you. This way Developer D can fix a bug in A and Developer E will automatically get the bug fix the next time they pull down the SNAPSHOT build of library A, they no longer need to resync and manually build. You can configure how often Maven will check for a snapshot update (see updatePolicy http://maven.apache.org/ref/3.0.3/maven-settings/settings.html#class_snapshots) With a continuous build system in place whenever C changes it will automatically schedule a build for A and B, run your unit tests and report success or failure. It should also then build Product X and Y for you (since a downstream dependency changed), again running your unit tests. You will also want a Repository Manager so that it can keep some control over how many SNAPSHOT versions to keep (otherwise you can find yourself running out of disk space) Hope this helps some. I understand the need to treat internally-developed dependencies as actual dependencies rather than forcing them to be modules, but I'm having some problems with the workflow. When the project is relatively new and the internally-developed dependency A is no where near being mature, nearly every change being made to Project X requires a corresponding change to A. At this point in the development cycle (and for many months in the foreseeable future) I actually /do/ need to rebuild A every time I build X. I can setup our CI system so that A SNAPSHOTS are built and published to Nexus after every commit, but what about during development, before I'm ready commit my changes? Am I stuck with what my IDE provides? We have developers using a wide range of IDEs, or no IDE at all, so I was hoping that Maven itself would have some way of kicking off builds of downstream dependency A when X is built, if in fact that's what I want to do. Right now we're simply telling folks to build A, then build X. And this certainly makes sense when you step back and think about it... it's just not terribly convenient. -- View this message in context: http://maven.40175.n5.nabble.com/Misunderstanding-modules-Two-or-more-projects-in-the-reactor-have-the-same-identifier-tp4614001p5780688.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Misunderstanding modules: Two or more projects in the reactor have the same identifier
On 7 January 2014 09:42, erich8 eric.herrm...@intermedix.com wrote: Barrie Treloar wrote When you build Product X the libraries A, B and C should already exist. You dont want to rebuild them just to build Product X, that will slow down your development process. Ideally A, B, and C are released versions, but if you find a bug in them then you will be using SNAPSHOT versions, which will need to be released separately prior to releasing Product X. If developers are rarely touching the libraries then its better to let your continuous build system (e.g. Jenkins) build the libraries and Maven will automatically pull down the latest SNAPSHOT for you. This way Developer D can fix a bug in A and Developer E will automatically get the bug fix the next time they pull down the SNAPSHOT build of library A, they no longer need to resync and manually build. You can configure how often Maven will check for a snapshot update (see updatePolicy http://maven.apache.org/ref/3.0.3/maven-settings/settings.html#class_snapshots) With a continuous build system in place whenever C changes it will automatically schedule a build for A and B, run your unit tests and report success or failure. It should also then build Product X and Y for you (since a downstream dependency changed), again running your unit tests. You will also want a Repository Manager so that it can keep some control over how many SNAPSHOT versions to keep (otherwise you can find yourself running out of disk space) Hope this helps some. I understand the need to treat internally-developed dependencies as actual dependencies rather than forcing them to be modules, but I'm having some problems with the workflow. When the project is relatively new and the internally-developed dependency A is no where near being mature, nearly every change being made to Project X requires a corresponding change to A. At this point in the development cycle (and for many months in the foreseeable future) I actually /do/ need to rebuild A every time I build X. I can setup our CI system so that A SNAPSHOTS are built and published to Nexus after every commit, but what about during development, before I'm ready commit my changes? Am I stuck with what my IDE provides? We have developers using a wide range of IDEs, or no IDE at all, so I was hoping that Maven itself would have some way of kicking off builds of downstream dependency A when X is built, if in fact that's what I want to do. Ideally you want your development to be only against releases, but as you notice in the early days that just can't happen. One thing I neglected to mention is that publishing SNAPSHOT to a repository can be a pain. The reason is that while you are happily working with your artifacts, if a new SNAPSHOT is published and Maven decides to start downloading it then you can find your local development hosed by bugs in the new SNAPSHOT. Obviously there is a trade-off here. You want to see bugs quickly so that you can get them fixed correctly - either your code, or the dependency. But you can also waste a lot of time if you have people checking in things that cause breakage all the time (perhaps you then need to investigate why that is occurring and deal with that as well). You should be able to manage this with the --no-snapshot-updates option so you can when you want to pull in newer SNAPSHOTS. Just remember that you may have to rebuild your code again so that your local .m2 cache has your code changes in it and not the CI version. The next thing to ask is who is making the changes to A and X. If it is the same person then they dont need Maven yet. They can build via the command line, IDE, whatever. I prefer to let the IDE (Eclipse in my case) handle the incremental build problems. I keep working on whatever projects I need until they are ready to commit into version control and the IDE will ensure that everything is building correctly so I can run my unit tests, etc all in the IDE. I'm not using Maven at all here. Before I commit this to version control, then I break out Maven and build the projects in the correct order and ensure everything works. Once committed to version control then CI will publish the SNAPSHOTS and other developers can then decide when they want to start using the new SNAPSHOTS. Right now we're simply telling folks to build A, then build X. And this certainly makes sense when you step back and think about it... it's just not terribly convenient. If those folks are working on A and X they dont have any other options, they want to build their code with their changes and not suddenly get something from CI (which obviously can not have their changes in it). For those working with IDEs they should be able to just work in the IDE. I'm fairly sure there is Maven integration with m2e like features in NetBeans and IDEA. I dont understand how you can efficiently develop without an IDE and I'm not prepared to spend any of my time trying to help them
Re: short and snappy description of what Maven is
I am not sure that you want to start a range war in the opening paragraph. If there is a concise second or third sentence that clearly explains the difference between Ant and Maven, it would be a great idea to add that. If Gradle is likely to be in the running for a new developer, it might be interesting to have a sentence explaining the difference. Need to be careful not to turn off a new person by an obscure argument that does not address the decision points in a way that a new person would understand. Ron On 06/01/2014 4:33 PM, Stephen Connolly wrote: I don't want a religious war. If Gradle or ANT are a better fit for the way some people think about building software... well good for them... and the faster we can help them realise that Maven takes a different tack the better. I happen to believe that the power of Maven comes from being model driven rather than procedural, which ultimately allows for a richer IDE experience, but consequently you lose some flexibility in your build process. It is a tradeoff I happen to like the Maven balance of, but I am not so arrogant to presume that Maven's balance suits everyone. The Maven repository has grown beyond just Maven, so that is no longer a key differentiator for Maven. The differentiator is in the declarative build rather than procedural build... With Ant you have a mostly pure procedural build. With Maven you have a mostly pure declarative build. With Gradle you have a hodge-podge mix of both. (By declarative, I mean packagingjar/packaging is all I need to declare, maven knows how everything fits into that) So let's let others go to the tools that suit their tastes, and the faster that we help them there, the less bitching about how Maven is crap (because it doesn't suit my taste) we will hear. It's like marmite: you either love it or hate it! On 6 January 2014 20:08, Russell Gold russell.g...@oracle.com wrote: Several sentences sounds good. But here’s another question. Comparing Maven to ant is almost too easy in terms of advantages. Is gradle now a serious competitor (I had been working on converting an enormous project to maven, but the architect decided to switch to gradle, so I am particularly sensitive to the issue). I can see some superficial advantages of gradle that might appeal to some projects. Is it better to ignore or address this? On Jan 6, 2014, at 3:02 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Monday, 6 January 2014, Ron Wheeler wrote: I think that the target has to be people deciding whether to try Maven. They initially want to know what it does and why it is better than Ant or whatever they are using now. Trying to teach Maven in a single sentence is too much to ask. Maven is a build tool which consumes and produces artifacts managed in a repository. doesn't sound like it will help build my application. At the start, one doesn't have any artifacts or own a repository. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I think we should hint at the descriptive philosophy rather than the procedural philosophy most tools take is pretty clear for a single sentence description and it true. Maybe we can come up with a follow-up sentence to amplify/explain this one. Most programmers or project managers should be able to find the time to read 2 or maybe 3 sentences before deciding on a build tool. As long as each sentence draws the person deeper into Maven, that would work. Yes that is the idea Ron On 06/01/2014 12:57 PM, Russell Gold wrote: Of course, you could say that about Gradle, too. And ant now does have the ability to use those dependency features. I went through this when creating my video course (not in the sig because this is work email). It’s not clear to me that you can make a one sentence description that will provide sufficiently useful information unless something like: Maven is a build tool which consumes and produces artifacts managed in a repository. But that is not going to help people coming new to the project. I think I am missing the motivation here.Is the target for this description people deciding whether to try Maven? People trying to learn how to use it? On Jan 6, 2014, at 12:43 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: on https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site it says: We need a short and snappy description of what Maven is: Apache Maven is a software project management and comprehension tool. Is just not an easy to understand description of what Maven is. I would like to submit my short description for review. Apache Maven is a convention-over-configuration build tool which has great dependency management features. I know that it does more than that - but I feel that at its core, this is what it really is. - -- Ron Wheeler President Artifact Software Inc email:
Re: Misunderstanding modules: Two or more projects in the reactor have the same identifier
During active development, we have found that libraries A,B and C should be released as SNAPSHOTs with a spec and warranty from the developer. These may be informal but without this, the developer of X has a hard time testing if A,B and C are changing specification/behaviour without warning. This implies that there is a series of stubs for methods in A,B and C that are not complete. If it is not possible for the developers of A,B and C to do this, the developer of X needs to program to interfaces of A,B and C and find a way (DI for instance ) of substituting is own versions (stubs) of A,B and C for testing while A,B and C are being developed to a point where they are suitable for testing and can be released as SNAPSHOTS with specs and warranties. Otherwise the developer of X will waste a lot of time debugging the intermediate versions of A, B and C rather than focusing on X. While debugging, the developer of X will never know whether changes to X are not working or changes to the behaviour of X are caused by undocumented changes to the dependencies. Ron On 06/01/2014 6:12 PM, erich8 wrote: Barrie Treloar wrote When you build Product X the libraries A, B and C should already exist. You dont want to rebuild them just to build Product X, that will slow down your development process. Ideally A, B, and C are released versions, but if you find a bug in them then you will be using SNAPSHOT versions, which will need to be released separately prior to releasing Product X. If developers are rarely touching the libraries then its better to let your continuous build system (e.g. Jenkins) build the libraries and Maven will automatically pull down the latest SNAPSHOT for you. This way Developer D can fix a bug in A and Developer E will automatically get the bug fix the next time they pull down the SNAPSHOT build of library A, they no longer need to resync and manually build. You can configure how often Maven will check for a snapshot update (see updatePolicy http://maven.apache.org/ref/3.0.3/maven-settings/settings.html#class_snapshots) With a continuous build system in place whenever C changes it will automatically schedule a build for A and B, run your unit tests and report success or failure. It should also then build Product X and Y for you (since a downstream dependency changed), again running your unit tests. You will also want a Repository Manager so that it can keep some control over how many SNAPSHOT versions to keep (otherwise you can find yourself running out of disk space) Hope this helps some. I understand the need to treat internally-developed dependencies as actual dependencies rather than forcing them to be modules, but I'm having some problems with the workflow. When the project is relatively new and the internally-developed dependency A is no where near being mature, nearly every change being made to Project X requires a corresponding change to A. At this point in the development cycle (and for many months in the foreseeable future) I actually /do/ need to rebuild A every time I build X. I can setup our CI system so that A SNAPSHOTS are built and published to Nexus after every commit, but what about during development, before I'm ready commit my changes? Am I stuck with what my IDE provides? We have developers using a wide range of IDEs, or no IDE at all, so I was hoping that Maven itself would have some way of kicking off builds of downstream dependency A when X is built, if in fact that's what I want to do. Right now we're simply telling folks to build A, then build X. And this certainly makes sense when you step back and think about it... it's just not terribly convenient. -- View this message in context: http://maven.40175.n5.nabble.com/Misunderstanding-modules-Two-or-more-projects-in-the-reactor-have-the-same-identifier-tp4614001p5780688.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Misunderstanding modules: Two or more projects in the reactor have the same identifier
When the project is relatively new and the internally-developed dependency A is no where near being mature, nearly every change being made to Project X requires a corresponding change to A. At this point in the development cycle (and for many months in the foreseeable future) I actually /do/ need to rebuild A every time I build X. What I've often done here is create a new workspace area that contains symlinks ( or git submodule checkouts ) of each of the modules I'm working on, and having a simple pom.xml in the top level that sets up a reactor build, then just build that. signature.asc Description: OpenPGP digital signature
Re: Misunderstanding modules: Two or more projects in the reactor have the same identifier
On 7 January 2014 15:29, Mark Derricutt m...@talios.com wrote: When the project is relatively new and the internally-developed dependency A is no where near being mature, nearly every change being made to Project X requires a corresponding change to A. At this point in the development cycle (and for many months in the foreseeable future) I actually /do/ need to rebuild A every time I build X. What I've often done here is create a new workspace area that contains symlinks ( or git submodule checkouts ) of each of the modules I'm working on, and having a simple pom.xml in the top level that sets up a reactor build, then just build that. There was also some talk about automating this step. But its vapourware at the moment. It would work by checking your current pom for any -SNAPSHOT dependencies and then pulling out the source code for those and sitting them in the parent directory. And as you say the parent pom is just a helper that has a bunch of modules to make building things easier - and you would never check that pom into version control. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
