RE: [2.0.10 RC] Please test
Yes, that's helpful. We'll have to dig in some more. -Original Message- From: Henrique Prange [mailto:[EMAIL PROTECTED] Sent: Saturday, November 08, 2008 3:12 PM To: Maven Users List Subject: Re: [2.0.10 RC] Please test Hi Brian, I'm using wagon-ssh (for scp:// url). I've probably used the latest version, since it was not specified in my pom.xml. I did two tests with the same project: 1) Specified the wagon-ssh version as 1.0-beta-4 (I suppose it is the latest): I had the same problem. 2) Specified the wagon-ssh version as 1.0-beta-2: Maven did what it was supposed to do without asking me to type any password. Hope this helps. Cheers, Henrique P.S.: I have the following message printed on console for both versions of the wagon plug-in (beta-2 or beta-4). WAGON_VERSION: 1.0-beta-2 Brian E. Fox wrote: > What wagon/url is being used? > > -Original Message- > From: Henrique Prange [mailto:[EMAIL PROTECTED] > Sent: Friday, November 07, 2008 8:55 AM > To: Maven Users List > Subject: Re: [2.0.10 RC] Please test > > Hi Brian, > > I've tried to deploy a project with 2.0.10-RC2 and I receive a message > asking me to type the password a lot of times. > > [INFO] Retrieving previous build number from myhost.com/dist/snapshots > Keyboard interactive required, supplied password is ignored > Password:: > > I've rechecked and the password is correctly configured in my > settings.xml. I've tried with 2.1.0-M1 and it worked fine. > > Cheers, > > Henrique > > Brian Fox wrote: >> Hello, >> We're moving forward with the 2.0.10 RC process. We have have not >> turned up any new issues within the Dev team, so as usual we're >> widening our net. >> >> Here's the list of issues fixed in 2.0.10: >> >> > http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112&styleName >> =Html&projectId=10500&Create=Create >> >> And I've staged RC-2 here: >> >> > http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa >> che-maven/2.0.10-RC2/ >> >> >> >> Please try it out and see if we have any remaining regressions over > 2.0.9. >> Thanks, >> >> Brian >> >> -- >> >> Brian Fox >> >> Apache Maven PMC >> >> http://blogs.sonatype.com/brian/ >> >> - >> 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] > > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ${localRepository} property not recognized in Maven2
Yes I am sure, ${settings.localRepository} does'nt print the local repo
location, I am running Maven 2.0.9 latest download.
-Praveen
--
View this message in context:
http://www.nabble.com/%24%7BlocalRepository%7D-property-not-recognized-in-Maven2-tp20389692p20402755.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ${localRepository} property not recognized in Maven2
Are you sure?
Its works for me. A configuration example :
maven-antrun-plugin
settings.localRepository=${settings.localRepository}
pkbhavani wrote:
>
>
> settings.localRepository=${settings.localRepository}
>
>
>
> I have maven-antrun-plugin task that needs location of the local
> Repository, but ${settings.localRepository} is not recognizing, I have
> defined in the conf/settings.xml file in maven
> installation.
>
> -praveen
>
--
View this message in context:
http://www.nabble.com/%24%7BlocalRepository%7D-property-not-recognized-in-Maven2-tp20389692p20401273.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management Questions
On Sat, Nov 8, 2008 at 1:01 PM, Rusty Wright <[EMAIL PROTECTED]> wrote: > But I do have multiple environments. > > How do you manage the different configuration files for the different > environments? > > Do they have different names and the application figures out which > environment it's on and then uses the appropriately named configuration > file? I tried that; it's too fragile. > > Or do the configuration files have the same name on all environments and > you have to ensure that the right ones are installed? That's what I'm using > now with symbolic links. For example, db.properties is what the app uses > but it's a symbolic link to db-dev.properties. I mostly to the latter -- i've experimented with some kind of centralized configuration with discovery, but haven't ended up with something i'm happy with, so I mostly just load configuration from the classpath with a predefined name, and use the container to add the appropriate directory into the classpath in each environment. -- Geoffrey Wiseman
Re: [2.0.10 RC] Please test
Hi Brian, I'm using wagon-ssh (for scp:// url). I've probably used the latest version, since it was not specified in my pom.xml. I did two tests with the same project: 1) Specified the wagon-ssh version as 1.0-beta-4 (I suppose it is the latest): I had the same problem. 2) Specified the wagon-ssh version as 1.0-beta-2: Maven did what it was supposed to do without asking me to type any password. Hope this helps. Cheers, Henrique P.S.: I have the following message printed on console for both versions of the wagon plug-in (beta-2 or beta-4). WAGON_VERSION: 1.0-beta-2 Brian E. Fox wrote: What wagon/url is being used? -Original Message- From: Henrique Prange [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 8:55 AM To: Maven Users List Subject: Re: [2.0.10 RC] Please test Hi Brian, I've tried to deploy a project with 2.0.10-RC2 and I receive a message asking me to type the password a lot of times. [INFO] Retrieving previous build number from myhost.com/dist/snapshots Keyboard interactive required, supplied password is ignored Password:: I've rechecked and the password is correctly configured in my settings.xml. I've tried with 2.1.0-M1 and it worked fine. Cheers, Henrique Brian Fox wrote: Hello, We're moving forward with the 2.0.10 RC process. We have have not turned up any new issues within the Dev team, so as usual we're widening our net. Here's the list of issues fixed in 2.0.10: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112&styleName =Html&projectId=10500&Create=Create And I've staged RC-2 here: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.10-RC2/ Please try it out and see if we have any remaining regressions over 2.0.9. Thanks, Brian -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - 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] - 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: Ant-based Mojos using Ant 1.6.5
> unless you have a body of ant script that's already been debugged That's basically the situation. From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Fri 11/7/2008 10:31 PM To: Maven Users List Subject: Re: Ant-based Mojos using Ant 1.6.5 I have the code here, I took it out of plexus with the intent of just sticking it in Maven as no one outside a B&R environment would care about writing a plexus component with ant script. In my experience it's still just faster to write the plugin in Java then try to debug ant script, unless you have a body of ant script that's already been debugged. Or write the script first stand-alone then wrap it. On 7-Nov-08, at 12:23 PM, Edelson, Justin wrote: > Currently, it seems that the support in Maven for writing plugins in > Ant > uses Ant 1.6.5. Is there a plan to upgrade this to 1.7.1? > > I traced the depencency back to plexus-ant-factory, but it looks like > this component was deleted from Subversion about a month ago > (http://fisheye.codehaus.org/changelog/plexus/plexus-component-factories > /trunk/plexus-ant-factory?cs=7731). > > Thanks, > > Justin Edelson > VP, Platform Engineering > MTV Networks Digital Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant-based Mojos using Ant 1.6.5
I have the code here, I took it out of plexus with the intent of just sticking it in Maven as no one outside a B&R environment would care about writing a plexus component with ant script. In my experience it's still just faster to write the plugin in Java then try to debug ant script, unless you have a body of ant script that's already been debugged. Or write the script first stand-alone then wrap it. On 7-Nov-08, at 12:23 PM, Edelson, Justin wrote: Currently, it seems that the support in Maven for writing plugins in Ant uses Ant 1.6.5. Is there a plan to upgrade this to 1.7.1? I traced the depencency back to plexus-ant-factory, but it looks like this component was deleted from Subversion about a month ago (http://fisheye.codehaus.org/changelog/plexus/plexus-component-factories /trunk/plexus-ant-factory?cs=7731). Thanks, Justin Edelson VP, Platform Engineering MTV Networks Digital Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven compilation error
Hi, See the maven-compiler-plugin: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#encodingadd the encoding tag inside the configuration one. Cheers. 2008/11/8 <[EMAIL PROTECTED]> > Hi, > > When i am compiling the classes using > > mvn com[ile,I am gettin the followiug exceptions... > > INFO] Compilation failure > > > error: IO exception sun.io.MalformedInputException > error: IO exception sun.io.MalformedInputException > error: IO exception sun.io.MalformedInputException > error: IO exception sun.io.MalformedInputException > > > Earlier when we had used ant scripts,this was resolved with > > > > How to specify the same in maven?? > > THanks > > Regards > > > -- > Hyundai to launch the i20 in India. Catch the exclusive preview on > ZigWheels.com > > http://www.zigwheels.com/b2cam/newsDetails.action?name=Emb11_20080731&path=/INDT/News/Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Release Management Questions
But I do have multiple environments. How do you manage the different configuration files for the different environments? Do they have different names and the application figures out which environment it's on and then uses the appropriately named configuration file? I tried that; it's too fragile. Or do the configuration files have the same name on all environments and you have to ensure that the right ones are installed? That's what I'm using now with symbolic links. For example, db.properties is what the app uses but it's a symbolic link to db-dev.properties. Geoffrey Wiseman wrote: On Fri, Nov 7, 2008 at 3:45 PM, Rusty Wright <[EMAIL PROTECTED]> wrote: What are the pros and cons for this? I feel more comfortable having everything in the war file, because then if I change one of the properties files all I have to do is rebuild, check the war file in to subversion, then our release management people check it out on the appropriate layer. If the properties file was external then that's another file for them to have to deal with. It seems less error prone when the war file is completely self contained. If you've only got one environment or the configuration isn't environmental, I'd agree; if you're likely to have more than one environment and environmental configuration, then I'd argue for configuration to be externalized, so that one WAR can live in testing, staging and production (or whatever your needs are for multiple environments -- such as multiple clients) without needing to be changed and rebuilt. - Geoffrey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven unit tests run twice
When I run "mvn install site", the unit tests run twice. I've tried all different combinations of the things talked about here: http://jira.codehaus.org/browse/SUREFIRE-257 But no matter what I do, they run twice - halp?!
Re: Activate a profile when project.version is not SNAPSHOT
http://jira.codehaus.org/browse/MNG-3826 On Fri, Nov 7, 2008 at 1:26 AM, Mark Hobson <[EMAIL PROTECTED]> wrote: > I've been wanting this for a while but figured it'd be solved by > custom profile activators, currently sitting in trunk: > > http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators > > Perhaps a new snapshot profile activator would be best for the > short-term. Have you raised an issue I could watch? > > Cheers, > > Mark > > 2008/11/6 Dan Tran <[EMAIL PROTECTED]>: >> sounds like a new feature to request for maven-profile component >> >> On Thu, Nov 6, 2008 at 1:35 PM, Stephen Connolly >> <[EMAIL PROTECTED]> wrote: >>> AFAIK, No... the core does not support it and plugins cannot activate >>> profiles as the active profiles have been decided before the validate phase >>> >>> 2008/11/6 Dan Tran <[EMAIL PROTECTED]> >>> is it possible? -D - 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] >> >> > > - > 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: Non lifecycle tasks in Maven
am an ant user who is trying to get up to speed with Maven because I started working on a project that uses it. In ant this would be simple, but I was told not to create any build.xml files. There are a lot of tasks in a project that you will want to capture the processing logic for and only run once in a blue moon. Things like run this GUI or generate some test data for debugging or generate stubs. What I would like to be able to do is something like; mvn genStubs and have the result be a jar file with the compiled stub classes in it. Ken David Ojeda-2 wrote: > > You are right Nick, I think this is a problem with this solution since I > dont > think it is possible to re-evaluate the profile once a phase has finished > or > started. > > Let me know if you come up with another solution. > > On Thursday 06 November 2008 05:29:38 Nick Stolwijk wrote: >> Does this also work when you execute "mvn clean install" on a project >> which has the generated sources? I think the profile activation will >> only be looked at at the beginning of the build. After that, the clean >> task removes the generated sources and your install phase would fail. >> >> With regards, >> >> Nick Stolwijk >> ~Java Developer~ >> >> Iprofs BV. >> Claus Sluterweg 125 >> 2012 WS Haarlem >> www.iprofs.nl >> >> On Thu, Nov 6, 2008 at 1:19 AM, David Ojeda <[EMAIL PROTECTED]> wrote: >> > What a coincidence, I just stumbled with this problem. >> > I solved it by using a profile that activates when the generated >> classes >> > directory is missing. The profile defines the task for class >> generation. >> > Here is a snip, I will post it completely in a different post, for >> future >> > axis2/maven users... >> > >> > I use xmlbeans so I could not use the maven axis plugins nor the maven >> > xmlbeans plugin. But you'll get the idea >> > >> > >> > >> >sourcegen >> > >> >false >> > >> >target/generated-sources >> > >> > >> > >> > >> > >> >org.apache.maven.plugins >> >maven-antrun-plugin >> >1.3 >> > >> > >> >xmlbeans-source-code-generation >> > >> >generate-sources >> > >> >run >> > >> > >> > >> >> > classname="org.apache.xmlbeans.impl.tool.SchemaCompiler" >> >fork="true"> >> >> >line=" >> >-javasource 1.5 >> >-srconly >> >-src target/generated- >> > sources/xmlbeans >> >-d target/generated- >> > sources/xmlbeans >> >src/main/wsdl >> >src/main/xsd" /> >> >> > refid="maven.dependency.classpath" /> >> >> > refid="maven.compile.classpath" /> >> >> > refid="maven.runtime.classpath" /> >> > >> > >> > >> > >> > >> >axis2-source-code-generation >> >generate-sources >> > >> >run >> > >> > >> > >> >> > classname="org.apache.axis2.wsdl.WSDL2Java" fork="true"> >> >> >line=" >> >-o >> target/generated-sources/axis2/ >> >-t >> >-ss >> >-sd >> >-d xmlbeans >> >-Ewdc >> >--noBuildXML >> >-uri >> > src/main/wsdl/WSIterautoID.wsdl" /> >> >> > refid="maven.dependency.classpath" /> >> >> > refid="maven.compile.cl
Re: Getting artifacts snapshot versions in a MOJO
Le Friday 07 November 2008 15:44:01 Stephen Connolly, vous avez écrit : > When you build foo-1.0.3-SNAPSHOT, > the build treats that version as is until you reach the deploy stage. > > At deploy, the deploy plugin gives it the timestamp... so the timestamp is > only available when you get to the deploy phase (i.e. after deploy you'd be > able to get foo-1.0.3-20081104.143523-57) > > Unfortunately for you, you are looking for the value before it exists... Understood, thanks Stephen. > now if this is for a separate module, then you might stand a chance To be more precise, when I'm building foo-1.0.3-SNAPSHOT, depending on bar-1.2.2-SNAPSHOT our MOJO tries to download bar-1.2.2-SNAPSHOT-aclassifier. Given that at time 1, bar snapshot version was deployed _with_ an attached artifact with "aclassifier" and that at time 2 another bar snapshot version was deployed _without_ and attached artifact with "aclassifier", maven download the last snapshot version of bar-1.2.2-SNAPSHOT but our MOJO download the previous deployed snapshot version when trying to resolve bar-1.2.2-SNAPSHOT-aclassifier. Any idea ? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Experimental Grails archetype
Hi, I have been working on the Maven integration for Grails, basically incorporating the Maven Grails Plugin and taking advantage of some changes in Grails itself. There is now an archetype available that you can use to create Grails projects without having to install Grails manually. The command line is: mvn archetype:generate -DarchetypeGroupId=org.grails \ -DarchetypeArtifactId=grails-maven-archetype \ -DarchetypeVersion=1.0-SNAPSHOT \ -DarchetypeRepository=http://snapshots.repository.codehaus.org \ -DgroupId=example -DartifactId=my-app \ Once you have a project, you can execute the standard phases: "clean", "compile", "test", and "package". It's a bit rough around the edges to say the least, so there might be a few problems. I'm interested in what people think and whether it plays ok with other plugins (I suspect mostly not). Issues should be raised as sub-tasks of: http://jira.codehaus.org/browse/GRAILS-3547 Regards, Peter -- View this message in context: http://www.nabble.com/Experimental-Grails-archetype-tp20395006p20395006.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven release:prepare - creates file with svn inconsistent line ending style for CDATA sections
Has anyone else had problems with svn inconsistent line ending style and mvn release:prepare? This would should up only on windows as the block in question only has LF not CR LF. I suspect because it uses \n instead of System.getProperty( line.separator ); I haven't spent any time investigating it. Besides google and checking JIRA. The problem occurs in the CDATA section of the maven-eclipse-plugin - when setting the contents of the .checkstyle file. org.apache.maven.plugins maven-eclipse-plugin true com.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder com.atlassw.tools.eclipse.checkstyle.CheckstyleNature .checkstyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
