Regarding Archetype customization
I have a question regarding Archetype customization. Consider i have two files FILE1.java and FILE2.java , How can i customize my archetype-metadata.xml so that , according to my choice i can select FILE1.java or FILE2.java at the time of mvn archetype:generate. Is it possible ? Can you send me related tutorial or working tutorial? Regards -Goutham -- View this message in context: http://maven.40175.n5.nabble.com/Regarding-Archetype-customization-tp4494131p4494131.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Enforcer Plugin version 1.0.1 - Vote Cancelled
Isn't the correct staging site here:? http://maven.apache.org/plugins/maven-enforcer-plugin-1.0.1/ It got deployed by you yesterday... HTH, -Lukas Kristian Rosenvold wrote: There is something weird with the multi-module site in enforcer. I don't have the time to debug this one at the moment so I'm cancelling the enforcer vote instead of keeping you all in suspense. Kristian On Wed, Jun 15, 2011 at 8:48 PM, Karl Heinz Marbaisekhmarba...@gmx.de wrote: Hi, Also the Custom Rules - Writing a custom rule produces the same... after waiting a full day nothing changed...which means the missing pages are there... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Enforcer Plugin version 1.0.1 - Vote Cancelled
Well yes, it's there, but the left-hand menu items point to the current production version instead of the newly staged versions. This seems to be because the xref between the plugin (with a specific url) and the remaining enforcere modules (with a different url) does not work when staging. If I stage locally and just copy everything manually to a single folder it works. This looks like it'll work if I did the production release, but the cross reference links in site.xml uses relative adressing to link from the plugin to the enforcer rules. I'm a bit at loss at what is the correct way to fix it. Kristian Den 16.06.2011 11:17, skrev Lukas Theussl: Isn't the correct staging site here:? http://maven.apache.org/plugins/maven-enforcer-plugin-1.0.1/ It got deployed by you yesterday... HTH, -Lukas Kristian Rosenvold wrote: There is something weird with the multi-module site in enforcer. I don't have the time to debug this one at the moment so I'm cancelling the enforcer vote instead of keeping you all in suspense. Kristian On Wed, Jun 15, 2011 at 8:48 PM, Karl Heinz Marbaisekhmarba...@gmx.de wrote: Hi, Also the Custom Rules - Writing a custom rule produces the same... after waiting a full day nothing changed...which means the missing pages are there... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Enforcer Plugin version 1.0.1 - Vote Cancelled
Somewhat confused now: is this vote for the enforcer-plugin alone? Ie did you only stage-deploy the plugin site or the whole enforcer site? (I suppose this needs to be released and voted on as well?) The plugin site uses relative links in the menu that lead out of the current project, so these links will get broken if different modules get stage-deployed to different locations, as seems to be the case here. My guess is that using site-plugin-2.3 should fix the problem (and stage-deploy of a multi-module project is a real pain with 2.2 anyway...), but in any case you need to stage-deploy the whole enforcer site if the relative links should work. HTH, -Lukas Kristian Rosenvold wrote: Well yes, it's there, but the left-hand menu items point to the current production version instead of the newly staged versions. This seems to be because the xref between the plugin (with a specific url) and the remaining enforcere modules (with a different url) does not work when staging. If I stage locally and just copy everything manually to a single folder it works. This looks like it'll work if I did the production release, but the cross reference links in site.xml uses relative adressing to link from the plugin to the enforcer rules. I'm a bit at loss at what is the correct way to fix it. Kristian Den 16.06.2011 11:17, skrev Lukas Theussl: Isn't the correct staging site here:? http://maven.apache.org/plugins/maven-enforcer-plugin-1.0.1/ It got deployed by you yesterday... HTH, -Lukas Kristian Rosenvold wrote: There is something weird with the multi-module site in enforcer. I don't have the time to debug this one at the moment so I'm cancelling the enforcer vote instead of keeping you all in suspense. Kristian On Wed, Jun 15, 2011 at 8:48 PM, Karl Heinz Marbaisekhmarba...@gmx.de wrote: Hi, Also the Custom Rules - Writing a custom rule produces the same... after waiting a full day nothing changed...which means the missing pages are there... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Enforcer Plugin version 1.0.1 - Vote Cancelled
PS: I don't think that's a reason to cancel the vote, the links will be correct on the final site. -Lukas Kristian Rosenvold wrote: Well yes, it's there, but the left-hand menu items point to the current production version instead of the newly staged versions. This seems to be because the xref between the plugin (with a specific url) and the remaining enforcere modules (with a different url) does not work when staging. If I stage locally and just copy everything manually to a single folder it works. This looks like it'll work if I did the production release, but the cross reference links in site.xml uses relative adressing to link from the plugin to the enforcer rules. I'm a bit at loss at what is the correct way to fix it. Kristian Den 16.06.2011 11:17, skrev Lukas Theussl: Isn't the correct staging site here:? http://maven.apache.org/plugins/maven-enforcer-plugin-1.0.1/ It got deployed by you yesterday... HTH, -Lukas Kristian Rosenvold wrote: There is something weird with the multi-module site in enforcer. I don't have the time to debug this one at the moment so I'm cancelling the enforcer vote instead of keeping you all in suspense. Kristian On Wed, Jun 15, 2011 at 8:48 PM, Karl Heinz Marbaisekhmarba...@gmx.de wrote: Hi, Also the Custom Rules - Writing a custom rule produces the same... after waiting a full day nothing changed...which means the missing pages are there... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Enforcer Plugin version 1.0.1 - Vote Cancelled
I tried to deploy the whole enforcer project (so I suppose the vote topic was incorrect). I did stage-deploy of the whole enforcer project, but if you're looking at what files I managed to upload yesterday, you'll probably see a number of different attempts. I'll try tonight with 2.3 and restart vote (with proper topic) if it works. Kristian Den 16.06.2011 11:36, skrev Lukas Theussl: Somewhat confused now: is this vote for the enforcer-plugin alone? Ie did you only stage-deploy the plugin site or the whole enforcer site? (I suppose this needs to be released and voted on as well?) The plugin site uses relative links in the menu that lead out of the current project, so these links will get broken if different modules get stage-deployed to different locations, as seems to be the case here. My guess is that using site-plugin-2.3 should fix the problem (and stage-deploy of a multi-module project is a real pain with 2.2 anyway...), but in any case you need to stage-deploy the whole enforcer site if the relative links should work. HTH, -Lukas Kristian Rosenvold wrote: Well yes, it's there, but the left-hand menu items point to the current production version instead of the newly staged versions. This seems to be because the xref between the plugin (with a specific url) and the remaining enforcere modules (with a different url) does not work when staging. If I stage locally and just copy everything manually to a single folder it works. This looks like it'll work if I did the production release, but the cross reference links in site.xml uses relative adressing to link from the plugin to the enforcer rules. I'm a bit at loss at what is the correct way to fix it. Kristian Den 16.06.2011 11:17, skrev Lukas Theussl: Isn't the correct staging site here:? http://maven.apache.org/plugins/maven-enforcer-plugin-1.0.1/ It got deployed by you yesterday... HTH, -Lukas Kristian Rosenvold wrote: There is something weird with the multi-module site in enforcer. I don't have the time to debug this one at the moment so I'm cancelling the enforcer vote instead of keeping you all in suspense. Kristian On Wed, Jun 15, 2011 at 8:48 PM, Karl Heinz Marbaisekhmarba...@gmx.de wrote: Hi, Also the Custom Rules - Writing a custom rule produces the same... after waiting a full day nothing changed...which means the missing pages are there... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Enforcer Plugin version 1.0.1 - Vote Cancelled
I'm cancelling until I'm satisifed (or exhausted from trying) ;) Kristian Den 16.06.2011 11:41, skrev Lukas Theussl: PS: I don't think that's a reason to cancel the vote, the links will be correct on the final site. -Lukas Kristian Rosenvold wrote: Well yes, it's there, but the left-hand menu items point to the current production version instead of the newly staged versions. This seems to be because the xref between the plugin (with a specific url) and the remaining enforcere modules (with a different url) does not work when staging. If I stage locally and just copy everything manually to a single folder it works. This looks like it'll work if I did the production release, but the cross reference links in site.xml uses relative adressing to link from the plugin to the enforcer rules. I'm a bit at loss at what is the correct way to fix it. Kristian Den 16.06.2011 11:17, skrev Lukas Theussl: Isn't the correct staging site here:? http://maven.apache.org/plugins/maven-enforcer-plugin-1.0.1/ It got deployed by you yesterday... HTH, -Lukas Kristian Rosenvold wrote: There is something weird with the multi-module site in enforcer. I don't have the time to debug this one at the moment so I'm cancelling the enforcer vote instead of keeping you all in suspense. Kristian On Wed, Jun 15, 2011 at 8:48 PM, Karl Heinz Marbaisekhmarba...@gmx.de wrote: Hi, Also the Custom Rules - Writing a custom rule produces the same... after waiting a full day nothing changed...which means the missing pages are there... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release version 21 of the parent POM for maven plugins
+1 -Lukas Benson Margulies wrote: Hi, We solved 1 issues: ** Improvement * [MPOM-12] - Update maven-plugins to new org.apache.maven:maven-parent:20 There are no open JIRAs against the maven-plugins parent. http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?r1=1135900r2=1135901diff_format=h Staging repo: https://repository.apache.org/content/repositories/maven-014/ Staging site: http://maven.apache.org/plugins/maven-plugins-21/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release version 21 of the parent POM for maven plugins
+1 LieGrue, strub --- On Thu, 6/16/11, Lukas Theussl ltheu...@apache.org wrote: From: Lukas Theussl ltheu...@apache.org Subject: Re: [VOTE]: release version 21 of the parent POM for maven plugins To: Maven Developers List dev@maven.apache.org Date: Thursday, June 16, 2011, 11:40 AM +1 -Lukas Benson Margulies wrote: Hi, We solved 1 issues: ** Improvement * [MPOM-12] - Update maven-plugins to new org.apache.maven:maven-parent:20 There are no open JIRAs against the maven-plugins parent. http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?r1=1135900r2=1135901diff_format=h Staging repo: https://repository.apache.org/content/repositories/maven-014/ Staging site: http://maven.apache.org/plugins/maven-plugins-21/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
PMC change explanation?
Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMC change explanation?
Only speaking for myself, I would like to stress that I stepped back from the PMC for purely personal reasons. Though it certainly facilitated my decision, the events that occupied the PMC at the time are in no causal relation to my retirement. Said events will hopefully be explained by some representative of the PMC or the Apache board, all maven devs and the community have a right to know what's going on. -Lukas Jeff Jensen wrote: Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven EAR Plugin version 2.6
Hi, The vote has passed with the following result : +1 (binding): Lukas Theussl, Olivier Lamy, Mark Struberg, Vincent Siveton, Stephen Connolly, Stéphane Nicoll I will promote the artifacts to the central repo. S. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMC change explanation?
Jeff, I believe this strictly falls within the purview of the Apache Board to explain. In particular Jim, Doug and Shane. Only the board has the right to reveal the business that has been transacted on private lists. Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop. On Jun 16, 2011, at 9:42 AM, Jeff Jensen wrote: Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown
Re: PMC change explanation?
I find it somewhat bewildering that there is no post of the vote or the results on the dev and users mailing lists I can see. Nor does the web site seem to be updated. http://maven.apache.org/team-list.html I would have expected more transparency from Apache. manfred Jeff, I believe this strictly falls within the purview of the Apache Board to explain. In particular Jim, Doug and Shane. Only the board has the right to reveal the business that has been transacted on private lists. Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop. On Jun 16, 2011, at 9:42 AM, Jeff Jensen wrote: Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Enforcer version 1.0.1 - Take 2
Hi, The release includes the enforcer-plugin, enforcer-rules and enforcer-api modules. The site-staging problems from take 1 were fixed in r1136499. The only diff between this vote and take 1 is the site deployment. We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=16879 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MENFORCER+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-011/ Staging site: http://maven.apache.org/staging/plugins/maven-enforcer-plugin/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: PMC change explanation?
Good Afternoon Manfred from my understanding the maven hierarchy looks like: JASON (aka god) | v Everyone else (pull up a pew) Bedankt, Martin __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 16 Jun 2011 08:24:35 -0700 Subject: Re: PMC change explanation? From: manf...@mosabuam.com To: dev@maven.apache.org CC: bo...@apache.org I find it somewhat bewildering that there is no post of the vote or the results on the dev and users mailing lists I can see. Nor does the web site seem to be updated. http://maven.apache.org/team-list.html I would have expected more transparency from Apache. manfred Jeff, I believe this strictly falls within the purview of the Apache Board to explain. In particular Jim, Doug and Shane. Only the board has the right to reveal the business that has been transacted on private lists. Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop. On Jun 16, 2011, at 9:42 AM, Jeff Jensen wrote: Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: PMC change explanation?
Hm... sure Jason had and still has lots of influence. But so does Linus and so do other BDFL's. Imho the Maven project has tons of good people involved in the community around the core and the plugins. Jason is one of them and there are MANY others. There should be cooperation and open communication happening as much as possible. Clearly there is room for improvement. manfred Good Afternoon Manfred from my understanding the maven hierarchy looks like: JASON (aka god) | v Everyone else (pull up a pew) Bedankt, Martin __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 16 Jun 2011 08:24:35 -0700 Subject: Re: PMC change explanation? From: manf...@mosabuam.com To: dev@maven.apache.org CC: bo...@apache.org I find it somewhat bewildering that there is no post of the vote or the results on the dev and users mailing lists I can see. Nor does the web site seem to be updated. http://maven.apache.org/team-list.html I would have expected more transparency from Apache. manfred Jeff, I believe this strictly falls within the purview of the Apache Board to explain. In particular Jim, Doug and Shane. Only the board has the right to reveal the business that has been transacted on private lists. Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop. On Jun 16, 2011, at 9:42 AM, Jeff Jensen wrote: Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMC change explanation?
Martin, I don't think that your message helps anyone here. Jason's email is a very gracious acknowledgement of the governance of the Apache Software Foundation. The changes in the Maven PMC result from a complex situation, and many people are working hard behind the scenes to resolve that situation. It's not for me to elaborate here. I would join others in appealing for patience. --benson margulies On Thu, Jun 16, 2011 at 3:08 PM, Martin Gainty mgai...@hotmail.com wrote: Good Afternoon Manfred from my understanding the maven hierarchy looks like: JASON (aka god) | v Everyone else (pull up a pew) Bedankt, Martin __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 16 Jun 2011 08:24:35 -0700 Subject: Re: PMC change explanation? From: manf...@mosabuam.com To: dev@maven.apache.org CC: bo...@apache.org I find it somewhat bewildering that there is no post of the vote or the results on the dev and users mailing lists I can see. Nor does the web site seem to be updated. http://maven.apache.org/team-list.html I would have expected more transparency from Apache. manfred Jeff, I believe this strictly falls within the purview of the Apache Board to explain. In particular Jim, Doug and Shane. Only the board has the right to reveal the business that has been transacted on private lists. Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop. On Jun 16, 2011, at 9:42 AM, Jeff Jensen wrote: Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMC change explanation?
Yeah, Jason is a standup guy and that didn't come off very well at all. Whatever is going on I wouldn't worry too much about maven in general. cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 16, 2011 at 14:28, Benson Margulies bimargul...@gmail.com wrote: Martin, I don't think that your message helps anyone here. Jason's email is a very gracious acknowledgement of the governance of the Apache Software Foundation. The changes in the Maven PMC result from a complex situation, and many people are working hard behind the scenes to resolve that situation. It's not for me to elaborate here. I would join others in appealing for patience. --benson margulies On Thu, Jun 16, 2011 at 3:08 PM, Martin Gainty mgai...@hotmail.com wrote: Good Afternoon Manfred from my understanding the maven hierarchy looks like: JASON (aka god) | v Everyone else (pull up a pew) Bedankt, Martin __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 16 Jun 2011 08:24:35 -0700 Subject: Re: PMC change explanation? From: manf...@mosabuam.com To: dev@maven.apache.org CC: bo...@apache.org I find it somewhat bewildering that there is no post of the vote or the results on the dev and users mailing lists I can see. Nor does the web site seem to be updated. http://maven.apache.org/team-list.html I would have expected more transparency from Apache. manfred Jeff, I believe this strictly falls within the purview of the Apache Board to explain. In particular Jim, Doug and Shane. Only the board has the right to reveal the business that has been transacted on private lists. Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop. On Jun 16, 2011, at 9:42 AM, Jeff Jensen wrote: Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To
RE: PMC change explanation?
granted..maybe im old fashioned but I believe the person who created the project *should* have a say operating under the assumption everything good takes time what is taking place to cause this shift? bedankt, Martin Gainty __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 16 Jun 2011 15:28:11 -0400 Subject: Re: PMC change explanation? From: bimargul...@gmail.com To: dev@maven.apache.org Martin, I don't think that your message helps anyone here. Jason's email is a very gracious acknowledgement of the governance of the Apache Software Foundation. The changes in the Maven PMC result from a complex situation, and many people are working hard behind the scenes to resolve that situation. It's not for me to elaborate here. I would join others in appealing for patience. --benson margulies On Thu, Jun 16, 2011 at 3:08 PM, Martin Gainty mgai...@hotmail.com wrote: Good Afternoon Manfred from my understanding the maven hierarchy looks like: JASON (aka god) | v Everyone else (pull up a pew) Bedankt, Martin __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 16 Jun 2011 08:24:35 -0700 Subject: Re: PMC change explanation? From: manf...@mosabuam.com To: dev@maven.apache.org CC: bo...@apache.org I find it somewhat bewildering that there is no post of the vote or the results on the dev and users mailing lists I can see. Nor does the web site seem to be updated. http://maven.apache.org/team-list.html I would have expected more transparency from Apache. manfred Jeff, I believe this strictly falls within the purview of the Apache Board to explain. In particular Jim, Doug and Shane. Only the board has the right to reveal the business that has been transacted on private lists. Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop.
Re: [VOTE] Release Maven Remote Resources Plugin version 1.2.1
+1 2011/6/14 Kristian Rosenvold kristian.rosenv...@gmail.com: Hi, We solved 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=17198 There are still 2 issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MRRESOURCES+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-010/ Staging site: (Sync pending) http://maven.apache.org/plugins/maven-remote-resources-plugin-1.2.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Verifier version 1.3
+1 2011/6/14 Kristian Rosenvold kristian.rosenv...@gmail.com: Hi, We solved/improved quite a few things. Issue tracking does not seem to be actively used for this project, svn log attached below Staging repo: https://repository.apache.org/content/repositories/maven-012/ Staging site: (Sync pending) http://maven.apache.org/shared/maven-verifier-1.3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1. Kristian == CHANGELOG == r815892 | jdcasey | 2009-09-16 19:12:28 +0200 (on., 16 sep. 2009) | 1 line removing one-off source release assemblies (and config), then upgrading parent version for all shared projects up to 12, so source-release will be automatic. r823739 | bentmann | 2009-10-10 01:20:57 +0200 (lø., 10 okt. 2009) | 1 line o Added support to launch ITs using embedded Maven 3.x r824335 | bentmann | 2009-10-12 15:47:17 +0200 (ma., 12 okt. 2009) | 1 line o Added another embedded launcher that does not load Maven from a home directory but from the class path, this allows us to run the core ITs with the Maven from our IDE workspace r912161 | bentmann | 2010-02-20 18:46:18 +0100 (lø., 20 feb. 2010) | 1 line o Simplified configuration of environment variables r920045 | bentmann | 2010-03-07 18:43:28 +0100 (sø., 07 mars 2010) | 1 line o Added setter for fork option r920448 | bentmann | 2010-03-08 19:55:39 +0100 (ma., 08 mars 2010) | 1 line o Removed validation of goal list to allow execution of default goals given in POM r931543 | bentmann | 2010-04-07 15:41:19 +0200 (on., 07 april 2010) | 1 line o Fixed argument quoting to recognize more special characters r936076 | krosenvold | 2010-04-20 23:58:36 +0200 (ti., 20 april 2010) | 1 line o Removed deadlock-prone synchronization r944714 | bentmann | 2010-05-15 22:29:45 +0200 (lø., 15 mai 2010) | 1 line o Added method to purge specific g:a:v from local repo r948765 | bentmann | 2010-05-27 12:31:10 +0200 (to., 27 mai 2010) | 1 line o Disabled EMMA runtime controller to prevent port clashes during CI r981591 | bentmann | 2010-08-02 18:44:34 +0200 (ma., 02 aug. 2010) | 1 line o Added convenience method to add CLI option r983169 | hboutemy | 2010-08-07 05:29:54 +0200 (lø., 07 aug. 2010) | 1 line updated issue management urls to point precisely to the component in MSHARED r1029201 | bentmann | 2010-10-30 23:04:17 +0200 (lø., 30 okt. 2010) | 1 line o Set user.dir when running embedded Maven r1033965 | bentmann | 2010-11-11 16:39:40 +0100 (to., 11 nov. 2010) | 1 line o Ensured parent directory of filtered file exists r1050248 | bentmann | 2010-12-17 01:15:51 +0100 (fr., 17 des. 2010) | 1 line o Added methods to further help inspection of local repo contents r1050251 | bentmann | 2010-12-17 01:19:14 +0100 (fr., 17 des. 2010) | 1 line o Made local repo layout customizable r1050255 | bentmann | 2010-12-17 01:29:11 +0100 (fr., 17 des. 2010) | 1 line o Added convenience option to remote debug mvn r1050405 | bentmann | 2010-12-17 15:44:23 +0100 (fr., 17 des. 2010) | 1 line o Allowed to query path to group-level metadata r1059093 | bentmann | 2011-01-14 19:17:21 +0100 (fr., 14 jan. 2011) | 1 line o Simplified extraction of Maven version r1064936 | bentmann | 2011-01-29 02:24:36 +0100 (lø., 29 jan. 2011) | 1 line o Inherited from latest parent
Re: [VOTE] Release Maven Surefire Plugin version 2.9
+1 2011/6/14 Kristian Rosenvold kristian.rosenv...@gmail.com: Hi, We solved 17 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=17312 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-013/ Staging site: (Sync pending) http://maven.apache.org/plugins/maven-surefire-plugin-2.9/ http://maven.apache.org/plugins/maven-failsafe-plugin-2.9/ http://maven.apache.org/plugins/maven-surefire-report-plugin-2.9/ http://maven.apache.org/surefire/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Flex 3 with Maven - Resource bundles in SWC not available in app
Bill, I'd recommend posting this question to the Flexmojos user list.
Here's a link to:
http://groups.google.com/group/flex-mojos/topics
Tim
On Mon, May 16, 2011 at 10:31 PM, sg057052 bill.burf...@sabre.com wrote:
I followed an example on a flexmojos site at
https://docs.sonatype.org/display/FLEXMOJOS/Application+Localization to
add
my Language.properties to a library project. The Language.properties file
was not in the standard location, so I added resourceBundlePath to the
SWC
maven POM:
Multi-Module SWC Localization
If you are using a multi-module maven project that uses a SWC with
localization and a SWF that uses the SWC there are a few options:
Use runtimeLocales in your SWC and add the Resource Bundle as a dependency
in your SWF for each of your supported locales: SWC POM
build
plugins
plugin
groupIdorg.sonatype.flexmojos/groupId
artifactIdflexmojos-maven-plugin/artifactId
configuration
runtimeLocaleslocaleen_US/locale/runtimeLocales
resourceBundlePath
${basedir}/src/main/flex/locales/{locale}
/resourceBundlePath
/configuration
/plugin
/plugins
/build
The project compiles fine and creates the 2 SWC files.
The Application project (SWF) does not compile because it says it cannot
find the Language resource bundle.
SWF POM
dependencies
dependency
groupIdcom.example/groupId
artifactIdexample-swc/artifactId
version${project.version}/version
typeswc/type
/dependency
dependency
groupIdcom.example/groupId
artifactIdexample-swc/artifactId
version${project.version}/version
typerb.swc/type
classifieren_US/classifier
/dependency
/dependencies
Does the Application POM also need to have a change to it to know the path
of the RB?
The Applications main MXML file has:
mx:Metadata
[ResourceBundle(Language)]
/mx:Metadata
Does this need to change at all?
Thanks to all for your help!
--
View this message in context:
http://maven.40175.n5.nabble.com/Flex-3-with-Maven-Resource-bundles-in-SWC-not-available-in-app-tp4402522p4402522.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Regarding Archetype customization
sorry, this is not an actual feature of archetype plugin Regards, Hervé Le jeudi 16 juin 2011, goutham a écrit : I have a question regarding Archetype customization. Consider i have two files FILE1.java and FILE2.java , How can i customize my archetype-metadata.xml so that , according to my choice i can select FILE1.java or FILE2.java at the time of mvn archetype:generate. Is it possible ? Can you send me related tutorial or working tutorial? Regards -Goutham -- View this message in context: http://maven.40175.n5.nabble.com/Regarding-Archetype-customization-tp44941 31p4494131.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Flex 3 with Maven - Resource bundles in SWC not available in app
Hi Tim-
interesting question!
i took hermans Original codebase
layout is created which incorporates:
sample mxml created
sample as scripts are created
mxmlc on the mxmlc to produce swf
internationalisation:
1)I assume you have xml input? append each xml input with language_country e.g.
en_US
2)you will need some way to determine the language easiest way is to is to
sniff $ENV{HTTP_ACCEPT_LANGUAGE};
3)then apply the appended xml to the AS code populating string values
even though this is a maven-plugin the architecture adheres to Adobe Flex
Framework
Feel free to ping me offline as I have that here (and dont want to introduce OT
topics to list!)
thanks,
Martin Gainty
__
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und
Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
Date: Thu, 16 Jun 2011 16:46:59 -0500
Subject: Re: Flex 3 with Maven - Resource bundles in SWC not available in app
From: tobr...@discursive.com
To: dev@maven.apache.org
Bill, I'd recommend posting this question to the Flexmojos user list.
Here's a link to:
http://groups.google.com/group/flex-mojos/topics
Tim
On Mon, May 16, 2011 at 10:31 PM, sg057052 bill.burf...@sabre.com wrote:
I followed an example on a flexmojos site at
https://docs.sonatype.org/display/FLEXMOJOS/Application+Localization to
add
my Language.properties to a library project. The Language.properties file
was not in the standard location, so I added resourceBundlePath to the
SWC
maven POM:
Multi-Module SWC Localization
If you are using a multi-module maven project that uses a SWC with
localization and a SWF that uses the SWC there are a few options:
Use runtimeLocales in your SWC and add the Resource Bundle as a dependency
in your SWF for each of your supported locales: SWC POM
build
plugins
plugin
groupIdorg.sonatype.flexmojos/groupId
artifactIdflexmojos-maven-plugin/artifactId
configuration
runtimeLocaleslocaleen_US/locale/runtimeLocales
resourceBundlePath
${basedir}/src/main/flex/locales/{locale}
/resourceBundlePath
/configuration
/plugin
/plugins
/build
The project compiles fine and creates the 2 SWC files.
The Application project (SWF) does not compile because it says it cannot
find the Language resource bundle.
SWF POM
dependencies
dependency
groupIdcom.example/groupId
artifactIdexample-swc/artifactId
version${project.version}/version
typeswc/type
/dependency
dependency
groupIdcom.example/groupId
artifactIdexample-swc/artifactId
version${project.version}/version
typerb.swc/type
classifieren_US/classifier
/dependency
/dependencies
Does the Application POM also need to have a change to it to know the path
of the RB?
The Applications main MXML file has:
mx:Metadata
[ResourceBundle(Language)]
/mx:Metadata
Does this need to change at all?
Thanks to all for your help!
--
View this message in context:
Re: PMC change explanation?
Just to make a couple of things clear, that weren't stated elsewhere in the thread: On 16/06/2011, at 11:42 PM, Jeff Jensen wrote: It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. There has been no change to who has commit privileges in Maven. Whether Benjamin (or any other committer) chooses to commit or not is his choice, for whatever reasons they might have. My guess is he's probably been busy with other things. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? There's no private plans regarding the development of Maven. Things occasionally come up, but any discussion in private that veers to development or technical details gets pushed over to this list pretty quick. A recent example was the concerns about the lack of releases on the core (in contrast to the plugins), and thinking about what it takes to get more people involved. That is hardly a new thing - it's been the case as long as I've been in the project :) If anyone is concerned about the progress any part of the project is making, then by all means step up and get involved - there's plenty to be done! Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving forward with mixins
(sorry for the delay, I've not forgotten, just been busy) On 25/05/2011, at 12:34 AM, Jesse Glick wrote: On 05/24/2011 01:30 AM, Brett Porter wrote: Some notes on how I think it should work: - templates should look like a normal POM (perhaps only differing in root element, and less strict validation requirements) [...] - any POM element is valid, other than parent,groupId,artifactId,version,templates,modules - templates need to be sourced from the repository [...] - templates should have an extension xml in the repository. [...] Maybe I am missing some unmentioned constraints, but the problem as I see it is just that the existing parent mechanism does not support multiple inheritance. The sketch above sounds like something that is similar to regular inheritance, yet syntactically different, and requiring a new packaging etc. If the POM schema for the child (~ importer) needs to be extended anyway, why not make it look and work as much as possible like the existing mechanism? While I think it should be very close in behaviour, there's a fairly significant semantic difference between the parent and the mixin. The parent offers some grouping - a canonical set of stuff several projects pick up, where a mixin is something a project pulls in to add to itself. For example, you said: You would of course have to define some logic for picking which parent (or grandparent...) wins in case of a conflict on some item. I think the most natural choice is a depth-first search up through the parent graph, in the declared order. (Note that this implies that groupId, artifactId, and version may be inherited as before, but only from the first declared parent.) This makes the first parent special, which is potentially confusing and its better to be explicit. Note: the functionality of scope=import in current versions of Maven, limited to supplying dependencyManagement, would be subsumed by a feature like this. If you really wanted to avoid any XSD change to pom.xml you could just broaden the interpretation of scope=import (so it could inherit other configuration, and perhaps could be permitted in regular dependencies outside of dependencyManagement), though the syntax would be less intuitive than parents. I think that scope is a bit confusing, and not frequently used. It's really time we stopped applying bandaids and made it possible to change the POM... FWIW, I did start to port my previous work to get that happening. The main thing I'm still working on is identifying the touchpoints so that POMs in the repository work across both Maven 2 3. If anyone wants to help with that, let me know... - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving forward with mixins
Hi Maurizio, Re-reading this, I saw before we had a lot of agreement, but re-reading I see you also had a question... On 25/05/2011, at 1:44 AM, Maurizio Pillitu wrote: However, I'm sure you're already noticing some limitations: - you can't get in before interpolation, so properties used anywhere other than plugin configuration will not be set Yes, this is probably the biggest issue ATM with this approach, but I thought there would be good opportunities to fix it. I don't know how Maven interpolation works, so I don't have an idea how to solve this; could you provide me any pointers on code so that I can have a look (and learn some more) ? There was talk about a spec for this in the past, but I can't find an up to date document. maven-core/project-builder.txt is empty. My point was that there is no hook in Maven to get in before interpolation - the extension mechanism only deals with the constructed projects. That's why I was suggesting we would need to make modifications to the model builder. The code to look at would be the maven-model-builder and some of the DefaultProjectBuilder in maven-core. HTH, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMC change explanation?
On Thursday, June 16, 2011 3:36:45 PM Martin Gainty wrote: granted..maybe im old fashioned but I believe the person who created the project *should* have a say Unless that person decided they no longer want a say. Jason resigned from the PMC back in January. He voluntarily removed himself and was not part of this board action. I should also point out his choice of words is interesting: Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop. Notice there is nothing in there expressing a commitment to the Maven project here at Apache. Maybe I'm reading too much into it, but i found that concerning. Dan operating under the assumption everything good takes time what is taking place to cause this shift? bedankt, Martin Gainty __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 16 Jun 2011 15:28:11 -0400 Subject: Re: PMC change explanation? From: bimargul...@gmail.com To: dev@maven.apache.org Martin, I don't think that your message helps anyone here. Jason's email is a very gracious acknowledgement of the governance of the Apache Software Foundation. The changes in the Maven PMC result from a complex situation, and many people are working hard behind the scenes to resolve that situation. It's not for me to elaborate here. I would join others in appealing for patience. --benson margulies On Thu, Jun 16, 2011 at 3:08 PM, Martin Gainty mgai...@hotmail.com wrote: Good Afternoon Manfred from my understanding the maven hierarchy looks like: JASON (aka god) v Everyone else (pull up a pew) Bedankt, Martin __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 16 Jun 2011 08:24:35 -0700 Subject: Re: PMC change explanation? From:
Re: [RESULT] [VOTE] Release org.apache.maven:maven-parent:20
Correction: in the 24 hours I forgot about, we got two more binding votes: Herve Boutemy and Vincent Siveton. On Wed, Jun 15, 2011 at 7:03 AM, Benson Margulies bimargul...@gmail.com wrote: You know, I tried to check it against the PMC list on the page, and I very distinctively thought that i found you and not him. On Wed, Jun 15, 2011 at 2:06 AM, Lukas Theussl ltheu...@apache.org wrote: Benson Margulies wrote: Hi, The vote has passed with the following result : +1 (binding):Stephen Connolly, Olivier Lamy, Kristian Rosenvold, Lukas Theussl, Dennis Lundberg, John Casey +1 (not binding): Benson Margulies, Mark Struberg, For the record: my vote is not binding, but Mark's is, so the total count is invariant :) -Lukas I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Release the changes plugin?
Once the vote passes on the plugin parent, I'd like to turn around and start a release on maven-changes-plugin. Please let me know if anyone (Dennis?) thinks that something else needs to happen first. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving forward with mixins
On 6/16/11 8:11 PM, Brett Porter wrote: (sorry for the delay, I've not forgotten, just been busy) On 25/05/2011, at 12:34 AM, Jesse Glick wrote: On 05/24/2011 01:30 AM, Brett Porter wrote: Some notes on how I think it should work: - templates should look like a normal POM (perhaps only differing in root element, and less strict validation requirements) [...] - any POM element is valid, other thanparent,groupId,artifactId,version,templates,modules - templates need to be sourced from the repository [...] - templates should have an extension xml in the repository. [...] Maybe I am missing some unmentioned constraints, but the problem as I see it is just that the existingparent mechanism does not support multiple inheritance. The sketch above sounds like something that is similar to regular inheritance, yet syntactically different, and requiring a new packaging etc. If the POM schema for the child (~ importer) needs to be extended anyway, why not make it look and work as much as possible like the existing mechanism? While I think it should be very close in behaviour, there's a fairly significant semantic difference between the parent and the mixin. The parent offers some grouping - a canonical set of stuff several projects pick up, where a mixin is something a project pulls in to add to itself. For example, you said: You would of course have to define some logic for picking which parent (or grandparent...) wins in case of a conflict on some item. I think the most natural choice is a depth-first search up through the parent graph, in the declared order. (Note that this implies that groupId, artifactId, and version may be inherited as before, but only from the first declared parent.) This makes the first parent special, which is potentially confusing and its better to be explicit. Note: the functionality of scope=import in current versions of Maven, limited to supplyingdependencyManagement, would be subsumed by a feature like this. If you really wanted to avoid any XSD change to pom.xml you could just broaden the interpretation of scope=import (so it could inherit other configuration, and perhaps could be permitted in regulardependencies outside ofdependencyManagement), though the syntax would be less intuitive thanparents. I think that scope is a bit confusing, and not frequently used. It's really time we stopped applying bandaids and made it possible to change the POM... While I agree that we should be engaging in design a little more and avoiding bandaid fixes for things, I will say that the import scope brings a lot of potential for standardizing dependency versions - both privately within a large collection of projects, and publicly for users of those projects. It's not the most elegant solution, though... FWIW, I did start to port my previous work to get that happening. The main thing I'm still working on is identifying the touchpoints so that POMs in the repository work across both Maven 2 3. If anyone wants to help with that, let me know... - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design Best Practices
Issue Subscription
Filter: Design Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to jsp tags or jsf composites
http://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-4713
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
http://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for properties and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Help in customizing maven-archetype
when i run mvn archetype:generate it asks for parameters like groupId , artifactId , package and version. Now i want to ask for an extra parameter like module-author but i want to ask in this manner Do you want to enter module-author? ( Y / N) (on entering Y , i should ask for the parameter) Y module-author: nameoftheauthor (on entering N , i should terminate the asking process and the rest of the project build should be completed) N . . Project Build Success Full -- Is this possible with ArchetypeCreationQueryer ? .. i guess i got an example source file here http://svn.apache.org/repos/asf/maven/archetype/tags/maven-archetype-2.0/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/ui/DefaultArchetypeCreationQueryer.java DefaultArchetypeCreationQueryer but i dont know how to implement it in my project and run it and see how it works? Any help will be thank full -- View this message in context: http://maven.40175.n5.nabble.com/Help-in-customizing-maven-archetype-tp4497629p4497629.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
