adding video capture to the continuum site
Hi, I'd like to add some wink captures to the site (as adding a project for newbies etc...) As this files can be huge, I don't really want to add this in sources trunk (It can be long to checkout the sources) But in order to publish them, they must be in a site module. That's why I'd like to remove the site module from this current path and move it to https://svn.apache.org/repos/asf/maven/continuum/. svn mv https://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-site/ https://svn.apache.org/repos/asf/maven/continuum . The parent pom of this module will be last org.apache.maven:maven-parent pom. An other question is what I have to add in svn : wnk and swf files or only swf ? Let me know if there is any objections concerning this, -- Olivier
Re: adding video capture to the continuum site
Yes displaying the page containing this swf could be long. But in the link to these pages we can indicate this. For not storing this files in svn but in an other place, it looks possible to deploy it manually to people.apache.org /www/maven.apache.org/continuum. But I'm not sure it's a good solution to have an automatic process to deploying site with mvn and an other manual to deploy this files. -- Olivier 2007/9/19, Rahul Thakur [EMAIL PROTECTED]: How will this affect users on dial-up/slow connections browsing those pages on the continuum site? Is it possible to have these swf (or wnk) resources live outside SVN and be included from an external URL? Rahul - Original Message - From: olivier lamy [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Wednesday, September 19, 2007 6:42 PM Subject: adding video capture to the continuum site Hi, I'd like to add some wink captures to the site (as adding a project for newbies etc...) As this files can be huge, I don't really want to add this in sources trunk (It can be long to checkout the sources) But in order to publish them, they must be in a site module. That's why I'd like to remove the site module from this current path and move it to https://svn.apache.org/repos/asf/maven/continuum/. svn mv https://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-site/ https://svn.apache.org/repos/asf/maven/continuum . The parent pom of this module will be last org.apache.maven:maven-parent pom. An other question is what I have to add in svn : wnk and swf files or only swf ? Let me know if there is any objections concerning this, -- Olivier -- Olivier
Re: adding video capture to the continuum site
On 9/18/07, olivier lamy [EMAIL PROTECTED] wrote: I'd like to add some wink captures to the site (as adding a project for newbies etc...) Great idea. :) As this files can be huge, I don't really want to add this in sources trunk (It can be long to checkout the sources) But in order to publish them, they must be in a site module. Not necessarily... they can be hosted anywhere that can handle the bandwidth, and linked to. Is YouTube an appropriate option? (Or can you convert to a format that can be hosted there or somewhere similar?) That's why I'd like to remove the site module from this current path and move it to https://svn.apache.org/repos/asf/maven/continuum/. svn mv https://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-site/ https://svn.apache.org/repos/asf/maven/continuum . I'm not in favor of moving the site somewhere it doesn't get checked out with the project. But I also don't think the ASF Subversion repo is the right place for documentation video files. (It would be different if they were *part* of the product itself.) Are any other projects offering video examples? How do they handle it? -- Wendy
[vote] Release Continuum 1.1-beta-3
Hi, Continuum 1.1-beta-3 is ready for release The highlights are - lot of bug fixes - LDAP support for authentication (thanks jesse) - performance improvement - committer mail notification The Release Notes is available there: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13661 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-3/continuum-plexus-runtime-1.1-beta-3-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-webapp/1.1-beta-3/continuum-webapp-1.1-beta-3.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/data-management-cli/1.1-beta-3/data-management-cli-1.1-beta-3-app.jar Everyone is encouraged to vote and give their feedback. [ ] +1 Release it! [ ] 0 [ ] -1 Don't release it, because... The vote will be open for 72 hours. So, cast your votes now ;-) Here's my +1 Thanks, Emmanuel
Re: [vote] Release Continuum 1.1-beta-3
+1 -- Olivier 2007/9/19, Emmanuel Venisse [EMAIL PROTECTED]: Hi, Continuum 1.1-beta-3 is ready for release The highlights are - lot of bug fixes - LDAP support for authentication (thanks jesse) - performance improvement - committer mail notification The Release Notes is available there: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13661 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-3/continuum-plexus-runtime-1.1-beta-3-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-webapp/1.1-beta-3/continuum-webapp-1.1-beta-3.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/data-management-cli/1.1-beta-3/data-management-cli-1.1-beta-3-app.jar Everyone is encouraged to vote and give their feedback. [ ] +1 Release it! [ ] 0 [ ] -1 Don't release it, because... The vote will be open for 72 hours. So, cast your votes now ;-) Here's my +1 Thanks, Emmanuel
Re: [vote] Release Continuum 1.1-beta-3
+1 Emmanuel Venisse To [EMAIL PROTECTED] continuum-dev@maven.apache.org .net continuum-dev@maven.apache.org cc 19/09/2007 02:55 Subject PM[vote] Release Continuum 1.1-beta-3 Please respond to [EMAIL PROTECTED] en.apache.org Hi, Continuum 1.1-beta-3 is ready for release The highlights are - lot of bug fixes - LDAP support for authentication (thanks jesse) - performance improvement - committer mail notification The Release Notes is available there: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13661 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-3/continuum-plexus-runtime-1.1-beta-3-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-webapp/1.1-beta-3/continuum-webapp-1.1-beta-3.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/data-management-cli/1.1-beta-3/data-management-cli-1.1-beta-3-app.jar Everyone is encouraged to vote and give their feedback. [ ] +1 Release it! [ ] 0 [ ] -1 Don't release it, because... The vote will be open for 72 hours. So, cast your votes now ;-) Here's my +1 Thanks, Emmanuel
Re: [vote] Release Continuum 1.1-beta-3
Emmanuel Venisse wrote: Hi, Continuum 1.1-beta-3 is ready for release The highlights are - lot of bug fixes - LDAP support for authentication (thanks jesse) - performance improvement - committer mail notification The Release Notes is available there: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13661 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-3/continuum-plexus-runtime-1.1-beta-3-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-webapp/1.1-beta-3/continuum-webapp-1.1-beta-3.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/data-management-cli/1.1-beta-3/data-management-cli-1.1-beta-3-app.jar Everyone is encouraged to vote and give their feedback. [ ] +1 Release it! [ ] 0 [ ] -1 Don't release it, because... The vote will be open for 72 hours. So, cast your votes now ;-) Here's my +1 Thanks, Emmanuel This issues is preventing me from being able to check out projects from Subversion: http://jira.codehaus.org/browse/SCM-320 -- View this message in context: http://www.nabble.com/-vote--Release-Continuum-1.1-beta-3-tf4482966.html#a12785521 Sent from the Continuum - Dev mailing list archive at Nabble.com.
Re: dependency:analyze changes
On 18/09/2007, Paul Gier [EMAIL PROTECTED] wrote: I think that's what I meant ;) Anyway, the surefire report plugin uses report and report-only to do something similar, so that seems consistent with Brian's suggestion of using analyze and analyze-only. Great, I think we're all in agreement now :) I've renamed analyze-attached to analyze-only, so the final state of affairs is: dependency:analyze - executes test-compile phase - for use standalone dependency:analyze-only - executes in phase verify - for use in the build lifecycle Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven Artifact in 2.0.x
On 18/09/2007, Jason van Zyl [EMAIL PROTECTED] wrote: I think it makes sense to release 2.0.8 as is. When Herve comes back he can roll in his encoding changes. That will fix the biggies for 2.0.8, there's a couple things I will fix, anything else anyone wants to tackle and then we can release it. I think waiting for the encoding fixes is important. Aside from that I think we can push out most other things and release. Then attempt the maven-artifact integration. Sounds great, let's do it. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release maven-changes-plugin 2.0-beta-3
On 17/09/2007, Dennis Lundberg [EMAIL PROTECTED] wrote: I guess that the presence of [WARNING] plexus:plexus-container-default:jar:1.0-alpha-6:compile is a bad sign? Is the right way to fix this, to excluding this from whichever dependency is pulling it in? I'll try to run 'mvn package -X' and see is I can find where it's coming from, or is there an easier/better way? You'll need the latest unreleased version of dependency:tree: 1) Ensure you're running Maven 2.0.8-SNAPSHOT 2) Install maven-dependency-tree 1.1-SNAPSHOT: http://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/ 3) Install maven-dependency-tree-MDEP-100 branch: http://svn.apache.org/repos/asf/maven/plugins/branches/maven-dependency-plugin-MDEP-100/ Then, for your example, run: mvn dependency:tree -Dincludes=plexus:plexus-container-default -Dverbose [INFO] [dependency:tree] [INFO] org.apache.maven.plugins:maven-changes-plugin:maven-plugin:2.0-beta-3-SNAPSHOT [INFO] +- plexus:plexus-mail-sender-simple:jar:1.0-alpha-2:compile [INFO] | +- plexus:plexus-container-default:jar:1.0-alpha-6:compile [INFO] | \- plexus:plexus-mail-sender-api:jar:1.0-alpha-2:compile [INFO] | \- (plexus:plexus-container-default:jar:1.0-alpha-6:compile - omitted for duplicate) [INFO] \- plexus:plexus-mail-sender-javamail:jar:1.0-alpha-2:compile [INFO]\- (plexus:plexus-container-default:jar:1.0-alpha-6:compile - omitted for duplicate) Very handy for tracking down rogue dependencies. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding video capture to the continuum site
How will this affect users on dial-up/slow connections browsing those pages on the continuum site? Is it possible to have these swf (or wnk) resources live outside SVN and be included from an external URL? Rahul - Original Message - From: olivier lamy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 6:42 PM Subject: adding video capture to the continuum site Hi, I'd like to add some wink captures to the site (as adding a project for newbies etc...) As this files can be huge, I don't really want to add this in sources trunk (It can be long to checkout the sources) But in order to publish them, they must be in a site module. That's why I'd like to remove the site module from this current path and move it to https://svn.apache.org/repos/asf/maven/continuum/. svn mv https://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-site/ https://svn.apache.org/repos/asf/maven/continuum . The parent pom of this module will be last org.apache.maven:maven-parent pom. An other question is what I have to add in svn : wnk and swf files or only swf ? Let me know if there is any objections concerning this, -- Olivier
Doubt on dowload sources and javadoc
Hello, Im using maven-eclipse-plugin in a project. The problem is when I make mvn eclipse:eclipse it tries to download the artefacts sources. Even if I add DdownloadSources=false or delete de mvn-eclipse-cache.properties file it continues trying to download them, sources and javadoc. How can I solve the problem? Thanks for the help, José Pacheco.
Javadoc plugin and default Plexus Commandline
Hi guys, I've just updated some projects that now use Maven 2.0.7 along with the Javadoc plugin 2.3, and now my build fails because the UNIX platform where the integrations happen doesn't have bash. The reason is the following: the Javadoc plugin creates a default Commandline object to run the javadoc process, but with the last versions of Plexus Utils, the default constructor sets /bin/bash as the default shell. For what I've found in the code of both the Javadoc plugin and Plexus Utils, it seems to me that there is no way to specify another shell for UNIX systems. Do you have any idea of how I could handle that? The problem is that I don't have root privileges on the UNIX server... :-( Thanks in advance for any anwser! Cheers, Fabrice.
Maven deployment
Hi all Can anybody explain me the steps to deploy ejb using maven with Websphere 6?Has anybody tried using Maven and RAD combination? Can maven follow the directory structure of RAD? Thanks and regards Hemant Ved
Re: Maven deployment
Hi, use the maven-eclipse-plugin for RAD-6 support. I do not know the status of the RAD-7 support. http://maven.apache.org/plugins/maven-eclipse-plugin/ tip 1: Stay with the maven project layout as far as possible! tip 2: extract java code from any war into a separate jar-module (this will reduce a lot of rad problems) regards, Richard van Nieuwenhoven Hemant Ved wrote: Hi all Can anybody explain me the steps to deploy ejb using maven with Websphere 6?Has anybody tried using Maven and RAD combination? Can maven follow the directory structure of RAD? Thanks and regards Hemant Ved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
pre-configuring self written plugins
hi there! is there any way to pre-configure my own maven plugin so that i am able to create and modify a standard config without re-compiling? i don't want the users to be forced to configure some parameters by themselves. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc plugin and default Plexus Commandline
Hi Fabrice, PLXUTILS-34 is included in p-u:1.4.6, so try to add it as dependency in the javadoc-plugin. Cheers, Vincent 2007/9/19, Fabrice Bellingard [EMAIL PROTECTED]: Hi guys, I've just updated some projects that now use Maven 2.0.7 along with the Javadoc plugin 2.3, and now my build fails because the UNIX platform where the integrations happen doesn't have bash. The reason is the following: the Javadoc plugin creates a default Commandline object to run the javadoc process, but with the last versions of Plexus Utils, the default constructor sets /bin/bash as the default shell. For what I've found in the code of both the Javadoc plugin and Plexus Utils, it seems to me that there is no way to specify another shell for UNIX systems. Do you have any idea of how I could handle that? The problem is that I don't have root privileges on the UNIX server... :-( Thanks in advance for any anwser! Cheers, Fabrice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Doubt on dowload sources and javadoc
This is a bug in the latest version. -Original Message- From: José Pacheco [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 5:52 AM To: dev@maven.apache.org Subject: Doubt on dowload sources and javadoc Hello, I'm using maven-eclipse-plugin in a project. The problem is when I make mvn eclipse:eclipse it tries to download the artefacts sources. Even if I add -DdownloadSources=false or delete de mvn-eclipse-cache.properties file it continues trying to download them, sources and javadoc. How can I solve the problem? Thanks for the help, José Pacheco. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: pre-configuring self written plugins
Parameters in your plugins can have defaults. Take a look at any of the maven plugins for examples. -Original Message- From: Jens Rapp [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 8:29 AM To: dev@maven.apache.org Subject: pre-configuring self written plugins hi there! is there any way to pre-configure my own maven plugin so that i am able to create and modify a standard config without re-compiling? i don't want the users to be forced to configure some parameters by themselves. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modify the Super Pom from Plugin
On 18 Sep 07, at 12:11 PM 18 Sep 07, Arnaud HERITIER wrote: Hi guys, Is it possible within a plugin to modify the default settings of the Super Pom (default directories, ..) ? Any idea ? No, and why would you want to do that? The Super POM is immutable for all intents and purposes. You should just override at the organizational level or in a project POM if you want to do something different. Thx .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc plugin and default Plexus Commandline
Hi Vincent, in Maven 2.0.x, it is not possible to add a dependency to a plugin in the reporting section. And if you put it in the pluginManagement section, this doesn't work either. (see bug MNG-1931) So that's why I don't see a solution to that... :-( Cheers, Fabrice. On 9/19/07, Vincent Siveton [EMAIL PROTECTED] wrote: Hi Fabrice, PLXUTILS-34 is included in p-u:1.4.6, so try to add it as dependency in the javadoc-plugin. Cheers, Vincent 2007/9/19, Fabrice Bellingard [EMAIL PROTECTED]: Hi guys, I've just updated some projects that now use Maven 2.0.7 along with the Javadoc plugin 2.3, and now my build fails because the UNIX platform where the integrations happen doesn't have bash. The reason is the following: the Javadoc plugin creates a default Commandline object to run the javadoc process, but with the last versions of Plexus Utils, the default constructor sets /bin/bash as the default shell. For what I've found in the code of both the Javadoc plugin and Plexus Utils, it seems to me that there is no way to specify another shell for UNIX systems. Do you have any idea of how I could handle that? The problem is that I don't have root privileges on the UNIX server... :-( Thanks in advance for any anwser! Cheers, Fabrice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modify the Super Pom from Plugin
Hi Jason, I was quite sure to have this reply and this is normal. I explain my problem. A Grails project has actually its own directories layout that isn't at all compatible with maven standards (and it sucks a little bit). It's something like that : %PROJECT_HOME% + grails-app + conf --- location of configuration artifacts like data sources + hibernate --- optional hibernate config + spring --- optional spring config + controllers --- location of controller artifacts + domain --- location of domain classes + i18n --- location of message bundles for i18n + services --- location of services + taglib --- location of tag libraries + util --- location of special utility classes (e.g., codecs, etc.) + views--- location of views + layouts --- location of layouts + lib + scripts --- scripts + src + groovy --- optional; location for Groovy source files (of types other than those in grails-app/*) + java --- optional; location for Java source files + test --- generated test classes + web-app + WEB-INF As you can see java classes are in src/java, but there's also a lot og groovy files in grails-app/controller, grails-app/..., src/groovy Actually the build mechanism in grails isn't enough opened to be able to configure it with a maven layout and grails users get used to have this layout, that's why I try temporarly to adapt maven to grails standards (waiting to be able to adapt grails to maven ones). My integration with maven is actually very thin. I'm using grails scripts from maven, but I would like if possible in a near future to be able to use reports and others maven features (release management, ...). All those plugins are looking in the pom to find where are sources, tests , But I would like to avoid to define all those custom settings in each project's pom. It could be better to have the plugin to do it for the project. Temporarly I think I'll try to add sources / tests directories like it is done in the build-helper plugin. I don't see another idea. If you have one . ;-) Thx. Arnaud On 19/09/2007, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Sep 07, at 12:11 PM 18 Sep 07, Arnaud HERITIER wrote: Hi guys, Is it possible within a plugin to modify the default settings of the Super Pom (default directories, ..) ? Any idea ? No, and why would you want to do that? The Super POM is immutable for all intents and purposes. You should just override at the organizational level or in a project POM if you want to do something different. Thx .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
RE: Modify the Super Pom from Plugin
What happens if you modified the super pom and included it an extension? Which would take precedence? -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 12:09 PM To: Maven Developers List Subject: Re: Modify the Super Pom from Plugin Hi Jason, I was quite sure to have this reply and this is normal. I explain my problem. A Grails project has actually its own directories layout that isn't at all compatible with maven standards (and it sucks a little bit). It's something like that : %PROJECT_HOME% + grails-app + conf --- location of configuration artifacts like data sources + hibernate --- optional hibernate config + spring --- optional spring config + controllers --- location of controller artifacts + domain --- location of domain classes + i18n --- location of message bundles for i18n + services --- location of services + taglib --- location of tag libraries + util --- location of special utility classes (e.g., codecs, etc.) + views--- location of views + layouts --- location of layouts + lib + scripts --- scripts + src + groovy --- optional; location for Groovy source files (of types other than those in grails-app/*) + java --- optional; location for Java source files + test --- generated test classes + web-app + WEB-INF As you can see java classes are in src/java, but there's also a lot og groovy files in grails-app/controller, grails-app/..., src/groovy Actually the build mechanism in grails isn't enough opened to be able to configure it with a maven layout and grails users get used to have this layout, that's why I try temporarly to adapt maven to grails standards (waiting to be able to adapt grails to maven ones). My integration with maven is actually very thin. I'm using grails scripts from maven, but I would like if possible in a near future to be able to use reports and others maven features (release management, ...). All those plugins are looking in the pom to find where are sources, tests , But I would like to avoid to define all those custom settings in each project's pom. It could be better to have the plugin to do it for the project. Temporarly I think I'll try to add sources / tests directories like it is done in the build-helper plugin. I don't see another idea. If you have one . ;-) Thx. Arnaud On 19/09/2007, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Sep 07, at 12:11 PM 18 Sep 07, Arnaud HERITIER wrote: Hi guys, Is it possible within a plugin to modify the default settings of the Super Pom (default directories, ..) ? Any idea ? No, and why would you want to do that? The Super POM is immutable for all intents and purposes. You should just override at the organizational level or in a project POM if you want to do something different. Thx .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: pre-configuring self written plugins
well, i did this but i couldn't find where to set them- besides the declaration in the plugin's source code but i would have to recompile the plugin if those parameters are changed.. can you tell me where to find these defaults? Original-Nachricht Datum: Wed, 19 Sep 2007 09:33:01 -0400 Von: Brian E. Fox [EMAIL PROTECTED] An: Maven Developers List dev@maven.apache.org Betreff: RE: pre-configuring self written plugins Parameters in your plugins can have defaults. Take a look at any of the maven plugins for examples. -Original Message- From: Jens Rapp [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 8:29 AM To: dev@maven.apache.org Subject: pre-configuring self written plugins hi there! is there any way to pre-configure my own maven plugin so that i am able to create and modify a standard config without re-compiling? i don't want the users to be forced to configure some parameters by themselves. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modify the Super Pom from Plugin
On 19 Sep 07, at 9:09 AM 19 Sep 07, Arnaud HERITIER wrote: Hi Jason, Just make your archetypes redefine those directories. Or deploy a parent for all your maven-based grails projects that inherit from a POM with all the overrides. Changing the super POM is a bad, bad, bad, bad idea. I was quite sure to have this reply and this is normal. I explain my problem. A Grails project has actually its own directories layout that isn't at all compatible with maven standards (and it sucks a little bit). It's something like that : %PROJECT_HOME% + grails-app + conf --- location of configuration artifacts like data sources + hibernate --- optional hibernate config + spring --- optional spring config + controllers --- location of controller artifacts + domain --- location of domain classes + i18n --- location of message bundles for i18n + services --- location of services + taglib --- location of tag libraries + util --- location of special utility classes (e.g., codecs, etc.) + views--- location of views + layouts --- location of layouts + lib + scripts --- scripts + src + groovy --- optional; location for Groovy source files (of types other than those in grails-app/*) + java --- optional; location for Java source files + test --- generated test classes + web-app + WEB-INF As you can see java classes are in src/java, but there's also a lot og groovy files in grails-app/controller, grails-app/..., src/groovy Actually the build mechanism in grails isn't enough opened to be able to configure it with a maven layout and grails users get used to have this layout, that's why I try temporarly to adapt maven to grails standards (waiting to be able to adapt grails to maven ones). My integration with maven is actually very thin. I'm using grails scripts from maven, but I would like if possible in a near future to be able to use reports and others maven features (release management, ...). All those plugins are looking in the pom to find where are sources, tests , But I would like to avoid to define all those custom settings in each project's pom. It could be better to have the plugin to do it for the project. Temporarly I think I'll try to add sources / tests directories like it is done in the build-helper plugin. I don't see another idea. If you have one . ;-) Thx. Arnaud On 19/09/2007, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Sep 07, at 12:11 PM 18 Sep 07, Arnaud HERITIER wrote: Hi guys, Is it possible within a plugin to modify the default settings of the Super Pom (default directories, ..) ? Any idea ? No, and why would you want to do that? The Super POM is immutable for all intents and purposes. You should just override at the organizational level or in a project POM if you want to do something different. Thx .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modify the Super Pom from Plugin
On 19/09/2007, Jason van Zyl [EMAIL PROTECTED] wrote: On 19 Sep 07, at 9:09 AM 19 Sep 07, Arnaud HERITIER wrote: Hi Jason, Just make your archetypes redefine those directories. Or deploy a parent for all your maven-based grails projects that inherit from a POM with all the overrides. Changing the super POM is a bad, bad, bad, bad idea. I understand and I'm not in favor to show how to hack maven standards because it can open a very dangerous door. But on the other side I would like to be able to show the power of maven. I though to propose a parent pom but I abandoned it because it can be unusable if you have another inheritance (in a corp env for example). Others solutions I see actually are : - to generate those settings when I create the pom. It's not a real archetype because grails already offers this sort of services. The dark side of this, is that users will have a pom a little bit big at the beginning. But I'll be able to explain that this one will be reduced when grails will use maven's standards. - to add a mojo, that I bind in a phase called at the beginning of the lifecycle to add sources directories. Arnaud I was quite sure to have this reply and this is normal. I explain my problem. A Grails project has actually its own directories layout that isn't at all compatible with maven standards (and it sucks a little bit). It's something like that : %PROJECT_HOME% + grails-app + conf --- location of configuration artifacts like data sources + hibernate --- optional hibernate config + spring --- optional spring config + controllers --- location of controller artifacts + domain --- location of domain classes + i18n --- location of message bundles for i18n + services --- location of services + taglib --- location of tag libraries + util --- location of special utility classes (e.g., codecs, etc.) + views--- location of views + layouts --- location of layouts + lib + scripts --- scripts + src + groovy --- optional; location for Groovy source files (of types other than those in grails-app/*) + java --- optional; location for Java source files + test --- generated test classes + web-app + WEB-INF As you can see java classes are in src/java, but there's also a lot og groovy files in grails-app/controller, grails-app/..., src/groovy Actually the build mechanism in grails isn't enough opened to be able to configure it with a maven layout and grails users get used to have this layout, that's why I try temporarly to adapt maven to grails standards (waiting to be able to adapt grails to maven ones). My integration with maven is actually very thin. I'm using grails scripts from maven, but I would like if possible in a near future to be able to use reports and others maven features (release management, ...). All those plugins are looking in the pom to find where are sources, tests , But I would like to avoid to define all those custom settings in each project's pom. It could be better to have the plugin to do it for the project. Temporarly I think I'll try to add sources / tests directories like it is done in the build-helper plugin. I don't see another idea. If you have one . ;-) Thx. Arnaud On 19/09/2007, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Sep 07, at 12:11 PM 18 Sep 07, Arnaud HERITIER wrote: Hi guys, Is it possible within a plugin to modify the default settings of the Super Pom (default directories, ..) ? Any idea ? No, and why would you want to do that? The Super POM is immutable for all intents and purposes. You should just override at the organizational level or in a project POM if you want to do something different. Thx .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
Re: RE: pre-configuring self written plugins
The defaults are in the source code, as you mentioned. Which will require compilation to change. So it sounds like your requirements cannot be met currently. Why don't you explain what exactly you're trying to achieve, and perhaps someone will have an alternate suggestion? Wayne On 9/19/07, Jens Rapp [EMAIL PROTECTED] wrote: well, i did this but i couldn't find where to set them- besides the declaration in the plugin's source code but i would have to recompile the plugin if those parameters are changed.. can you tell me where to find these defaults? Original-Nachricht Datum: Wed, 19 Sep 2007 09:33:01 -0400 Von: Brian E. Fox [EMAIL PROTECTED] An: Maven Developers List dev@maven.apache.org Betreff: RE: pre-configuring self written plugins Parameters in your plugins can have defaults. Take a look at any of the maven plugins for examples. -Original Message- From: Jens Rapp [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 8:29 AM To: dev@maven.apache.org Subject: pre-configuring self written plugins hi there! is there any way to pre-configure my own maven plugin so that i am able to create and modify a standard config without re-compiling? i don't want the users to be forced to configure some parameters by themselves. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Local Repository Separation
On 18/09/2007, at 10:22 PM, Kenney Westerhof wrote: Hi, 2. Workspaces should be something you have to set consciously, not automatically created. This allows an integration-testing run (for example) to run in isolation by using a different workspace id, and clean up after itself when finished. Agreed. I think they should always be created, and after the entire build finished, merged to the main tree. Look at it as build transactions. I had listed this as a separate feature that could be built on top of this, under Rolling back a reactor build - I don't think it impacts the base implementation, though. In your other mail you indicated likewise that it might need more thought (as it could be avoided altogether by making the install plugin an aggregator). WDYT? Do I need to make some additional changes to the proposal? Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
summary regarding plugin pack proposal
Hi, This is the best summary I can get from the discussion earlier this month about this proposal: - in terms of having some way to simplify specifying a group of plugins: 4 in favour, 3 against, 1 on the fence and 2 that wanted a compromise (a plugin to automate snippet injection) - in terms of *requiring* versions to be locked down: the poll was split 50/50. Some said they would only vote for this if there was some way of doing the above easily. So it's pretty much split. It's worth nothing there is general appeal for mixins in a more well-defined form, and that could be applied to the first. I'm not pursuing the original proposal at this stage - however I will revise in the future. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
[proposal] bring plugin tools together in SCM
I'd like to do what we did for surefire and bring all the following into one tree, called /plugin-tools/trunk, versioned consistently as 2.4 and using MPLUGIN as the JIRA project: * plugins/maven-plugin-plugin * shared/maven-plugin-* * shared/maven-script Thoughts? Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: summary regarding plugin pack proposal
Let it be implemented as tooling which doesn't affect the core and people will decide what they like to use. The enforcer plugin addition goes a long way. A simple tool for creating a block with the latest releases I am making now for a client. People can compose these tools as they wish to provide they stability they desire. On 19 Sep 07, at 6:17 PM 19 Sep 07, Brett Porter wrote: Hi, This is the best summary I can get from the discussion earlier this month about this proposal: - in terms of having some way to simplify specifying a group of plugins: 4 in favour, 3 against, 1 on the fence and 2 that wanted a compromise (a plugin to automate snippet injection) - in terms of *requiring* versions to be locked down: the poll was split 50/50. Some said they would only vote for this if there was some way of doing the above easily. So it's pretty much split. It's worth nothing there is general appeal for mixins in a more well-defined form, and that could be applied to the first. I'm not pursuing the original proposal at this stage - however I will revise in the future. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: pre-configuring self written plugins
i'm juggling with some svn repositories and pathes inside and outside them so i have several similar classes inside my mojo. because there are at least two small groups of people in my company which are using other repositories than the others, I need to configure them. But currently I don't know the svn server names. Original-Nachricht Datum: Wed, 19 Sep 2007 16:41:08 -0500 Von: Wayne Fay [EMAIL PROTECTED] An: Maven Developers List dev@maven.apache.org Betreff: Re: RE: pre-configuring self written plugins The defaults are in the source code, as you mentioned. Which will require compilation to change. So it sounds like your requirements cannot be met currently. Why don't you explain what exactly you're trying to achieve, and perhaps someone will have an alternate suggestion? Wayne On 9/19/07, Jens Rapp [EMAIL PROTECTED] wrote: well, i did this but i couldn't find where to set them- besides the declaration in the plugin's source code but i would have to recompile the plugin if those parameters are changed.. can you tell me where to find these defaults? Original-Nachricht Datum: Wed, 19 Sep 2007 09:33:01 -0400 Von: Brian E. Fox [EMAIL PROTECTED] An: Maven Developers List dev@maven.apache.org Betreff: RE: pre-configuring self written plugins Parameters in your plugins can have defaults. Take a look at any of the maven plugins for examples. -Original Message- From: Jens Rapp [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 8:29 AM To: dev@maven.apache.org Subject: pre-configuring self written plugins hi there! is there any way to pre-configure my own maven plugin so that i am able to create and modify a standard config without re-compiling? i don't want the users to be forced to configure some parameters by themselves. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
