Re: Don't want to repeat plugin version for both build and reporting
I’ve always used properties, but would it work to use buildDependencies? -K On Oct 2, 2014, at 7:02 PM, Paul Benedict pbened...@apache.org wrote: I use the maven-javadoc-plugin in both build and reporting. I don't want to fall back to properties to share the plugin version. Is there a better way than using properties? Cheers, Paul - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to tell Maven to generate code when XSL has changed?
I'm not the requestor, but it seems like time stamp would be reasonable. But you also have a forceCreate config (or something like that, it's been a few weeks since I last typed it.) They could just use that and always generate the file. -K On Apr 25, 2013, at 5:20 AM, Baptiste MATHUS wrote: How would you like it to detect that file was changed? If you can come up with a sensible way of doing that, please just file a JIRA and we could look into it. Even better, if you can provide a good patch I can take apply it. Cheers 2013/4/25 Markus Karg k...@quipsy.de I am using xml-maven-plugin to generate Java code from XML: groupIdorg.codehaus.mojo/groupId artifactIdxml-maven-plugin/artifactId version1.0/version executions execution phasegenerate-sources/phase goals goaltransform/goal /goals /execution /executions This works well, but now I want that it automatically executes as soon as the used transformation XSLT file was modified. So how can I tell maven that it shall do generate-sources as soon as a particular file was touched? Thanks! -Markus -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: git scm and site:deploy
Should I be pulling that and deploying? -K On Aug 22, 2012, at 7:12 AM, Stephen Connolly wrote: Here is my fork https://github.com/stephenc/wagon-gitsite which has support for deploying multi-module projects (which is what I needed) On 22 August 2012 13:09, Stephen Connolly stephen.alan.conno...@gmail.comwrote: On 22 August 2012 13:03, Thomas Scheffler thomas.scheff...@uni-jena.dewrote: Am 22.08.2012 12:48, schrieb Olivier Lamy: Not very well supported currently natively by our own Apache maven stuff. But have a look here http://khuxtable.github.com/wagon-gitsite/usage.html Thank you for giving me the link. Sadly currently I found no version of this plugin in any repository. So it seems a bit ugly to download the It's in central. http://search.maven.org/#search%7Cga%7C1%7Cwagon-gitsite Here is an example (though using my forked version - which has some patches that I needed and ms huxtable has yet to publish a release with the patches applied - likely because her use cases do not overlap the issues I had) https://github.com/jszip/jszip-parent/blob/master/pom.xml#L144 source and install the artifact locally. As this affect a documented feature that is missing (see: http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html) should I open a bug then or am I missing some config options? regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Can I do scm checkout from inside a plugin?
I know the release plugin can do it, but the source is fairly complex. Is there an easy way? My goal is to check out an earlier version of the artifact, copy its resources (so I'll also be running the copy-resources plugin), which produces some data as side effects, and then compare that data to the current data. I'm trying to make an incremental updater. Obviously I can keep the earlier version around, but it would be nice not to have to depend on that. Any advice would be appreciated. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can I do scm checkout from inside a plugin?
Thanks! I'm also checking out the mojo-executor plugin. It looks kind of squirrelly, but it may do what I want. I'm going to need to run a plugin on the checked out code, so I guess I can't avoid either embedding Maven or forking it. (I think I'll fork.) Part of me wonders if sticking to shell scripting for this might be easier. -K On Jun 26, 2012, at 8:29 AM, Olivier Lamy wrote: Hi, Maybe will be more easy to have a look at the CheckoutMojo ? http://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/CheckoutMojo.java 2012/6/26 Kathryn Huxtable kath...@kathrynhuxtable.org: I know the release plugin can do it, but the source is fairly complex. Is there an easy way? My goal is to check out an earlier version of the artifact, copy its resources (so I'll also be running the copy-resources plugin), which produces some data as side effects, and then compare that data to the current data. I'm trying to make an incremental updater. Obviously I can keep the earlier version around, but it would be nice not to have to depend on that. Any advice would be appreciated. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can I do scm checkout from inside a plugin?
Thanks. I am using maven3, but I think the invoker looks simpler. If we were using Jenkins already I might think differently… -K On Jun 26, 2012, at 11:27 AM, Olivier Lamy wrote: 2012/6/26 Kathryn Huxtable kath...@kathrynhuxtable.org: Thanks! I'm also checking out the mojo-executor plugin. It looks kind of squirrelly, but it may do what I want. I'm going to need to run a plugin on the checked out code, so I guess I can't avoid either embedding Maven or forking it. (I think I'll fork.) Probably maven-invoker (http://maven.apache.org/shared/maven-invoker/) library can help you. If you use maven3 maybe you can have a look at https://github.com/jenkinsci/lib-jenkins-maven-embedder which is not prefect :-) embedder. Part of me wonders if sticking to shell scripting for this might be easier. -K On Jun 26, 2012, at 8:29 AM, Olivier Lamy wrote: Hi, Maybe will be more easy to have a look at the CheckoutMojo ? http://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/CheckoutMojo.java 2012/6/26 Kathryn Huxtable kath...@kathrynhuxtable.org: I know the release plugin can do it, but the source is fairly complex. Is there an easy way? My goal is to check out an earlier version of the artifact, copy its resources (so I'll also be running the copy-resources plugin), which produces some data as side effects, and then compare that data to the current data. I'm trying to make an incremental updater. Obviously I can keep the earlier version around, but it would be nice not to have to depend on that. Any advice would be appreciated. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can I do scm checkout from inside a plugin?
Okay, I have what I need. Thanks to everyone. The most useful advice (for me) was Olivier's pointer at the invoker plugin. I had never needed it and didn't really know about it. Knowing about it, I was able to find its uses in the release plugin, so I can make my use of it more robust. -K On Jun 26, 2012, at 1:56 PM, Kathryn Huxtable wrote: Thanks. I am using maven3, but I think the invoker looks simpler. If we were using Jenkins already I might think differently… -K On Jun 26, 2012, at 11:27 AM, Olivier Lamy wrote: 2012/6/26 Kathryn Huxtable kath...@kathrynhuxtable.org: Thanks! I'm also checking out the mojo-executor plugin. It looks kind of squirrelly, but it may do what I want. I'm going to need to run a plugin on the checked out code, so I guess I can't avoid either embedding Maven or forking it. (I think I'll fork.) Probably maven-invoker (http://maven.apache.org/shared/maven-invoker/) library can help you. If you use maven3 maybe you can have a look at https://github.com/jenkinsci/lib-jenkins-maven-embedder which is not prefect :-) embedder. Part of me wonders if sticking to shell scripting for this might be easier. -K On Jun 26, 2012, at 8:29 AM, Olivier Lamy wrote: Hi, Maybe will be more easy to have a look at the CheckoutMojo ? http://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/CheckoutMojo.java 2012/6/26 Kathryn Huxtable kath...@kathrynhuxtable.org: I know the release plugin can do it, but the source is fairly complex. Is there an easy way? My goal is to check out an earlier version of the artifact, copy its resources (so I'll also be running the copy-resources plugin), which produces some data as side effects, and then compare that data to the current data. I'm trying to make an incremental updater. Obviously I can keep the earlier version around, but it would be nice not to have to depend on that. Any advice would be appreciated. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] JAXB-2 Maven Plugin 1.4 Released
In general, how does this compare to the jvnet jaxb plugin? Why would I use one
over the other?
I do a certain amount of JAXB, and I'm curious.
-K
On Jun 26, 2012, at 3:20 PM, Anders Hammar wrote:
Hi,
The Mojo team is pleased to announce the release of the JAXB-2 Maven
Plugin version 1.4.
http://mojo.codehaus.org/jaxb2-maven-plugin/
To get this update, simply specify the version in your project's
plugin configuration:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjaxb2-maven-plugin/artifactId
version1.4/version
/plugin
Release Notes
** Bug
* [MJAXB-49] - Change the name of the plugin
** Improvement
* [MJAXB-30] - Patch to add support for Ant-style wildcards to schemaFiles
* [MJAXB-37] - Getters not being generated for Boolean fields
* [MJAXB-39] - Document use of schemagen target
* [MJAXB-48] - Make it possible to enable verbose from command line
* [MJAXB-53] - add an encoding parameter and use
${project.build.sourceEncoding} as default value
* [MJAXB-59] - SchemaGen should skip non-existent source directories
* [MJAXB-60] - Improve m-compiler-p version lock-down in usage pages
** New Feature
* [MJAXB-55] - Provide means to set the file name of generated XML schema
** Task
* [MJAXB-50] - Document an example about having two (or more)
bindings with different config
Enjoy,
The Mojo team.
/Anders
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven site documentation problem
Let's hear it for version control. Also undelete. -K On Dec 7, 2011, at 9:58 AM, Jim McCaskey wrote: Hello all, As a sort of public service announcement I would like to point out a problem with the docs here: http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Old_configuration_Maven_2__3 It has this little snippet at the top: reporting excludeDefaultstrue/excludeDefaults outputDirectory/outputDirectory plugins Notice that empty outputDirectory? Well Maven 2.2.1 appears to ignore it. Maven 3.0.3 however, deletes the entire tree. The entire tree, including your pom.xml and your /src directory. Use with extreme caution. I opened this issue to track the documentation issue: http://jira.codehaus.org/browse/MSITE-621 I'm not sure if the maven-clean-plugin should prevent this sort of thing or not (probably not). But the docs should be updated for the next unaware traveler. :) -Jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using Maven with custom libraries which are not in repository.
And a single Nexus instance can have multiple repositories. You can manually install your custom libraries in a repository in Nexus that is only used by this one project. -K On Sep 29, 2011, at 6:56 AM, Schrecker, Wolfgang wrote: You can put your libs into Nexus without 'mavenizing' them. Lot less to do ... Wolfgang -Ursprüngliche Nachricht- Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Gesendet: Donnerstag, 29. September 2011 11:09 An: Maven Users List Betreff: Re: Using Maven with custom libraries which are not in repository. Rule of thumb: If you feel like you are fighting Maven then either: 1. You are doing it wrong, do it the Maven way and you won't be fighting; or 2. You maybe should be using a different build tool that does not have its own way. -Stephen On 29 September 2011 09:59, Wayne Fay wayne...@gmail.com wrote: No, that does NOT work. Put them in Nexus as you've been told. Wayne On Thursday, September 29, 2011, Prashant Neginahal prashu.n...@gmail.com wrote: Is that the only option? Those jars are required only for web project. Other application java projects DO NOT require those jars. I was thinking to put them in web lib folder and maven can include them in classpath. Some thing like this works? Thanks, Prashant On Thu, Sep 29, 2011 at 1:07 PM, Guillaume Polet guillaume.po...@gmail.comwrote: I am looking at fix to use that framework in maven way. Then, your only option is to install all those jars in your Nexus repository. Guillaume Le 29/09/2011 09:31, Prashant Neginahal a écrit : Thanks for reply,Yuvaraj. I understand the maven repository and we will be having nexus repository. But, we are asked to use that proprietary web framework which comes with its own jars. I dont think we have possibility to mavenize all those jars and put them into repository. I just want to keep it the way it is and use for build. However, our application development projects will be maven projects and will put them into maven repository. Thanks, Prashant On Thu, Sep 29, 2011 at 12:17 PM, Yuvaraj Vanarase yuvaraj.vanar...@synechron.com** wrote: Prashant, If those libraries are standard and well known then should be available at some maven repository. You can try http://mvnrepository.com to find it out. Generally, you should setup your own repository may be using artifactory and put all dependencies there. Requirement is maven should able to access those jars while build, once artifact is ready it will contain required jars, thus complete deployable. Hope this helps! Regards, Yuvaraj Yuvaraj Vanarase, Lead Technology - Software Phone: +91.20.40262000 Ext 2305|Mobile: +91.9850818870 | http://www.synechron.com SYNECHRON - - Top 10 Best IT Employers for 4 consecutive years (link). - Celebrating 10 Years! -Original Message- From: Prashant Neginahal [mailto:prashu.n...@gmail.com] Sent: Thursday, September 29, 2011 12:14 PM To: Maven Users List Subject: Using Maven with custom libraries which are not in repository. Hi All, We are starting new web project. But, it has to be built on some proprietary web framework which is NOT mavenised and comes with its own bunch of libraries. I am thinking of using maven for this application development. But, just wondering how to ensure maven uses this proprietary framework and its libraries which are not there in repository. Can we just dump framework libraries in WEB_INF/lib folder and maven includes the same in its CLASSPATH. Thanks, Prashant --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Geschäftsführer: Wolf Kunisch Aufsichtsratsvorsitzender: Didier Dhennin Sitz der Gesellschaft: Frankfurt/Main Handelsregister: Frankfurt/Main HRB 40 417 * * * * * * * * L E G A LD I S C L A I M E R * * * * * * * * This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail by error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and shall not be liable for any damages resulting from any virus transmitted. * * * * * * * * L E G A LD I S C L A I M E R * * * * * * * * - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: tool (mojo) lifecycle
I assume you mean artifact instead of repository? -K On Sep 4, 2011, at 12:05 AM, Wayne Fay wrote: I feel like it may be better to stick it out in a separate repository so that the lifecycle of the tool and project are decoupled. I agree. This is nearly always the right approach. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Getting strange error in compilation
Anyone else seen this? [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project seaglasslookandfeel: Compilation failure [ERROR] Failure executing javac, but could not parse the error: [ERROR] Fatal Error: Unable to find package java.lang in classpath or bootclasspath This is code that used to work. I'm running JDK 1.6.0_26 on Mac OS X 10.6.8 (Snow Leopard). This is Maven 3.0.3. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting strange error in compilation
Okay, I see. Apple changed the location of classes.jar, which is what they call rt.jar in a recent release of Java, possibly update 26. -K On Jul 31, 2011, at 5:39 PM, Kathryn Huxtable wrote: Anyone else seen this? [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project seaglasslookandfeel: Compilation failure [ERROR] Failure executing javac, but could not parse the error: [ERROR] Fatal Error: Unable to find package java.lang in classpath or bootclasspath This is code that used to work. I'm running JDK 1.6.0_26 on Mac OS X 10.6.8 (Snow Leopard). This is Maven 3.0.3. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting strange error in compilation
I've been working on a Swing pluggable look feel, and was needing to include
rt.jar. I have a separate profile for the Mac. The relevant sections of my pom
look like:
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
source1.6/source
target1.6/target
compilerArguments
bootclasspath${java.home}/lib/rt.jar/bootclasspath
/compilerArguments
/configuration
/plugin
/plugins
...
profiles
profile
idmac/id
activation
os
familymac/family
/os
/activation
build
plugins
!-- Configure the compiler plugin to use JDK
1.6. --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
source1.6/source
target1.6/target
compilerArguments
bootclasspath${java.home}/bundle/Classes/classes.jar/bootclasspath
/compilerArguments
/configuration
/plugin
/plugins
/build
/profile
...
I think most artifacts don't need to include rt.jar, so I don't know what you'd
do. I suppose we can add the JDK version to the activation profile...
I don't think you folks need to do anything, but I was bewildered, and Google
wasn't much help, though I did eventually find a solution through a Google
search, just not the first several I tried.
-K
On Jul 31, 2011, at 6:27 PM, Barrie Treloar wrote:
On Mon, Aug 1, 2011 at 8:23 AM, Kathryn Huxtable
kath...@kathrynhuxtable.org wrote:
Okay, I see. Apple changed the location of classes.jar, which is what they
call rt.jar in a recent release of Java, possibly update 26.
How did you fix this then?
Do we need to configure maven to understand this natively?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting strange error in compilation
Actually, can I require that a profile be activated when both a jdk version
*and* an os family are selected, or is it always an or comparison? -K
On Jul 31, 2011, at 6:41 PM, Kathryn Huxtable wrote:
I've been working on a Swing pluggable look feel, and was needing to
include rt.jar. I have a separate profile for the Mac. The relevant sections
of my pom look like:
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
source1.6/source
target1.6/target
compilerArguments
bootclasspath${java.home}/lib/rt.jar/bootclasspath
/compilerArguments
/configuration
/plugin
/plugins
...
profiles
profile
idmac/id
activation
os
familymac/family
/os
/activation
build
plugins
!-- Configure the compiler plugin to use JDK
1.6. --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
source1.6/source
target1.6/target
compilerArguments
bootclasspath${java.home}/bundle/Classes/classes.jar/bootclasspath
/compilerArguments
/configuration
/plugin
/plugins
/build
/profile
...
I think most artifacts don't need to include rt.jar, so I don't know what
you'd do. I suppose we can add the JDK version to the activation profile...
I don't think you folks need to do anything, but I was bewildered, and Google
wasn't much help, though I did eventually find a solution through a Google
search, just not the first several I tried.
-K
On Jul 31, 2011, at 6:27 PM, Barrie Treloar wrote:
On Mon, Aug 1, 2011 at 8:23 AM, Kathryn Huxtable
kath...@kathrynhuxtable.org wrote:
Okay, I see. Apple changed the location of classes.jar, which is what they
call rt.jar in a recent release of Java, possibly update 26.
How did you fix this then?
Do we need to configure maven to understand this natively?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting strange error in compilation
I think the way for me to solve this is to use
fileexistsblah/exists/file in two different profiles checking for the
two different locations of classes.jar. If neither exists, we'll use the
default profile, which points to the Windows/Linux location.
I assume that when Oracle actually releases a Mac Java, they will use the
standard locations for these things rather than Apple's non-standard locations,
but it's just an assumption. I'm not counting on anything, including that
Oracle will even release a Mac Java. ;-)
-K
On Jul 31, 2011, at 6:44 PM, Kathryn Huxtable wrote:
Actually, can I require that a profile be activated when both a jdk version
*and* an os family are selected, or is it always an or comparison? -K
On Jul 31, 2011, at 6:41 PM, Kathryn Huxtable wrote:
I've been working on a Swing pluggable look feel, and was needing to
include rt.jar. I have a separate profile for the Mac. The relevant sections
of my pom look like:
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
source1.6/source
target1.6/target
compilerArguments
bootclasspath${java.home}/lib/rt.jar/bootclasspath
/compilerArguments
/configuration
/plugin
/plugins
...
profiles
profile
idmac/id
activation
os
familymac/family
/os
/activation
build
plugins
!-- Configure the compiler plugin to use JDK
1.6. --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
source1.6/source
target1.6/target
compilerArguments
bootclasspath${java.home}/bundle/Classes/classes.jar/bootclasspath
/compilerArguments
/configuration
/plugin
/plugins
/build
/profile
...
I think most artifacts don't need to include rt.jar, so I don't know what
you'd do. I suppose we can add the JDK version to the activation profile...
I don't think you folks need to do anything, but I was bewildered, and
Google wasn't much help, though I did eventually find a solution through a
Google search, just not the first several I tried.
-K
On Jul 31, 2011, at 6:27 PM, Barrie Treloar wrote:
On Mon, Aug 1, 2011 at 8:23 AM, Kathryn Huxtable
kath...@kathrynhuxtable.org wrote:
Okay, I see. Apple changed the location of classes.jar, which is what they
call rt.jar in a recent release of Java, possibly update 26.
How did you fix this then?
Do we need to configure maven to understand this natively?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting strange error in compilation
My test indicated that it's an and/or. -K On Jul 31, 2011, at 6:55 PM, Barrie Treloar wrote: On Mon, Aug 1, 2011 at 9:14 AM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: Actually, can I require that a profile be activated when both a jdk version *and* an os family are selected, or is it always an or comparison? -K You know, I dont know. You might be better starting a separate thread to ask that question. My googling gets me contradictory answers. http://www.google.com/search?q=maven+profile+activation The POM reference docs (http://maven.apache.org/pom.html#Activation) * Activation occurs when one or more of the specified criteria have been met. When the first positive result is encountered, processing stops and the profile is marked as active. Introduction to Build Profiles (http://maven.apache.org/guides/introduction/introduction-to-profiles.html) * Doesn't have any examples that use multiple values within activation Maven: The Complete Reference Section 5.3. Profile Activation (http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html) * Activations can contain one of more selectors including JDK versions, Operating System parameters, files, and properties. A profile is activated when all activation criteria has been satisfied. So I suggest you try multiple and find out what happens. Then we need to create a JIRA to fix the documentation... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting strange error in compilation
I get: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/../Classes/classes.jar -K On Jul 31, 2011, at 7:22 PM, Benson Margulies wrote: What do you get from: find `/usr/libexec/java_home`/.. -name classes.jar -print ? I get: /Library/Java/JavaVirtualMachines/1.6.0_26-b03-384.jdk/Contents/Home/../Classes/classes.jar On Sun, Jul 31, 2011 at 7:55 PM, Barrie Treloar baerr...@gmail.com wrote: On Mon, Aug 1, 2011 at 9:14 AM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: Actually, can I require that a profile be activated when both a jdk version *and* an os family are selected, or is it always an or comparison? -K You know, I dont know. You might be better starting a separate thread to ask that question. My googling gets me contradictory answers. http://www.google.com/search?q=maven+profile+activation The POM reference docs (http://maven.apache.org/pom.html#Activation) * Activation occurs when one or more of the specified criteria have been met. When the first positive result is encountered, processing stops and the profile is marked as active. Introduction to Build Profiles (http://maven.apache.org/guides/introduction/introduction-to-profiles.html) * Doesn't have any examples that use multiple values within activation Maven: The Complete Reference Section 5.3. Profile Activation (http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html) * Activations can contain one of more selectors including JDK versions, Operating System parameters, files, and properties. A profile is activated when all activation criteria has been satisfied. So I suggest you try multiple and find out what happens. Then we need to create a JIRA to fix the documentation... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Pretty-printing/compressing HTML in post-site phase
On Jun 1, 2011, at 9:54 AM, Andreas Sewe wrote: Kathryn Huxtable wrote: My purpose in writing htmlfilter-site-maven-plugin was to better incorporate docbkx-tools output into Doxia-generated output. Yes, that seems to be the rationale for the maven-tidy-plugin http://docbook-utils.sourceforge.net/maven-tidy-plugin_1.0/ as well, although this plugin seems to allow one to configure JTidy. Unfortunately, it is not available in central. :-( Mine is available on my github site (http://github.com/khuxtable/htmlfilter-site-maven-plugin) and you could clone it and modify it. It uses JTidy, so you could strip out the stuff you didn't want and change the JTidy configs. It's Apache licensed, so no worries. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Pretty-printing/compressing HTML in post-site phase
My purpose in writing htmlfilter-site-maven-plugin was to better incorporate docbkx-tools output into Doxia-generated output. Not sure what might help. -K On May 31, 2011, at 8:06 AM, Andreas Sewe wrote: Hi all, are there any plugins that can be used to prettify or compress the output of Doxia/the maven-site-plugin in the post-site phase? I found Kathryn Huxtable's htmlfilter-site-maven-plugin, but that only seems to be able fix (tidy) malformed HTML. I remember reading somewhere that Doxia itself deliberatly ignores the issue of pretty-printing; instead, it defers this to other plugins. Alas, I wasn't able to find such a plugin. Any pointers? Best wishes, Andreas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Keeping the executable bit on shell scripts when testing
That's a reasonable workaround. I think it's a reasonable thing to expect permissions on files to be preserved. Consider this a +1 for a feature enhancement. -K On Jan 26, 2011, at 11:04 AM, Stephen Connolly wrote: launch them with sh as the prefix on the cli, eg sh foo.sh and not foo.sh - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 26 Jan 2011 15:36, Oliver Schrenk oliver.schr...@gmail.com wrote: Hi, I have several shell scripts in src/test/resources that I try to call from within a JUnit test. The class under test is a wrapper arround plexus.utils.cli. When mvn copies the files to target/test-classes the executable bits are lost and the test fails due missing authorization. Any way to keep them? Or any other ideas? Best regards Oliver Schrenk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Fwd: Maven job in woodlawn maryland
I'm posting this for Rick, who isn't on the list. Just FYI. -K Begin forwarded message: From: Rick Waters rwat...@apexgov.com Date: December 27, 2010 1:37:35 PM CST To: kath...@kathrynhuxtable.org Subject: Maven job in woodlawn maryland Required Qualifications for Apache Maven and Nexus development tools: Start: 1/15/2011 Duration: 1 year Local: must be local resource · Apache Maven SME whose primary work focus is in the implementation of Maven with the Eclipse or RAD development environment, · Technical experience with the installing and customizing Apache Maven, · Technical development or scripting experience integrating with FUSE on Solaris, · Technical experience with Eclipse, RAD, and implementing Maven Plug-ins or customizations in those environments, · Has ability to build Java applications using Maven and can demonstrate key technical concepts using RAD or Eclipse development tools. · Excellent written and verbal communications skills; ability to support software engineering life-cycle (requirements analysis, design alternatives; detail program specifications etc.) Document development may be required · Sonatype Nexus SME whose primary work focus repository development and management to support the implementation of FUSE. · Technical experience with the installing and customizing Sonatype Nexus on Solaris. · Technical development or scripting experience integrating with FUSE on Solaris. · Technical experience with Eclipse, RAD, and implementing Maven Plug-ins or customizations in those environments. · Has ability to build Java applications using RAD or Eclipse and can demonstrate key technical concepts for Nexus repository using the prescribed development development tools. · Excellent written and verbal communications skills; ability to support software engineering life-cycle (requirements analysis, design alternatives; detail program specifications etc.) Document development may be required. Thank You, Rick Waters Director of Resource Management Apex Government Solutions 816-547-1630 rwat...@apexgov.com
Re: Maven job in woodlawn maryland
I would worry a bit about posting a job for Maven people, but the Boxee thing is quite funny and seems like a more questionable use of the list. ;-) -K On Dec 27, 2010, at 1:44 PM, Kathryn Huxtable wrote: I'm posting this for Rick, who isn't on the list. Just FYI. -K Begin forwarded message: From: Rick Waters rwat...@apexgov.com Date: December 27, 2010 1:37:35 PM CST To: kath...@kathrynhuxtable.org Subject: Maven job in woodlawn maryland Required Qualifications for Apache Maven and Nexus development tools: Start: 1/15/2011 Duration: 1 year Local: must be local resource · Apache Maven SME whose primary work focus is in the implementation of Maven with the Eclipse or RAD development environment, · Technical experience with the installing and customizing Apache Maven, · Technical development or scripting experience integrating with FUSE on Solaris, · Technical experience with Eclipse, RAD, and implementing Maven Plug-ins or customizations in those environments, · Has ability to build Java applications using Maven and can demonstrate key technical concepts using RAD or Eclipse development tools. · Excellent written and verbal communications skills; ability to support software engineering life-cycle (requirements analysis, design alternatives; detail program specifications etc.) Document development may be required · Sonatype Nexus SME whose primary work focus repository development and management to support the implementation of FUSE. · Technical experience with the installing and customizing Sonatype Nexus on Solaris. · Technical development or scripting experience integrating with FUSE on Solaris. · Technical experience with Eclipse, RAD, and implementing Maven Plug-ins or customizations in those environments. · Has ability to build Java applications using RAD or Eclipse and can demonstrate key technical concepts for Nexus repository using the prescribed development development tools. · Excellent written and verbal communications skills; ability to support software engineering life-cycle (requirements analysis, design alternatives; detail program specifications etc.) Document development may be required. Thank You, Rick Waters Director of Resource Management Apex Government Solutions 816-547-1630 rwat...@apexgov.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What is this BoxEE support?
I'd guess that someone has email from this group forwarded to Boxee support. Either because they hate Boxee, or more likely, as an error somewhere. This may not be the fault of anyone at Boxee. -K On Dec 27, 2010, at 4:37 PM, Steve Cohen wrote: Who are they and who gave them the right to create tickets from posts to this list? I had no idea I was working with such an organization. If they are abusing this list, their rights to post here should be revoked. I never saw them until today. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What is this BoxEE support?
Eric or Wendy are more likely correct than I. -K On Dec 27, 2010, at 5:31 PM, Kathryn Huxtable wrote: I'd guess that someone has email from this group forwarded to Boxee support. Either because they hate Boxee, or more likely, as an error somewhere. This may not be the fault of anyone at Boxee. -K On Dec 27, 2010, at 4:37 PM, Steve Cohen wrote: Who are they and who gave them the right to create tickets from posts to this list? I had no idea I was working with such an organization. If they are abusing this list, their rights to post here should be revoked. I never saw them until today. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can I release:perform without release:prepare?
Well, it *was* working a few months ago when I did my last release. Now it fails. -K On Dec 21, 2010, at 2:50 AM, Stephen Connolly wrote: git reset --hard 792c6ebc7bc131a149b2a6fa1d73e7cbb56839a8 git push origin +master mvn release:clean mvn release:prepare release:perform -B should just work On 21 December 2010 08:46, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I normally just keep on doing the release:prepare until it works given that it resumes from the point of failure On 21 December 2010 04:00, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: I've already manually done the release:prepare because for some reason my release:prepare didn't successfully push to github. I'm using Maven 2.2.1. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can I release:perform without release:prepare?
I'm releasing to Sonatype, staging to Central. -K On Dec 21, 2010, at 2:11 AM, Anders Hammar wrote: Should work if you do everything correctly. It would be similar to executing the release:perform at a later stage (not directly after release:prepare): mvn release:perform -DworkingDirectory=xxx -DconnectionUrl=xxx -Dtag=xxx I think you can skip workingDirectory. Also, the line above is what I use for clearcase. You might need to add some param depending on your scm. /Anders On Tue, Dec 21, 2010 at 05:00, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: I've already manually done the release:prepare because for some reason my release:prepare didn't successfully push to github. I'm using Maven 2.2.1. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can I release:perform without release:prepare?
Dumb me. That's for the perform. -K On Dec 21, 2010, at 7:19 AM, Kathryn Huxtable wrote: I'm releasing to Sonatype, staging to Central. -K On Dec 21, 2010, at 2:11 AM, Anders Hammar wrote: Should work if you do everything correctly. It would be similar to executing the release:perform at a later stage (not directly after release:prepare): mvn release:perform -DworkingDirectory=xxx -DconnectionUrl=xxx -Dtag=xxx I think you can skip workingDirectory. Also, the line above is what I use for clearcase. You might need to add some param depending on your scm. /Anders On Tue, Dec 21, 2010 at 05:00, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: I've already manually done the release:prepare because for some reason my release:prepare didn't successfully push to github. I'm using Maven 2.2.1. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can I release:perform without release:prepare?
So I have the following in my pom: scm connectionscm:git:git://github.com/khuxtable/wagon-gitsite.git/connection developerConnectionscm:git:git+ssh://g...@github.com/khuxtable/wagon-gitsite.git/developerConnection urlhttp://github.com/khuxtable/wagon-gitsite/url /scm Is the problem the format of the developerConnection element? If so, how would I specify it correctly and get SSH? -K On Dec 21, 2010, at 7:18 AM, Kathryn Huxtable wrote: Well, it *was* working a few months ago when I did my last release. Now it fails. -K On Dec 21, 2010, at 2:50 AM, Stephen Connolly wrote: git reset --hard 792c6ebc7bc131a149b2a6fa1d73e7cbb56839a8 git push origin +master mvn release:clean mvn release:prepare release:perform -B should just work On 21 December 2010 08:46, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I normally just keep on doing the release:prepare until it works given that it resumes from the point of failure On 21 December 2010 04:00, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: I've already manually done the release:prepare because for some reason my release:prepare didn't successfully push to github. I'm using Maven 2.2.1. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can I release:perform without release:prepare?
Thanks, I'll give that syntax a try. I'm of the opinion that the function key should be to the right of the control key. The control key should be the leftmost key. That said, I use a MacBook Pro and it's the other way. De gustibus... -K On Dec 21, 2010, at 9:00 AM, Stephen Connolly wrote: Damn you lenova laptop keyboard... who put's Fn where Ctrl should be https://github.com/stephenc/high-scale-lib/blob/master/pom.xml On 21 December 2010 15:00, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Here is a pom that I have working On 21 December 2010 13:57, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: So I have the following in my pom: scm connectionscm:git:git://github.com/khuxtable/wagon-gitsite.git /connection developerConnectionscm:git:git+ssh:// g...@github.com/khuxtable/wagon-gitsite.git/developerConnection urlhttp://github.com/khuxtable/wagon-gitsite/url /scm Is the problem the format of the developerConnection element? If so, how would I specify it correctly and get SSH? -K On Dec 21, 2010, at 7:18 AM, Kathryn Huxtable wrote: Well, it *was* working a few months ago when I did my last release. Now it fails. -K On Dec 21, 2010, at 2:50 AM, Stephen Connolly wrote: git reset --hard 792c6ebc7bc131a149b2a6fa1d73e7cbb56839a8 git push origin +master mvn release:clean mvn release:prepare release:perform -B should just work On 21 December 2010 08:46, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I normally just keep on doing the release:prepare until it works given that it resumes from the point of failure On 21 December 2010 04:00, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: I've already manually done the release:prepare because for some reason my release:prepare didn't successfully push to github. I'm using Maven 2.2.1. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Can I release:perform without release:prepare?
I've already manually done the release:prepare because for some reason my release:prepare didn't successfully push to github. I'm using Maven 2.2.1. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: git as deploy target
Yes, it's available on central at org.kathrynhuxtable.maven.wagon.wagon-gitsite:0.2, and the docs are at http://khuxtable.github.com/wagon-gitsite/ There are a few minor improvements I'd like to make, the main one being to create the gh-pages branch if it doesn't exist, but it works, at least with Maven 2. I haven't tried with Maven 3 yet, because I have other fish to fry at the moment. -K On Nov 30, 2010, at 5:31 PM, Benson Margulies wrote: Back in March, there was a thread involving Kathryn Huxtable and deploying to git via the scm provider. I have a vague sense that she subsequently reported success here. Kathryn, are you reading this? Did you get it to work? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: git as deploy target
I should point out that this was intended to deploy site documentation, not artifacts. Did you want artifacts? That should be doable, but probably not with the existing code. I rather think that the ssh wagon would be sufficient. -K On Nov 30, 2010, at 5:48 PM, Kathryn Huxtable wrote: Yes, it's available on central at org.kathrynhuxtable.maven.wagon.wagon-gitsite:0.2, and the docs are at http://khuxtable.github.com/wagon-gitsite/ There are a few minor improvements I'd like to make, the main one being to create the gh-pages branch if it doesn't exist, but it works, at least with Maven 2. I haven't tried with Maven 3 yet, because I have other fish to fry at the moment. -K On Nov 30, 2010, at 5:31 PM, Benson Margulies wrote: Back in March, there was a thread involving Kathryn Huxtable and deploying to git via the scm provider. I have a vague sense that she subsequently reported success here. Kathryn, are you reading this? Did you get it to work? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: git as deploy target
Maybe I'm confused. I meant using the git protocol over ssh using the standard git wagon. My wagon allows you to specify a branch, but that's it. -K On Nov 30, 2010, at 7:04 PM, Benson Margulies wrote: I have a particularly nefarious plot. I want to use this to push an eclipse update site to github via the sonatype maven-update-plugin. Can I add more pathname to the end of the urls? Your reference to ssh leads me to believe that I'm confused. How does one use ssh to push files to github? I seem to have missed something basic. On Tue, Nov 30, 2010 at 6:50 PM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: I should point out that this was intended to deploy site documentation, not artifacts. Did you want artifacts? That should be doable, but probably not with the existing code. I rather think that the ssh wagon would be sufficient. -K On Nov 30, 2010, at 5:48 PM, Kathryn Huxtable wrote: Yes, it's available on central at org.kathrynhuxtable.maven.wagon.wagon-gitsite:0.2, and the docs are at http://khuxtable.github.com/wagon-gitsite/ There are a few minor improvements I'd like to make, the main one being to create the gh-pages branch if it doesn't exist, but it works, at least with Maven 2. I haven't tried with Maven 3 yet, because I have other fish to fry at the moment. -K On Nov 30, 2010, at 5:31 PM, Benson Margulies wrote: Back in March, there was a thread involving Kathryn Huxtable and deploying to git via the scm provider. I have a vague sense that she subsequently reported success here. Kathryn, are you reading this? Did you get it to work? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
It uploads the site documentation using the site:deploy target, the same as any Maven site deploy. If you have generated source listings, those will be uploaded. Yes, it is separate from source commits. That's standard. Apparently the Maven developers rather wish that site generation hadn't been included in the POM, but since it is, they're not removing it. To them, the source and documentation are completely separate. You'd like documentation to be generated, released, and tagged simultaneously with a release:prepare target? That's probably doable with a plugin. The plugin may not currently exist, however. -K On Oct 26, 2010, at 2:14 PM, Kenneth McDonald wrote: Kathyrn I greatly appreciate the feedback. I've looked at using your system but (correct me if I'm wrong), it doesn't maintain simulteneity of source and docs. In other words, I have to upload the docs seperately from the source? This is important to me. I regard a release as a juxtaposition of properly correlated source and docs. That's what I'm aiming at. Thanks, Ken On Oct 25, 2010, at 9:54 AM, Kathryn Huxtable wrote: I have a plugin (org.kathrynhuxtable.maven.wagon.wagon-gitsite) that uploads your site documentation to github. It hasn't been verified to work with Maven 3 yet. The docs are at http://khuxtable.github.com/wagon-gitsite/, if you're interested. -K On Oct 23, 2010, at 4:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how
Re: [Repetitive]: Maven does not live up to its promises
I have a plugin (org.kathrynhuxtable.maven.wagon.wagon-gitsite) that uploads your site documentation to github. It hasn't been verified to work with Maven 3 yet. The docs are at http://khuxtable.github.com/wagon-gitsite/, if you're interested. -K On Oct 23, 2010, at 4:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a) This one really pisses me off because I suspect it's absolutely true. I believe that Apache has a large number of very talented programmers, and I believe they are, in large respect, wasting their time because they have come to worship XML. I don't get it. There are things for which XML is appropriate. There are also so many things for which it's not, that why would you spend all of your time there? I don't have an answer. Anyway /end of rant Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
First off, I think Maven is great. I'm in the middle of stuff, so I'm not moving to Maven 3 until I get to a good stopping place. (Probably about six months or so.) On Oct 15, 2010, at 9:20 AM, Graham Leggett wrote: Guy who wrote ant build script is spontaneously thrown out of the third floor plate glass window. Ah. Spontaneous human defenestration! Next week on Fringe. Or something. Anyway, very nice. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
It does. The rest of the language is rather ugly, though. -K
On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote:
I just enjoyed the bit about perl having elegant and concise data structures
:-)
On 10/13/10 9:57 AM, chemit che...@codelutin.com wrote:
Le Wed, 13 Oct 2010 08:58:27 -0400,
Ron Wheeler rwhee...@artifact-software.com a écrit :
Doing the wrong thing and not using an IDE with a POM editor is not
a good recipe for a smooth development cycle.
I will admit to occasionally editing XML but that is for extreme
cases while you are getting set up..
euh wrong person :)
You should have respond to previous mail, ... I love maven and all the
xml stuff (arch to su much in facts.) I was just responding to the guy
Kenneth which seems to be pretty angry with Maven and xml ;)
If you don't like XML:
1) Get your development workflow Mavenized
2) Get a Maven Repo set up
3) Restructure your projects to fit the way Maven works
3) Use an IDE that supports Maven with a proper human oriented editor
- Eclipse STS is very good at this.
Then you will have no need of XML editing and no need to screw around
with command line Maven or custom plug-ins or custom goals.
You will not spend a lot of time in this forum moaning about the
unfairness of life and the difficulty of using Maven.
Once you start using Maven properly, it is a very high level tool for
building Java applications such as:
Java WebServices
Java Servlets
Java Portlets
Java Standalone applications
If you are building something else, my comments may not be relevant.
Ron
On 13/10/2010 2:47 AM, chemit wrote:
Le Tue, 12 Oct 2010 19:35:46 -0500,
Kenneth McDonaldkenneth.m.mcdon...@sbcglobal.net a écrit :
Yes, I realize this is flamebait, but after trying to puzzle out
the following maven plugin:
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.6/version
executions
execution
phasedeploy/phase
iddeploy-gh-pages/id
goals
goalrun/goal
/goals
configuration
target
property name=gh-pages-dir
location=/ exec executable=git dir=${gh-pages-dir}
arg line=add ./
/exec
exec executable=git
dir=${gh-pages-dir} arg line=commit/
/exec
exec executable=git
dir=${gh-pages-dir} arg line=push origin gh-pages/
/exec
/target
/configuration
/execution
/executions
/plugin
I simply can't resist. Whoever in their right mind decided software
developers to think that requiring other developers to write config
files in XML was a proper decision?
Python, Ruby, and (yes even Perl) have had had much more elegant
and concise ways of managing complex data structures for years
now. And there's a reason JSON has become so popular--primarily
because XML is not, and was never intended to be, a format for
developers to write specifications in.
First of all using the ant plugin is against Best pratices, so
for me and from this point, why critisize something when you are
doing it the wrong way ?
Let's take a look at the most obvious of the problems in the above:
property name=gh-pages-dir
location=/ exec executable=git dir=${gh-pages-dir}
arg line=add ./
/exec
exec executable=git
dir=${gh-pages-dir} arg line=commit/
/exec
exec executable=git
dir=${gh-pages-dir} arg line=push origin gh-pages/
/exec
Now, I'm still very new to maven, but it strikes me that what the
above is saying is (in Pythonic code, but feel free to convert to
your own):
import git
gh-pages-dir =
git(dir=gh-pages-dir, add .)
git(dir=gh-pages-dir, commit)
git(dir=gh-pages-dir, push origin gh-pages)
I'm sure there are errors in the translation--but I'm equally sure
that if these errors were corrected, they would not substantially
alter the ratio of XML to Pythonic code. Ruby and even Perl would
do just as well.
but if it is so simple as you say, you should be able to write your
simply code without any doubt...
So here's a challenge to the (very intelligent) folks at apache.
Open your minds to the fact that XML is not only the Final
Solution, but isn't even close to the best solution, and start
producing some products that are configurable without an entire
manual in front of oneself.
Re: maven-1.1 build-bootstrap fails with OpenVMS
Egads, is anyone still using Maven 1? If so, why? -K On Aug 24, 2010, at 11:40 AM, Wayne Fay wrote: Wasting time? How do I force BASIC authentication using maven-1.1 either with maven-1.1 or maybe I can do it outside maven-1.1-code through a Let me be more plain... you are WASTING YOUR TIME trying to fix Maven1. Perhaps you understand me better now? Find the simplest thing that could possibly work -- just download the artifacts into the proper spot in your local filesystem -- and get on with the more important things, which is apparently debugging your problems Axis. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh released dependencies
On Aug 6, 2010, at 12:57 PM, Kalle Korhonen wrote: On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric ehas...@transunion.com wrote: -Original Message- I don't (yet) know much about the internals of maven, but is it really that much of an impact on the code? There's already support present for checking for differences in snapshot versions, right? I'm imagining that making it work for release artifacts would be a matter of not distinguishing between release and snapshot artifacts and having the check apply to both. It sounds like you think it'll be harder to do than that; what I am missing? What you are asking is absurd. That's the exact difference between snapshots and releases; snapshots should be updated and releases shouldn't. Why would you insist on removing this differentiation? Wouldn't it be easier for you to just use snapshots if you need to check for updates? What Katie (and others) said! I have my differences with the current Maven philosophy, but one thing that has been baked in from the beginning is that artifact coordinates imply a fixed thing. The artifact does not change. That's one of the *points* of Maven. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh released dependencies
On Aug 6, 2010, at 1:00 PM, Haszlakiewicz, Eric wrote: -Original Message- From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric ehas...@transunion.com wrote: -Original Message- I don't (yet) know much about the internals of maven, but is it really that much of an impact on the code? There's already support present for checking for differences in snapshot versions, right? I'm imagining that making it work for release artifacts would be a matter of not distinguishing between release and snapshot artifacts and having the check apply to both. It sounds like you think it'll be harder to do than that; what I am missing? What you are asking is absurd. That's the exact difference between snapshots and releases; snapshots should be updated and releases shouldn't. Why would you insist on removing this differentiation? Wouldn't it be easier for you to just use snapshots if you need to check for updates? Please read the rest of the email thread. The short summary is: Yes, I know what *should* happen, but the world isn't perfect and release artifacts DO sometimes change. It is not absurd to be able to detect and recover from that kind of situation. Eric, you're not going to win this one. It's part of the philosophy of Maven. It's also good practice. Give it up. I'm not going to fight the site generation being split out of Maven. I think I understand Jason's point on that, though I disagree. And that's a *much* less nasty violation of Maven's perceived function, if in fact, it is a violation. What you're wanting is a violation. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh released dependencies
I second this! I've used Artifactory and liked it. (I somewhat prefer Nexus, at least the last time I looked at Artifactory.) -K On Aug 6, 2010, at 1:47 PM, Yoav Landman wrote: You may want to take a look at the CI integration in Artifactory - http://wiki.jfrog.org/confluence/display/RTF/Build+Integration You can get a json object with a report of all this information captured at build time: detailed build environment information, published artifacts and resolved dependencies of all scopes. Like many have commented here, re-downloading cached release artifacts if you run your build from scratch should be done from the caches of your repo manager. Yoav On Sat, Jul 31, 2010 at 12:07 AM, Shan Syed shan...@gmail.com wrote: no, this isn't in regard to our own published artifacts I regret starting this thread, I apologize I didn't mean this question to be an affront to maven conventions - I just need to figure out a better way to capture a full log they even want a log of how the build environment was downloaded and installed On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict pbened...@apache.org wrote: There is a maxim to follow when deploying: do not redeploy a version more than once. Once you deploy version X.Y.Z, it should never be updated, and those who download it never need to download it again. So, back to the original problem, are you guys doing that? On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed shan...@gmail.com wrote: it only applies to our final release cuts, not our day-to-day just once for this project really; I wanted to insert such this switch (if existed) in our delivery build profile we use archiva for everything else, and actually only make use of public maven repositories when we up a version of our dependencies, which is rare because of change control it's all weird stuff, I know, but sometimes I just don't question it On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wayne...@gmail.com wrote: deleting the m2 works, I was just curious to see if there was a switch in maven to force all downloads again This makes absolutely no sense, doesn't change your BOM, and is just wasteful. Consumes bandwidth unnecessarily from a resource that is being used by the whole Maven community. I'd think that if you had enough developers doing this on every machine on a consistent basis (eg every build), it might add up to enough traffic to get you on a blacklist somewhere... You really need to install Nexus or another MRM, this is just plain dumb. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh released dependencies
On Aug 6, 2010, at 2:58 PM, Paul Benedict wrote: On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric ehas...@transunion.comwrote: You're missing the point of what I'm asking. I'm not suggesting that maven make it possible or easy to *create* the violation. I'm suggesting that it should be able to *detect* the violation. I'm baffled as to why the maven community is so against the idea of having additional (optional) checks to detect problems. Eric, The point is releases don't change. To detect means wasting bandwidth comparing your supposedly unchanging released local artifacts to supposedly unchanging released remote artifacts. If anything, writing a Maven plug-in for this would be more appropriate, but I don't see your suggestion as part of Maven core. And actually, it wouldn't be that hard to write such a plugin. But you have to want it... -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh released dependencies
On Aug 6, 2010, at 6:16 PM, Ron Wheeler wrote: On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote: -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? If you can not deploy the release, that will tell you that you are trying to rerelease an artifact. Maybe you'll get lucky and something is different enough in your artifact that the build process fails. Your attempt to deploy will fail. That will tell you right away that you are doing the wrong thing. No, the deployment of a project that USES a changed artifact will NOT fail. Yes. That is why releases can not be replaced. In your case, you should have deleted the wrong artifacts and loaded them with new versions. And informed the victims that they needed to update their dependencies. You were completely in control of the versions and names. And, frustrating though it is, that's what I've done when my bad QC has released bad stuff onto Central. You just put out another version and apologize on the web page. There's not a lot else to do, and it's not that bad. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 Shell CLI: how to use?
And given that the reporting stuff is baked into the pom, I'd consider that stuff to be part of Maven, but apparently you folks disagree. I think you're very wrong. Not about the shell, but about site, etc. -K On Jul 2, 2010, at 2:56 PM, Jason van Zyl wrote: Open source project plans always change. Maven 3.x itself is the priority, full support for the shell will come when that's finished first. On Jul 2, 2010, at 3:53 PM, asookazian wrote: http://www.parleys.com/#sl=34st=5id=1630 see 32:05! -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-Shell-CLI-how-to-use-tp512715p512748.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3 Shell CLI: how to use?
If it had been that way from the start, I suppose I'd agree. But it wasn't. If it had changed with Maven 2, I suppose I'd agree. Well, we'll see what happens. -K On Jul 2, 2010, at 3:21 PM, Jason van Zyl wrote: On Jul 2, 2010, at 4:15 PM, Kathryn Huxtable wrote: And given that the reporting stuff is baked into the pom, I'd consider that stuff to be part of Maven, but apparently you folks disagree. I think you're very wrong. We emphatically disagree. But we've put in all the hooks so that it can remain in the POM so that the folks who want to maintain the site plugin can preserve backward compatibility for users. You're more then welcome to support the site plugin effort. Reporting is a separate concern from building which is why we separated them. That they are decoupled is a good thing. I believe it should be removed from the POM and all the configuration should go to the site plugin. This way other implementations for producing sites can also follow the same pattern. Not about the shell, but about site, etc. -K On Jul 2, 2010, at 2:56 PM, Jason van Zyl wrote: Open source project plans always change. Maven 3.x itself is the priority, full support for the shell will come when that's finished first. On Jul 2, 2010, at 3:53 PM, asookazian wrote: http://www.parleys.com/#sl=34st=5id=1630 see 32:05! -- View this message in context: http://maven.40175.n5.nabble.com/Maven-3-Shell-CLI-how-to-use-tp512715p512748.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site docs in Maven 3
Where is beta-7? As a side note, the developers had better not release version 3 until the site plugins and other major elements are actually ready. They did this with Maven 2 and it was hell. I know because I went through it. On a side note, I decided that Tycho wasn't worth it for as simple a plugin as mine was. It was just more trouble. Again, this has to do with not really being ready more than anything else, and having rather incomplete documentation. -K On Jun 30, 2010, at 3:46 AM, Olivier Lamy wrote: Hi, Have a look here : https://cwiki.apache.org/confluence/x/sokr Note : doesn't work with beta-1 (you have to use beta-7 or current maven3 trunk) 2010/6/30 Kathryn Huxtable kath...@kathrynhuxtable.org: Is there a version of the report generation that works? -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy http://www.viadeo.com/fr/profile/olivier.lamy7 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site docs in Maven 3
You'll find out... BTW, Sent from my iPad (or iPhone) is the first thing I change when I get a device like that. -K On Jul 1, 2010, at 7:22 AM, Brian Fox wrote: Since the site stuff is fully decoupled from core, it shouldn't really matter if site is done. Most people run the site build separately from a ci system anyway and for the time being you could use m2 if needed. For all the goodness m3 provides, I don't think the site plugin which has a separate release lifecycle should hold it up Sent from my iPad On Jul 1, 2010, at 3:20 AM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: Where is beta-7? As a side note, the developers had better not release version 3 until the site plugins and other major elements are actually ready. They did this with Maven 2 and it was hell. I know because I went through it. On a side note, I decided that Tycho wasn't worth it for as simple a plugin as mine was. It was just more trouble. Again, this has to do with not really being ready more than anything else, and having rather incomplete documentation. -K On Jun 30, 2010, at 3:46 AM, Olivier Lamy wrote: Hi, Have a look here : https://cwiki.apache.org/confluence/x/sokr Note : doesn't work with beta-1 (you have to use beta-7 or current maven3 trunk) 2010/6/30 Kathryn Huxtable kath...@kathrynhuxtable.org: Is there a version of the report generation that works? -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy http://www.viadeo.com/fr/profile/olivier.lamy7 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site docs in Maven 3
Heh! I like that! I change mine to my usual -K signature that I've been using since the late 1980s. Before that I used my full name. -K, who would like a larger screen than her iPhone, and is dithering between several choices. My contract is up in September. I'm in Overland Park, KS, and thus am quite familiar with Sprint's behavior towards its employees. I will not get a Sprint phone if they are the only carrier in the US. On Jul 1, 2010, at 1:27 PM, Stephen Connolly wrote: AFAIK, When I first got a device like that, Brian might even have been one of the people who complained about the tag line (which I subsequently change to Send from my rhymes with myPod) On 1 July 2010 18:33, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: BTW, Sent from my iPad (or iPhone) is the first thing I change when I get a device like that. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Site docs in Maven 3
Is there a version of the report generation that works? -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Developing Eclipse plugin with Maven
Are there any *good* guides to building an Eclipse plugin using Maven, preferably in a way that allows it to be developed in Eclipse? I don't really have any dependencies other than standard Eclipse packages, but I want all the great lifecycle and site management tools that Maven supplies. I've seen: http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html by Peter H. Petersen, and Sumit Gupta, of Princeton Softech, from 2006. I've also seen: https://cwiki.apache.org/UIMA/building-eclipse-plugins-with-maven-bundle-plugin-and-friends.html by Marshall Schor, from 2008. Are these reasonable? Is there something newer? The former is what you get when you search the eclipse site. It's pretty crude. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Developing Eclipse plugin with Maven
Thanks! -K On Jun 25, 2010, at 4:04 PM, Jason van Zyl wrote: Tycho. http://tycho.sonatype.org It's used to build M2Eclipse, Eclipse EGit, Eclipse Memory Analyzer, and Antlr IDE. Sources: http://github.com/sonatype/sonatype-tycho Integration tests specifically which shows how to build everything from plugins the products: http://github.com/sonatype/sonatype-tycho/tree/master/tycho-its/projects/ On Jun 25, 2010, at 4:53 PM, Kathryn Huxtable wrote: Are there any *good* guides to building an Eclipse plugin using Maven, preferably in a way that allows it to be developed in Eclipse? I don't really have any dependencies other than standard Eclipse packages, but I want all the great lifecycle and site management tools that Maven supplies. I've seen: http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html by Peter H. Petersen, and Sumit Gupta, of Princeton Softech, from 2006. I've also seen: https://cwiki.apache.org/UIMA/building-eclipse-plugins-with-maven-bundle-plugin-and-friends.html by Marshall Schor, from 2008. Are these reasonable? Is there something newer? The former is what you get when you search the eclipse site. It's pretty crude. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Developing Eclipse plugin with Maven
BTW, what I'm developing is a relatively throwaway plugin for Mac Cocoa Eclipse to set the represented filename for the active editor in the associated window. This enables software such as DTerm, which provides a convenient terminal window, to correctly get the directory associated with the active file. I'm using DTerm because EGit/JGit aren't really complete yet and I need command-line git. If good support for git svn isn't built into EGit at some point, I'll probably always need DTerm. The current non-mavenized plugin is at http://github.com/khuxtable/eclipse-cocoa-set-represented-filename It works, but I want it mavenized. -K On Jun 25, 2010, at 4:04 PM, Jason van Zyl wrote: Tycho. http://tycho.sonatype.org It's used to build M2Eclipse, Eclipse EGit, Eclipse Memory Analyzer, and Antlr IDE. Sources: http://github.com/sonatype/sonatype-tycho Integration tests specifically which shows how to build everything from plugins the products: http://github.com/sonatype/sonatype-tycho/tree/master/tycho-its/projects/ On Jun 25, 2010, at 4:53 PM, Kathryn Huxtable wrote: Are there any *good* guides to building an Eclipse plugin using Maven, preferably in a way that allows it to be developed in Eclipse? I don't really have any dependencies other than standard Eclipse packages, but I want all the great lifecycle and site management tools that Maven supplies. I've seen: http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html by Peter H. Petersen, and Sumit Gupta, of Princeton Softech, from 2006. I've also seen: https://cwiki.apache.org/UIMA/building-eclipse-plugins-with-maven-bundle-plugin-and-friends.html by Marshall Schor, from 2008. Are these reasonable? Is there something newer? The former is what you get when you search the eclipse site. It's pretty crude. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Developing Eclipse plugin with Maven
Will this work with the released tycho (0.8.0) or does it need the 0.9.0-SNAPSHOT versions? -K On Jun 25, 2010, at 4:41 PM, Jason van Zyl wrote: Change the names accordingly, but you should be able to drop this in and build with Maven 3: http://gist.github.com/453490 This won't work with Maven 2.x. On Jun 25, 2010, at 5:10 PM, Kathryn Huxtable wrote: BTW, what I'm developing is a relatively throwaway plugin for Mac Cocoa Eclipse to set the represented filename for the active editor in the associated window. This enables software such as DTerm, which provides a convenient terminal window, to correctly get the directory associated with the active file. I'm using DTerm because EGit/JGit aren't really complete yet and I need command-line git. If good support for git svn isn't built into EGit at some point, I'll probably always need DTerm. The current non-mavenized plugin is at http://github.com/khuxtable/eclipse-cocoa-set-represented-filename It works, but I want it mavenized. -K On Jun 25, 2010, at 4:04 PM, Jason van Zyl wrote: Tycho. http://tycho.sonatype.org It's used to build M2Eclipse, Eclipse EGit, Eclipse Memory Analyzer, and Antlr IDE. Sources: http://github.com/sonatype/sonatype-tycho Integration tests specifically which shows how to build everything from plugins the products: http://github.com/sonatype/sonatype-tycho/tree/master/tycho-its/projects/ On Jun 25, 2010, at 4:53 PM, Kathryn Huxtable wrote: Are there any *good* guides to building an Eclipse plugin using Maven, preferably in a way that allows it to be developed in Eclipse? I don't really have any dependencies other than standard Eclipse packages, but I want all the great lifecycle and site management tools that Maven supplies. I've seen: http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html by Peter H. Petersen, and Sumit Gupta, of Princeton Softech, from 2006. I've also seen: https://cwiki.apache.org/UIMA/building-eclipse-plugins-with-maven-bundle-plugin-and-friends.html by Marshall Schor, from 2008. Are these reasonable? Is there something newer? The former is what you get when you search the eclipse site. It's pretty crude. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Developing Eclipse plugin with Maven
Okay, I answered that myself. (Yes.) -K On Jun 25, 2010, at 4:54 PM, Kathryn Huxtable wrote: Will this work with the released tycho (0.8.0) or does it need the 0.9.0-SNAPSHOT versions? -K On Jun 25, 2010, at 4:41 PM, Jason van Zyl wrote: Change the names accordingly, but you should be able to drop this in and build with Maven 3: http://gist.github.com/453490 This won't work with Maven 2.x. On Jun 25, 2010, at 5:10 PM, Kathryn Huxtable wrote: BTW, what I'm developing is a relatively throwaway plugin for Mac Cocoa Eclipse to set the represented filename for the active editor in the associated window. This enables software such as DTerm, which provides a convenient terminal window, to correctly get the directory associated with the active file. I'm using DTerm because EGit/JGit aren't really complete yet and I need command-line git. If good support for git svn isn't built into EGit at some point, I'll probably always need DTerm. The current non-mavenized plugin is at http://github.com/khuxtable/eclipse-cocoa-set-represented-filename It works, but I want it mavenized. -K On Jun 25, 2010, at 4:04 PM, Jason van Zyl wrote: Tycho. http://tycho.sonatype.org It's used to build M2Eclipse, Eclipse EGit, Eclipse Memory Analyzer, and Antlr IDE. Sources: http://github.com/sonatype/sonatype-tycho Integration tests specifically which shows how to build everything from plugins the products: http://github.com/sonatype/sonatype-tycho/tree/master/tycho-its/projects/ On Jun 25, 2010, at 4:53 PM, Kathryn Huxtable wrote: Are there any *good* guides to building an Eclipse plugin using Maven, preferably in a way that allows it to be developed in Eclipse? I don't really have any dependencies other than standard Eclipse packages, but I want all the great lifecycle and site management tools that Maven supplies. I've seen: http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html by Peter H. Petersen, and Sumit Gupta, of Princeton Softech, from 2006. I've also seen: https://cwiki.apache.org/UIMA/building-eclipse-plugins-with-maven-bundle-plugin-and-friends.html by Marshall Schor, from 2008. Are these reasonable? Is there something newer? The former is what you get when you search the eclipse site. It's pretty crude. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Developing Eclipse plugin with Maven
Okay, one more question: do the java sources have to be under src instead of src/main/java? If so, where do I put my site docs? -K On Jun 25, 2010, at 4:41 PM, Jason van Zyl wrote: Change the names accordingly, but you should be able to drop this in and build with Maven 3: http://gist.github.com/453490 This won't work with Maven 2.x. On Jun 25, 2010, at 5:10 PM, Kathryn Huxtable wrote: BTW, what I'm developing is a relatively throwaway plugin for Mac Cocoa Eclipse to set the represented filename for the active editor in the associated window. This enables software such as DTerm, which provides a convenient terminal window, to correctly get the directory associated with the active file. I'm using DTerm because EGit/JGit aren't really complete yet and I need command-line git. If good support for git svn isn't built into EGit at some point, I'll probably always need DTerm. The current non-mavenized plugin is at http://github.com/khuxtable/eclipse-cocoa-set-represented-filename It works, but I want it mavenized. -K On Jun 25, 2010, at 4:04 PM, Jason van Zyl wrote: Tycho. http://tycho.sonatype.org It's used to build M2Eclipse, Eclipse EGit, Eclipse Memory Analyzer, and Antlr IDE. Sources: http://github.com/sonatype/sonatype-tycho Integration tests specifically which shows how to build everything from plugins the products: http://github.com/sonatype/sonatype-tycho/tree/master/tycho-its/projects/ On Jun 25, 2010, at 4:53 PM, Kathryn Huxtable wrote: Are there any *good* guides to building an Eclipse plugin using Maven, preferably in a way that allows it to be developed in Eclipse? I don't really have any dependencies other than standard Eclipse packages, but I want all the great lifecycle and site management tools that Maven supplies. I've seen: http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html by Peter H. Petersen, and Sumit Gupta, of Princeton Softech, from 2006. I've also seen: https://cwiki.apache.org/UIMA/building-eclipse-plugins-with-maven-bundle-plugin-and-friends.html by Marshall Schor, from 2008. Are these reasonable? Is there something newer? The former is what you get when you search the eclipse site. It's pretty crude. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: About Maven3 M2Eclipse plug-in versioning problem
So how do I use my documentation-producing plugin in its own documentation
without a variable version number?
See http://github.com/khuxtable/docbkx-wrapper-plugin/blob/master/pom.xml for
an example. It's in the site profile near the bottom.
-K
On May 17, 2010, at 12:48 PM, Kalpak Gadre wrote:
Yes variable version names are not allowed as of Maven 3. I believe the
reason will be deploying into repositories, as pom with version as some
properties instead of a proper version could get deployed.
A quick fix is to configure Eclipse to use external installation of Maven 2.
But remember that variable versions will not be supported in the future
releases. I personally use version number derived out of properties for our
Continuous Integration server to generate the tick part of version
(1.0.0.[123]). I haven't personally found a solution yet using Maven 3.
Thanks,
Kalpak
Hi,
At first, thanks for your attention and time to read.
In our enterprise applications we use MyEclipse 8.5 with
M2Eclipse maven3 plug-in support. Before begining to use maven3, with maven2
we
could specify a variable for the application version in the parent pom, so
that
in the child poms we could able to specify the version by the same variable.
That helps us saving our time for updating version number in each project
upgrade and for reusability.
I hope I can clearly demonstrate the problem as the
following piece of code for pom.xml’s.
Now the problem is in maven3 (m2eclipse) it gives a warning
that says “version must be a constant instead of a variable”. I have been
trying lots of variations such as moving out theversion tag or
swapping the expressions betweenprojectVersion andversion
tags or the other suggestions from the different forum sites, etc.. However,
the solution never comes up.. Maybe I am doing something wrong, but could not
find out yet.
Any help would be appreciated,
Many thanks in advance,
Bariscan
BTW, you can check the case from here:
PARENT:
project
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdcom.gg.n3gservices/groupId
artifactIdn3gservices/artifactId
namen3gservices Maven
Main/name
packagingpom/packaging
descriptionVersion Alias:
MemberProfitLocalService/description
version${projectVersion}/version
properties
projectVersion2.4/projectVersion
/properties
Child;
project
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdcom.gg.n3gservices/groupId
artifactIdn3gservicesBugfix/artifactId
namen3gservices Bugfix/name
parent
artifactIdn3gservices/artifactId
groupIdcom.gg.n3gservices/groupId
relativePath../n3gservices/pom.xml/relativePath
version${projectVersion}/version
/parent
version${projectVersion}/version
_
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: About Maven3 M2Eclipse plug-in versioning problem
In the words of John McEnroe, you cannot be serious!
Okay, it can be worked around, not by Frank's suggestion about using a
preprocessor, which is, I think, antithetical to Maven's design.
But it's still moderately restrictive.
I don't like it.
-K
On May 17, 2010, at 4:37 PM, Stephen Connolly wrote:
you have to use the previously release version
On 17 May 2010 22:24, Kathryn Huxtable kath...@kathrynhuxtable.org wrote:
So how do I use my documentation-producing plugin in its own documentation
without a variable version number?
See http://github.com/khuxtable/docbkx-wrapper-plugin/blob/master/pom.xmlfor
an example. It's in the site profile near the bottom.
-K
On May 17, 2010, at 12:48 PM, Kalpak Gadre wrote:
Yes variable version names are not allowed as of Maven 3. I believe the
reason will be deploying into repositories, as pom with version as some
properties instead of a proper version could get deployed.
A quick fix is to configure Eclipse to use external installation of Maven
2. But remember that variable versions will not be supported in the future
releases. I personally use version number derived out of properties for our
Continuous Integration server to generate the tick part of version
(1.0.0.[123]). I haven't personally found a solution yet using Maven 3.
Thanks,
Kalpak
Hi,
At first, thanks for your attention and time to read.
In our enterprise applications we use MyEclipse 8.5 with
M2Eclipse maven3 plug-in support. Before begining to use maven3, with
maven2 we
could specify a variable for the application version in the parent pom,
so that
in the child poms we could able to specify the version by the same
variable.
That helps us saving our time for updating version number in each
project
upgrade and for reusability.
I hope I can clearly demonstrate the problem as the
following piece of code for pom.xml’s.
Now the problem is in maven3 (m2eclipse) it gives a warning
that says “version must be a constant instead of a variable”. I have
been
trying lots of variations such as moving out theversion tag or
swapping the expressions betweenprojectVersion andversion
tags or the other suggestions from the different forum sites, etc..
However,
the solution never comes up.. Maybe I am doing something wrong, but
could not
find out yet.
Any help would be appreciated,
Many thanks in advance,
Bariscan
BTW, you can check the case from here:
PARENT:
project
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdcom.gg.n3gservices/groupId
artifactIdn3gservices/artifactId
namen3gservices Maven
Main/name
packagingpom/packaging
descriptionVersion Alias:
MemberProfitLocalService/description
version${projectVersion}/version
properties
projectVersion2.4/projectVersion
/properties
Child;
project
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdcom.gg.n3gservices/groupId
artifactIdn3gservicesBugfix/artifactId
namen3gservices Bugfix/name
parent
artifactIdn3gservices/artifactId
groupIdcom.gg.n3gservices/groupId
relativePath../n3gservices/pom.xml/relativePath
version${projectVersion}/version
/parent
version${projectVersion}/version
_
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: feature request: more verbose error messages
If you want this to ever be seen by someone who might possible implement your suggestion, you must file it in Jira. Otherwise you are quite literally talking to a brick wall. Really, Wayne? Literally? Where is the wall? -K, who thinks Wayne meant figuratively. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: feature request: more verbose error messages
Indeed. I think you made your point. I just couldn't help myself. And to Neil, I read xkcd regularly. Sometimes it leaves me bewildered, sometimes it just doesn't work for me, and sometimes it's hilarious or insightful. -K On May 10, 2010, at 9:59 AM, Wayne Fay wrote: quite literally talking to a brick wall. Really, Wayne? Literally? Where is the wall? -K, who thinks Wayne meant figuratively. But what you don't realize is that I have a special computer with text to speech software set up in my basement that reads all my email to me. And when I'm not around, only the brick walls can hear it. Wayne, who is known to exaggerate and simply wanted to communicate that the maven users list is a poor place to post feature requests - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release plugin git repo with multiple projects
Having recently switched from svn to git for most of my projects, I have an opinion. I think you should create a JIRA ticket and consider this a bug. What we're dealing with here is a bit of svn-centric thinking during design. It needs to be fixed. -K On Apr 26, 2010, at 8:08 AM, Jean-Laurent de Morlhon wrote: We're considering migrating from svn to git, we stumble on the maven-release-plugin usage with git. We think we prefer to use a single repository for many independently built projects like : foobar-repo.git |- project-foo/ ||- pom.xml ||– module A/ ||- module B/ | |- project-bar/ |- pom.xml project-bar scm url looks like : connectionscm:git:ssh://somehost.nowhere:/foobar-repo.git /connection This hints to the right repository but I can't write that the actual project-bar is in the project-bar subdirectory. mvn release:prepare goes well and ends succesfully. mvn release:perform fails whenever it tries to build the project from the tag. It effectively clone correctly the repository. But use the root of the repository rather than going into project-bar subdirectory whenever it tries to clean deploy the tag. This prevent using git and multiple projects in the same directory. Some may think we should use gitmodules but 1) the release plugin does not support it [1] 2) gitmodules is an aggregate of single repository Should I issue a new feature ticket into jira project MRELEASE or SCM ? Or should I fall back to the current convention of 1 project = 1 git repository ?? Or maybe someone managed to do it ? any advice appreciated. [1] : http://jira.codehaus.org/browse/SCM-530 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release plugin git repo with multiple projects
Perhaps I wasn't clear. I don't support multiple projects in one repository. Definitely not. I was trying to criticize the svn-centric thinking, not support it. I think there should be a JIRA issue to make modules work, given that they'll be in separate repositories. I'm not going to file this because I have almost zero experience with nested projects. There have been places it would have made sense and I shied away. But the release plugin should work with git projects that have modules and it should do it in the standard git manner, which is one repository containing one project. (Distributed, of course.) -K On Apr 26, 2010, at 9:06 AM, Justin Edelson wrote: Kathryn- Maybe I'm misunderstanding what you mean, but I think you have this exactly backwards. The svn-centric thinking is what's inspired someone to put multiple projects in the same repository. AFAIK, this is simply not supported by git, i.e. there's no way to clone, branch or tag _part_ of a repository. I am by no means a git expert, so I could be mistaken about this. Justin On 4/26/10 9:21 AM, Kathryn Huxtable wrote: Having recently switched from svn to git for most of my projects, I have an opinion. I think you should create a JIRA ticket and consider this a bug. What we're dealing with here is a bit of svn-centric thinking during design. It needs to be fixed. -K On Apr 26, 2010, at 8:08 AM, Jean-Laurent de Morlhon wrote: We're considering migrating from svn to git, we stumble on the maven-release-plugin usage with git. We think we prefer to use a single repository for many independently built projects like : foobar-repo.git |- project-foo/ ||- pom.xml ||– module A/ ||- module B/ | |- project-bar/ |- pom.xml project-bar scm url looks like : connectionscm:git:ssh://somehost.nowhere:/foobar-repo.git /connection This hints to the right repository but I can't write that the actual project-bar is in the project-bar subdirectory. mvn release:prepare goes well and ends succesfully. mvn release:perform fails whenever it tries to build the project from the tag. It effectively clone correctly the repository. But use the root of the repository rather than going into project-bar subdirectory whenever it tries to clean deploy the tag. This prevent using git and multiple projects in the same directory. Some may think we should use gitmodules but 1) the release plugin does not support it [1] 2) gitmodules is an aggregate of single repository Should I issue a new feature ticket into jira project MRELEASE or SCM ? Or should I fall back to the current convention of 1 project = 1 git repository ?? Or maybe someone managed to do it ? any advice appreciated. [1] : http://jira.codehaus.org/browse/SCM-530 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release plugin git repo with multiple projects
Although you can create a new git repo, add a remote, and then pull a single branch. Not the same as checking out a directory from svn, but you don't *have* to get the entire repo. I use this in my wagon-gitsite app to push docs to the gh-pages branch of github projects. -K On Apr 26, 2010, at 3:18 PM, Justin Edelson wrote: Jean-Laurent de Morlhon wrote: You say the git way of doing things is 1 project - 1 git repository, I understand, and it's not very far of having a svn repo for every project in svn altough the release plugin do not enforce this. Subversion doesn't enforce this. In fact, Subversion is designed to support a 1 to many relationship between projects and repositories whereas Git is designed for a 1 to 1 relationship. This has nothing to do with Maven. The current state of the release plugin force you to have the pom.xml at the root of your git repository or to say it differently if you have a pom.xml anywhere else than the root directory you can't release the project. (of course submodule of root located pom.xml do not count)... It's also common practice in the maven world to have a parent pom to share common settings. If I follow blindlessly the 1 project - 1 git repository, it means I have to setup a git repository for a single parent pom ? A multi-module project should be in a single git repository. An organizational pom should be in its own repository which may, you are correct, result in a repository with a single file in it. I have the feeling, but I maybe wrong, that this is more a limitation of the release plugin / scm provider more than a design goal. No. It's a design goal. See https://git.wiki.kernel.org/index.php/GitSvnComparison#Partial_Checkout.2FUsed_bandwidth Justin Those who migrated to git, what do you do for the above cases, especially the parent pom one ? Jean-Laurent On Mon, Apr 26, 2010 at 5:37 PM, Justin Edelson justinedel...@gmail.com mailto:justinedel...@gmail.com wrote: OK. Then we're on the same page... On 4/26/10 11:32 AM, Kathryn Huxtable wrote: Perhaps I wasn't clear. I don't support multiple projects in one repository. Definitely not. I was trying to criticize the svn-centric thinking, not support it. I think there should be a JIRA issue to make modules work, given that they'll be in separate repositories. I'm not going to file this because I have almost zero experience with nested projects. There have been places it would have made sense and I shied away. But the release plugin should work with git projects that have modules and it should do it in the standard git manner, which is one repository containing one project. (Distributed, of course.) -K On Apr 26, 2010, at 9:06 AM, Justin Edelson wrote: Kathryn- Maybe I'm misunderstanding what you mean, but I think you have this exactly backwards. The svn-centric thinking is what's inspired someone to put multiple projects in the same repository. AFAIK, this is simply not supported by git, i.e. there's no way to clone, branch or tag _part_ of a repository. I am by no means a git expert, so I could be mistaken about this. Justin On 4/26/10 9:21 AM, Kathryn Huxtable wrote: Having recently switched from svn to git for most of my projects, I have an opinion. I think you should create a JIRA ticket and consider this a bug. What we're dealing with here is a bit of svn-centric thinking during design. It needs to be fixed. -K On Apr 26, 2010, at 8:08 AM, Jean-Laurent de Morlhon wrote: We're considering migrating from svn to git, we stumble on the maven-release-plugin usage with git. We think we prefer to use a single repository for many independently built projects like : foobar-repo.git |- project-foo/ ||- pom.xml ||– module A/ ||- module B/ | |- project-bar/ |- pom.xml project-bar scm url looks like : connectionscm:git:ssh://somehost.nowhere:/foobar-repo.git /connection This hints to the right repository but I can't write that the actual project-bar is in the project-bar subdirectory. mvn release:prepare goes well and ends succesfully. mvn release:perform fails whenever it tries to build the project from the tag. It effectively clone correctly the repository. But use the root of the repository rather than going into project-bar subdirectory whenever it tries to clean deploy the tag. This prevent using git and multiple projects in the same directory. Some may think we should use gitmodules but 1) the release plugin does not support it [1] 2) gitmodules is an aggregate of single repository Should I issue
Re: [ANN] Apache Maven 3.0-beta-1 Released
I know Jason says he won't give ETAs, but is there any ETA on the site reporting? I make a lot of use of it, and I doubt I'm alone. My personal preference is to find some way to integrate the docbkx plugin with the site framework. I've got some code that does this for Maven 2, and it works for Maven 3, but the reports aren't generated. -K On Apr 23, 2010, at 8:05 AM, Benjamin Bentmann wrote: The Maven team is pleased to announce the release of Apache Maven 3.0-beta-1. Maven is a project comprehension and build tool, designed to simplify the process of maintaining a healthy development lifecycle for your project. You can read more here: http://maven.apache.org/ Downloads of source and binary distributions are listed in our download section: http://maven.apache.org/download.html A major goal of Maven 3.0 is to be compatible, to the extent possible, with existing plugins and projects designed for Maven 2.x. Users interested in testing this beta release should have a glance at the compatibility notes for known differences between Maven 3.0 and Maven 2.x: http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html If you encounter unexpected problems while using Maven 3.0-beta-1, please feel free to contact us via the Maven developer list: http://maven.apache.org/mail-lists.html Release Notes - Maven 2 3 - Version 3.0-beta-1 ** Bug * [MNG-1751] - merging metadata doesn't fail when timestamp is in the future * [MNG-2103] - Inheritance of plugin overrides that of execution * [MNG-] - dependency to dependency without source code fails * [MNG-2276] - profile activation by property doesn't work with properties defined in settings. * [MNG-2994] - Snapshot repositories are not checked when using ranges * [MNG-3092] - Version ranges with non-snapshot bounds can contain snapshot versions * [MNG-3133] - DefaultModelInheritence::appendPath assumes it is operating on interpolated/literal paths * [MNG-3470] - Build does not fail on corrupted POM even with checksumPolicy=fail * [MNG-3477] - Authentication failures on dependency download aren't reported * [MNG-3529] - mvn -Da= throws an excepltion * [MNG-3616] - Null Pointer Exception when mirrorOf missing from mirror in settings.xml * [MNG-3700] - ModelUtils.clone doesn't clone plugin entries where inherited == false * [MNG-4022] - Incorrect merge behavior using profile driven plugin configuration * [MNG-4326] - Maven should not check snapshot repositories for dependencies in the reactor * [MNG-4418] - Dependency resolution appears to misbehave if a remote repository uses the id local * [MNG-4453] - [regression] Plugin versions defined in a lifecycle mapping are not respected * [MNG-4555] - mvn archetype:generate -o (offline) still results in a checking updates from central * [MNG-4580] - Plugin dependencies for module ignored when building from aggregator project using direct plugin invocation * [MNG-4586] - Plugin prefix can't be resolved from plugin management if management entry is missing plugin version * [MNG-4590] - [regression] System properties are no longer interpolated in imported POMs * [MNG-4600] - [regression] Optional flag from dependency management applied to dependencies * [MNG-4618] - maven-javadoc-plugin aggregate-jar fails with maven3 and multiple modules * [MNG-4625] - Interpolation of settings.xml fails if an expression's value contains XML markup * [MNG-4629] - [regression] POM validation fails upon non-existing system-scope dependency * [MNG-4632] - Class loading is not thread-safe ** Improvement * [MNG-1701] - Validate that a plugin is not configured twice in the pom * [MNG-2187] - Improve error message when the pom is encoded in the wrong charset * [MNG-2741] - [regression] Meaningless error message: Error transferring file * [MNG-3004] - Allow build lifecycle to execute projects in parallel * [MNG-3779] - Improve error message when trying to execute mojo with no pom.xml * [MNG-4162] - Removal of all reporting logic from the core of Maven * [MNG-4194] - API to safely release of plugin realms * [MNG-4591] - Enhance the download rate output to include downloaded file name * [MNG-4610] - Bump maven-release-plugin to v2.0 in super POM * [MNG-4619] - Issue warning in case parent.relativePath points at POM with different groupId/artifactId * [MNG-4623] - model parsing errors can be less helpful in Maven 3 * [MNG-4628] - ReactorArtifactRepository is not setup soon enough for AbstractMavenLifecycleParticipant#afterProjectsRead * [MNG-4634] - Allow custom lifecycles ** Task * [MNG-3917] - Complete the POM construction tests which will be the validation for the specification Enjoy, -The Maven team - To
Re: [ANN] Apache Maven 3.0-beta-1 Released
Great! I'll try it out and let you know. You're probably already doing integration testing, so you probably already know anything I'll report. I'l check the JIRA before I complain... Thanks! -K On Apr 23, 2010, at 3:02 PM, Hervé BOUTEMY wrote: this one isn't done by Jason, but this won't give you an ETA neither ;) maven-site-plugin 3.0-beta-1 shouldn't be far: see [1] you can install it for yourself and see if it works we will probably put the release out in the next weeks Regards, Hervé https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+and+site+plugin Le vendredi 23 avril 2010, Kathryn Huxtable a écrit : I know Jason says he won't give ETAs, but is there any ETA on the site reporting? I make a lot of use of it, and I doubt I'm alone. My personal preference is to find some way to integrate the docbkx plugin with the site framework. I've got some code that does this for Maven 2, and it works for Maven 3, but the reports aren't generated. -K On Apr 23, 2010, at 8:05 AM, Benjamin Bentmann wrote: The Maven team is pleased to announce the release of Apache Maven 3.0-beta-1. Maven is a project comprehension and build tool, designed to simplify the process of maintaining a healthy development lifecycle for your project. You can read more here: http://maven.apache.org/ Downloads of source and binary distributions are listed in our download section: http://maven.apache.org/download.html A major goal of Maven 3.0 is to be compatible, to the extent possible, with existing plugins and projects designed for Maven 2.x. Users interested in testing this beta release should have a glance at the compatibility notes for known differences between Maven 3.0 and Maven 2.x: http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html If you encounter unexpected problems while using Maven 3.0-beta-1, please feel free to contact us via the Maven developer list: http://maven.apache.org/mail-lists.html Release Notes - Maven 2 3 - Version 3.0-beta-1 ** Bug * [MNG-1751] - merging metadata doesn't fail when timestamp is in the future * [MNG-2103] - Inheritance of plugin overrides that of execution * [MNG-] - dependency to dependency without source code fails * [MNG-2276] - profile activation by property doesn't work with properties defined in settings. * [MNG-2994] - Snapshot repositories are not checked when using ranges * [MNG-3092] - Version ranges with non-snapshot bounds can contain snapshot versions * [MNG-3133] - DefaultModelInheritence::appendPath assumes it is operating on interpolated/literal paths * [MNG-3470] - Build does not fail on corrupted POM even with checksumPolicy=fail * [MNG-3477] - Authentication failures on dependency download aren't reported * [MNG-3529] - mvn -Da= throws an excepltion * [MNG-3616] - Null Pointer Exception when mirrorOf missing from mirror in settings.xml * [MNG-3700] - ModelUtils.clone doesn't clone plugin entries where inherited == false * [MNG-4022] - Incorrect merge behavior using profile driven plugin configuration * [MNG-4326] - Maven should not check snapshot repositories for dependencies in the reactor * [MNG-4418] - Dependency resolution appears to misbehave if a remote repository uses the id local * [MNG-4453] - [regression] Plugin versions defined in a lifecycle mapping are not respected * [MNG-4555] - mvn archetype:generate -o (offline) still results in a checking updates from central * [MNG-4580] - Plugin dependencies for module ignored when building from aggregator project using direct plugin invocation * [MNG-4586] - Plugin prefix can't be resolved from plugin management if management entry is missing plugin version * [MNG-4590] - [regression] System properties are no longer interpolated in imported POMs * [MNG-4600] - [regression] Optional flag from dependency management applied to dependencies * [MNG-4618] - maven-javadoc-plugin aggregate-jar fails with maven3 and multiple modules * [MNG-4625] - Interpolation of settings.xml fails if an expression's value contains XML markup * [MNG-4629] - [regression] POM validation fails upon non-existing system-scope dependency * [MNG-4632] - Class loading is not thread-safe ** Improvement * [MNG-1701] - Validate that a plugin is not configured twice in the pom * [MNG-2187] - Improve error message when the pom is encoded in the wrong charset * [MNG-2741] - [regression] Meaningless error message: Error transferring file * [MNG-3004] - Allow build lifecycle to execute projects in parallel * [MNG-3779] - Improve error message when trying to execute mojo with no pom.xml * [MNG-4162] - Removal of all reporting logic from the core of Maven * [MNG-4194] - API to safely release of plugin realms * [MNG-4591] - Enhance the download rate output to include downloaded file name * [MNG-4610] - Bump maven-release-plugin to v2.0 in super POM * [MNG-4619] - Issue warning in case parent.relativePath points
Re: [ANN] Apache Maven 3.0-beta-1 Released
Any reason why mvn clean package on the checked out source would yield: [INFO] --- maven-compiler-plugin:2.1:compile (default-compile) @ maven-site-plugin --- [INFO] Compiling 23 source files to /Users/huxtable/Documents/workspace/maven-site-plugin-3.0-beta-1-SNAPSHOT/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /Users/huxtable/Documents/workspace/maven-site-plugin-3.0-beta-1-SNAPSHOT/src/main/java/org/apache/maven/plugins/site/DefaultMavenReportExecutor.java:[209,41] cannot find symbol symbol : method calculateForkedExecutions(org.apache.maven.plugin.MojoExecution,org.apache.maven.execution.MavenSession) location: interface org.apache.maven.lifecycle.LifecycleExecutor [ERROR] /Users/huxtable/Documents/workspace/maven-site-plugin-3.0-beta-1-SNAPSHOT/src/main/java/org/apache/maven/plugins/site/DefaultMavenReportExecutor.java:[213,45] cannot find symbol symbol : method executeForkedExecutions(org.apache.maven.plugin.MojoExecution,org.apache.maven.execution.MavenSession) location: interface org.apache.maven.lifecycle.LifecycleExecutor [INFO] 2 errors [INFO] - [INFO] [INFO] BUILD FAILURE -K On Apr 23, 2010, at 3:42 PM, Kathryn Huxtable wrote: Great! I'll try it out and let you know. You're probably already doing integration testing, so you probably already know anything I'll report. I'l check the JIRA before I complain... Thanks! -K On Apr 23, 2010, at 3:02 PM, Hervé BOUTEMY wrote: this one isn't done by Jason, but this won't give you an ETA neither ;) maven-site-plugin 3.0-beta-1 shouldn't be far: see [1] you can install it for yourself and see if it works we will probably put the release out in the next weeks Regards, Hervé https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+and+site+plugin Le vendredi 23 avril 2010, Kathryn Huxtable a écrit : I know Jason says he won't give ETAs, but is there any ETA on the site reporting? I make a lot of use of it, and I doubt I'm alone. My personal preference is to find some way to integrate the docbkx plugin with the site framework. I've got some code that does this for Maven 2, and it works for Maven 3, but the reports aren't generated. -K On Apr 23, 2010, at 8:05 AM, Benjamin Bentmann wrote: The Maven team is pleased to announce the release of Apache Maven 3.0-beta-1. Maven is a project comprehension and build tool, designed to simplify the process of maintaining a healthy development lifecycle for your project. You can read more here: http://maven.apache.org/ Downloads of source and binary distributions are listed in our download section: http://maven.apache.org/download.html A major goal of Maven 3.0 is to be compatible, to the extent possible, with existing plugins and projects designed for Maven 2.x. Users interested in testing this beta release should have a glance at the compatibility notes for known differences between Maven 3.0 and Maven 2.x: http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html If you encounter unexpected problems while using Maven 3.0-beta-1, please feel free to contact us via the Maven developer list: http://maven.apache.org/mail-lists.html Release Notes - Maven 2 3 - Version 3.0-beta-1 ** Bug * [MNG-1751] - merging metadata doesn't fail when timestamp is in the future * [MNG-2103] - Inheritance of plugin overrides that of execution * [MNG-] - dependency to dependency without source code fails * [MNG-2276] - profile activation by property doesn't work with properties defined in settings. * [MNG-2994] - Snapshot repositories are not checked when using ranges * [MNG-3092] - Version ranges with non-snapshot bounds can contain snapshot versions * [MNG-3133] - DefaultModelInheritence::appendPath assumes it is operating on interpolated/literal paths * [MNG-3470] - Build does not fail on corrupted POM even with checksumPolicy=fail * [MNG-3477] - Authentication failures on dependency download aren't reported * [MNG-3529] - mvn -Da= throws an excepltion * [MNG-3616] - Null Pointer Exception when mirrorOf missing from mirror in settings.xml * [MNG-3700] - ModelUtils.clone doesn't clone plugin entries where inherited == false * [MNG-4022] - Incorrect merge behavior using profile driven plugin configuration * [MNG-4326] - Maven should not check snapshot repositories for dependencies in the reactor * [MNG-4418] - Dependency resolution appears to misbehave if a remote repository uses the id local * [MNG-4453] - [regression] Plugin versions defined in a lifecycle mapping are not respected * [MNG-4555] - mvn archetype:generate -o (offline) still results in a checking updates from central * [MNG-4580] - Plugin dependencies
OT: Android developer book recommendations?
I know some of you out there are developing for Android. Do you have any good book recommendations? And how mature is the Maven stuff for Android? -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to get some menus expanded by default
I do this by manually specifying the menus for all my reports and not using the reports variable in site.xml. There may be other ways. If there are, I'd like to know. -K On Apr 12, 2010, at 9:38 AM, Benson Margulies wrote: When I go here, the project information menu is expanded by default. http://maven.apache.org/plugins/maven-site-plugin/ None of my projects have this, in spite of the fact that site.xml describes the default for collapse as 'false'. Is there something happening in the skin that arranges this. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to get some menus expanded by default
Well, I don't like collapsed menus, so I specify all the menus in site.xml. But that's just me. -K On Apr 12, 2010, at 12:17 PM, Benson Margulies wrote: That doesn't seem to be the situation at the maven-site-plugin itself. And updating to 2.1 seems to have changed this for some of my projects. On Mon, Apr 12, 2010 at 11:49 AM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: I do this by manually specifying the menus for all my reports and not using the reports variable in site.xml. There may be other ways. If there are, I'd like to know. -K On Apr 12, 2010, at 9:38 AM, Benson Margulies wrote: When I go here, the project information menu is expanded by default. http://maven.apache.org/plugins/maven-site-plugin/ None of my projects have this, in spite of the fact that site.xml describes the default for collapse as 'false'. Is there something happening in the skin that arranges this. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin 2.1 and PMD/CPD don't play nicely
On Apr 9, 2010, at 2:54 AM, Andreas Sewe wrote: Kathryn Huxtable wrote: My CPD HTML report is empty when I use maven-site-plugin 2.1. The XML report is fine. The PMD report is fine. If I use maven-site-plugin 2.0.1 I get my CPD report. I don't know if this is a problem with PMD, Site, or Doxia, but I've filed MPMD-119 to report it. Has anyone else experienced this? Yes, using m-site-plugin 2.1 I see the same problem here. :-( My cpd.xml contains a bunch of duplications, but the resulting cpd.html only has a h2Duplications/h2 followed by an empty paragraph. Thanks for reporting the issue. (Already voted for it :-) And it seems to be fixed in the next release. I wonder when that will be released, she wondered idly... -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin overwrites index.apt
Try version 2.1. I generally specify the reports I want in the project-info-reports plugin and don't specify the about report. -K On Apr 8, 2010, at 10:28 AM, Timothy Mcginnis wrote: I have a site for my project that defines a index.apt file. When I run the mvn site:site (or any other site goal) my index.apt file is ignored and a index.html file is created with just the description from my pom. This was working before where I would get the index.html file that I provided. But something has changed and I am not sure what is causing this different behavior. I am using version 2.0.1 of the site plugin. Thanks, Tim McGinnis 717 720-1962 Web Development AES/PHEAA == This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. == - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Site plugin 2.1 and PMD/CPD don't play nicely
My CPD HTML report is empty when I use maven-site-plugin 2.1. The XML report is fine. The PMD report is fine. If I use maven-site-plugin 2.0.1 I get my CPD report. I don't know if this is a problem with PMD, Site, or Doxia, but I've filed MPMD-119 to report it. Has anyone else experienced this? -K
Re: Maven and Hudson
If you're using TeamCity, do you also use IDEA for your IDE? -K, who rather prefers Nexus to Artifactory, having used both. Artifactory is pretty good, though. On Apr 7, 2010, at 1:20 PM, David Hoffer wrote: The tool stack we use is SVN, Maven, TeamCity Artifactory. -Dave On Wed, Apr 7, 2010 at 12:17 PM, Lorenzo Thurman lore...@thethurmans.com wrote: I'm beginning to see this now. I was asked to look at a number of products that we may use on a large ATG/jsp project we'll be working on. Hudson, CruiseControl, Maven and Ant. I don't any of us knows much about them, but I have to sort out the differences in each. I think I'm leaning towards a pairing of Hudson/Maven pairing, but it's still early. Thx for the reply. On Apr 7, 2010, at 12:06 PM, Adam Purkiss wrote: They are two different products that work well together rather then competing products. Why are you testing them? Hudson put simply is a CI server that you provide Maven/Ant/Shell scripts etc to and it does builds and you can generate reports about, Maven is a project comprehension tool that can be used as a way to build software, manage dependancies and also run other tools on code. My descriptions are basic at best but I think you are trying to compare two things that I would be using together and not instead of so maybe a better understanding of what your objective is would help answer the question. From: lore...@thethurmans.com Subject: Maven and Hudson Date: Wed, 7 Apr 2010 11:59:05 -0500 To: users@maven.apache.org I hope this question is suitable for the list, if not apologies. Can someone give me a comparison between Maven and Hudson? I'm in the process of testing both of these, but would like some opinions on the strengths/weaknesses of the product. Thanks My Break-Dancing days are over, but there's always the Funky Chicken --The Full Monty Lorenzo Thurman lore...@thethurmans.com _ Got a phone? Get Hotmail Messenger for mobile! http://go.microsoft.com/?linkid=9724464 Beware of all enterprises that require new clothes. -- Henry David Thoreau Lorenzo Thurman lore...@thethurmans.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and Hudson
Yes, it does have good maven integration. I'm so used to Eclipse, though. I was just wondering, since TeamCity is a JetBrains product like IDEA. -K On Apr 7, 2010, at 1:27 PM, David Hoffer wrote: Personally yes I use IDEA but others use Eclipse, etc. (IDEA has very good maven integration.) -Dave On Wed, Apr 7, 2010 at 12:23 PM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: If you're using TeamCity, do you also use IDEA for your IDE? -K, who rather prefers Nexus to Artifactory, having used both. Artifactory is pretty good, though. On Apr 7, 2010, at 1:20 PM, David Hoffer wrote: The tool stack we use is SVN, Maven, TeamCity Artifactory. -Dave On Wed, Apr 7, 2010 at 12:17 PM, Lorenzo Thurman lore...@thethurmans.com wrote: I'm beginning to see this now. I was asked to look at a number of products that we may use on a large ATG/jsp project we'll be working on. Hudson, CruiseControl, Maven and Ant. I don't any of us knows much about them, but I have to sort out the differences in each. I think I'm leaning towards a pairing of Hudson/Maven pairing, but it's still early. Thx for the reply. On Apr 7, 2010, at 12:06 PM, Adam Purkiss wrote: They are two different products that work well together rather then competing products. Why are you testing them? Hudson put simply is a CI server that you provide Maven/Ant/Shell scripts etc to and it does builds and you can generate reports about, Maven is a project comprehension tool that can be used as a way to build software, manage dependancies and also run other tools on code. My descriptions are basic at best but I think you are trying to compare two things that I would be using together and not instead of so maybe a better understanding of what your objective is would help answer the question. From: lore...@thethurmans.com Subject: Maven and Hudson Date: Wed, 7 Apr 2010 11:59:05 -0500 To: users@maven.apache.org I hope this question is suitable for the list, if not apologies. Can someone give me a comparison between Maven and Hudson? I'm in the process of testing both of these, but would like some opinions on the strengths/weaknesses of the product. Thanks My Break-Dancing days are over, but there's always the Funky Chicken --The Full Monty Lorenzo Thurman lore...@thethurmans.com _ Got a phone? Get Hotmail Messenger for mobile! http://go.microsoft.com/?linkid=9724464 Beware of all enterprises that require new clothes. -- Henry David Thoreau Lorenzo Thurman lore...@thethurmans.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn install - skipping modules that only contain test code
But why would anyone care what gets pulled into the local repository? I'm with Wayne on this one. That's how Maven works. An artifact is like a point in spacetime. It has coordinates and is immutable. You might need it later and it'll be there. And if not, so what? -K On Apr 6, 2010, at 2:28 PM, Ludwig Magnusson wrote: I recently submittet a patch in JIRA that added a skip flag. This skipped installation in the local repository for artifacts. /Ludwig -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: den 6 april 2010 20:59 To: Maven Users List Subject: Re: mvn install - skipping modules that only contain test code At present the install goal copies all the test jars to the local repository. Is there any way of skipping the install phase for these modules? Does it really hurt to copy them to the local repo? This is how Maven works. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn install - skipping modules that only contain test code
Ah. I misunderstood. I thought you meant it wouldn't pull in dependencies. No, the repository only makes sense for things that can be dependencies, or are used in building or deploying artifacts. My two current projects are a cross-platform look and feel for Swing, and a recipe program. The look and feel makes sense to have in a repository, but I have no intention of ever deploying the recipe program. (In fact, I'm hoping to sell it.) But it would never go into a repository if you don't install it or deploy it. Why would you do that? Why do you need an option to not put it into a repository? -K On Apr 6, 2010, at 2:52 PM, Ludwig Magnusson wrote: Why? I will never have a project that depends on the webapp I'm creating. That's one reason. I really don't understand the policy here. You might not see the the value and the value might not be big, but is that a reason for not adding a simple, already implemented feature? Maven can be used by many different projects and situations might occur where installation is not necessary. What is the reason for not putting the feature in? Will it lower the value of the plugin? /Ludwig -Original Message- From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org] Sent: den 6 april 2010 21:32 To: Maven Users List Subject: Re: mvn install - skipping modules that only contain test code But why would anyone care what gets pulled into the local repository? I'm with Wayne on this one. That's how Maven works. An artifact is like a point in spacetime. It has coordinates and is immutable. You might need it later and it'll be there. And if not, so what? -K On Apr 6, 2010, at 2:28 PM, Ludwig Magnusson wrote: I recently submittet a patch in JIRA that added a skip flag. This skipped installation in the local repository for artifacts. /Ludwig -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: den 6 april 2010 20:59 To: Maven Users List Subject: Re: mvn install - skipping modules that only contain test code At present the install goal copies all the test jars to the local repository. Is there any way of skipping the install phase for these modules? Does it really hurt to copy them to the local repo? This is how Maven works. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Not getting cpd.html in site generation
I have the following in my reporting element: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId version2.4/version configuration targetJdk1.6/targetJdk linkXreftrue/linkXref sourceEncodingutf-8/sourceEncoding minimumTokens100/minimumTokens /configuration /plugin I get the pmd report and the cpd.xml file is generated, but the cpd.html file lists no duplicate code, which is not correct. Any ideas? I have no other references in my POM to this plugin. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Not getting cpd.html in site generation
BTW, I get the following output from mvn site: [INFO] Generating Project License report. [INFO] Generating Project Team report. [INFO] Generating Project Summary report. [INFO] Generating Issue Tracking report. [INFO] Generating Source Repository report. [INFO] Generating Mailing Lists report. [INFO] Generating Dependencies report. [INFO] Generating Source Xref report. [INFO] Generating Test Source Xref report. [INFO] Generating Tag List report. [INFO] Generating PMD Report report. [INFO] Generating CPD Report report. [INFO] Generating JavaDocs report. So something is happening, and as I said, a cpd.xml file is generated with duplicates. If I run mvn pmd:cpd I get the correct HTML listing, but with the incorrect site.vm formatting. I have a custom template file for my site docs. Could that be the problem? -K On Apr 6, 2010, at 4:05 PM, Kathryn Huxtable wrote: I have the following in my reporting element: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId version2.4/version configuration targetJdk1.6/targetJdk linkXreftrue/linkXref sourceEncodingutf-8/sourceEncoding minimumTokens100/minimumTokens /configuration /plugin I get the pmd report and the cpd.xml file is generated, but the cpd.html file lists no duplicate code, which is not correct. Any ideas? I have no other references in my POM to this plugin. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Not getting cpd.html in site generation
On Apr 6, 2010, at 4:11 PM, Kathryn Huxtable wrote: On Apr 6, 2010, at 4:05 PM, Kathryn Huxtable wrote: I have the following in my reporting element: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-pmd-plugin/artifactId version2.4/version configuration targetJdk1.6/targetJdk linkXreftrue/linkXref sourceEncodingutf-8/sourceEncoding minimumTokens100/minimumTokens /configuration /plugin I get the pmd report and the cpd.xml file is generated, but the cpd.html file lists no duplicate code, which is not correct. Any ideas? I have no other references in my POM to this plugin. BTW, I get the following output from mvn site: [INFO] Generating Project License report. [INFO] Generating Project Team report. [INFO] Generating Project Summary report. [INFO] Generating Issue Tracking report. [INFO] Generating Source Repository report. [INFO] Generating Mailing Lists report. [INFO] Generating Dependencies report. [INFO] Generating Source Xref report. [INFO] Generating Test Source Xref report. [INFO] Generating Tag List report. [INFO] Generating PMD Report report. [INFO] Generating CPD Report report. [INFO] Generating JavaDocs report. So something is happening, and as I said, a cpd.xml file is generated with duplicates. If I run mvn pmd:cpd I get the correct HTML listing, but with the incorrect site.vm formatting. I have a custom template file for my site docs. Could that be the problem? -K It's not the problem. This used to work. Maybe I've changed a version or something. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Making a gitsite wagon for GitHub pages
Okay, I've released my wagon-gitsite into the wild. It's on Central. The coordinates are: org.kathrynhuxtable.maven.wagon:wagon-gitsite:0.2 The docs are at http://khuxtable.github.com/wagon-gitsite Enjoy! A lot of this could be done with the wagon-scm plugin with one minor change to maven-scm-provider-gitexe and a few changes to wagon-scm. I'll post issues when I get my password to jira reset. -K On Apr 3, 2010, at 8:26 PM, Kathryn Huxtable wrote: Justin, My initial versions were basically fixes with some minor changes to wagon-scm. Once I get some codehaus login issues worked out, I'll post Jira issues for gitexe and for wagon-scm, and send in patches for wagon-scm. At the moment I am having great success with implementing my mechanism using the scripty commands I posted. I'm not actually using scripts, I'm using gitexe. I want to tag the site release with the version number, more or less the way the release plugin does. I'd say I'm halfway done, and then I'll push my changes. Then I'll clean the code and post. -K On Apr 2, 2010, at 7:13 PM, Justin Edelson wrote: Kathryn- I'm very curious to see your code. Please do let me know when it's posted somewhere (presumably github). Justin On Apr 2, 2010, at 7:08 PM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: On Apr 2, 2010, at 2:22 PM, Kathryn Huxtable wrote: On Apr 2, 2010, at 2:03 PM, Justin Edelson wrote: IMHO, you should be writing your own wagon implementation and avoid using wagon-scm. This use case is very specific to github. This way, you're free to define your own URL syntax. Well, that's what I was thinking about doing. It looks to me as if the wagon-scm is in pretty early stages and really only works with svn. I'm still boggled that wagons don't seem to be configurable. Okay, I see that wagons are configurable in the settings.xml file. Bleah. I've taken a chainsaw and hacked away at wagon-scm and have something that works to deploy to GitHub. I'll clean it up a bit and deploy it. Others who use GitHub may find it useful. Of course, I gather that things are changing quite a bit with Maven 3.0, but I haven't looked at it yet. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can a site wagon deploy its own site docs?
Well, the site plugin uses the previous version of itself for its own site plugin. I've seen another site-related plugin use its own version. It noted in the comments that it needed to be installed before the site could be built. I'll investigate further. -K On Apr 3, 2010, at 3:38 AM, Stephen Connolly wrote: In general, a project cannot consume any maven plugins that it produces (as the plugins which have not been built yet could have an unknown effect on the build plan) I wonder if the same applies to extensions and wagons -Stephen On 3 April 2010 04:54, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: So I've deployed this crude hack of wagon-scm to http://github.com/khuxtable/wagon-gitsite and I thought it would be cool if it deployed its own documentation there. So I added the extensions to the POM and generated the site and did a site:deploy and got: [ERROR] BUILD ERROR [INFO] [INFO] Unsupported protocol: 'gitsite' Embedded error: Cannot find wagon which supports the requested protocol: gitsite Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagongitsite. The wagon-gitsite artifact build and installed successfully. It works in my test project. What gives? And what's the org.apache.maven.wagon.Wagongitsite reference doing there? The artifact coordinates are org.kathrynhuxtable.maven:wagon.wagon-gitsite:0.1-SNAPSHOT Any ideas? -K, who deployed the site manually. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can a site wagon deploy its own site docs?
Also, my own htmlfilter-site-maven-plugin uses itself. It puts the plugin management in a site profile. But a wagon isn't a plugin and has no mojos. -K On Apr 3, 2010, at 6:22 AM, Kathryn Huxtable wrote: Well, the site plugin uses the previous version of itself for its own site plugin. I've seen another site-related plugin use its own version. It noted in the comments that it needed to be installed before the site could be built. I'll investigate further. -K On Apr 3, 2010, at 3:38 AM, Stephen Connolly wrote: In general, a project cannot consume any maven plugins that it produces (as the plugins which have not been built yet could have an unknown effect on the build plan) I wonder if the same applies to extensions and wagons -Stephen On 3 April 2010 04:54, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: So I've deployed this crude hack of wagon-scm to http://github.com/khuxtable/wagon-gitsite and I thought it would be cool if it deployed its own documentation there. So I added the extensions to the POM and generated the site and did a site:deploy and got: [ERROR] BUILD ERROR [INFO] [INFO] Unsupported protocol: 'gitsite' Embedded error: Cannot find wagon which supports the requested protocol: gitsite Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagongitsite. The wagon-gitsite artifact build and installed successfully. It works in my test project. What gives? And what's the org.apache.maven.wagon.Wagongitsite reference doing there? The artifact coordinates are org.kathrynhuxtable.maven:wagon.wagon-gitsite:0.1-SNAPSHOT Any ideas? -K, who deployed the site manually. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Making a gitsite wagon for GitHub pages
Justin, My initial versions were basically fixes with some minor changes to wagon-scm. Once I get some codehaus login issues worked out, I'll post Jira issues for gitexe and for wagon-scm, and send in patches for wagon-scm. At the moment I am having great success with implementing my mechanism using the scripty commands I posted. I'm not actually using scripts, I'm using gitexe. I want to tag the site release with the version number, more or less the way the release plugin does. I'd say I'm halfway done, and then I'll push my changes. Then I'll clean the code and post. -K On Apr 2, 2010, at 7:13 PM, Justin Edelson wrote: Kathryn- I'm very curious to see your code. Please do let me know when it's posted somewhere (presumably github). Justin On Apr 2, 2010, at 7:08 PM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: On Apr 2, 2010, at 2:22 PM, Kathryn Huxtable wrote: On Apr 2, 2010, at 2:03 PM, Justin Edelson wrote: IMHO, you should be writing your own wagon implementation and avoid using wagon-scm. This use case is very specific to github. This way, you're free to define your own URL syntax. Well, that's what I was thinking about doing. It looks to me as if the wagon-scm is in pretty early stages and really only works with svn. I'm still boggled that wagons don't seem to be configurable. Okay, I see that wagons are configurable in the settings.xml file. Bleah. I've taken a chainsaw and hacked away at wagon-scm and have something that works to deploy to GitHub. I'll clean it up a bit and deploy it. Others who use GitHub may find it useful. Of course, I gather that things are changing quite a bit with Maven 3.0, but I haven't looked at it yet. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with wagon-scm and gitexe
So looking at the git SCM code (git-commons and gitexe) and at the wagon-scm
code, the problem I see is that there is no syntax in the git SCM url to
specify a branch to which to deploy the site. Not a surprise, since git
generally wants to clone an entire repository and then push and pull things.
The desired process would be something along the lines of the following. (In
UN*X-y/scripty/Velocity-y format.)
mkdir ${checkoutDirectory}
cd ${checkoutDirectory}
git init
git remote add origin ${gitRepoUrl}
git pull origin refs/heads/${siteBranch}
replace the contents of the checkout directory, except for the .git
subdirectory, with the site docs
git add .
git commit -a -m Deploy site documentation.
git push origin master:${siteBranch}
rm -Rf ${checkoutDirectory}
This works.
Obviously, we wouldn't want to mess up the git SCM for other uses. Does the
release plugin use the wagon? I *really* don't want to end up looking at all
the Maven source code.
Any ideas on where changes need to be made? In wagon-scm? In gitexe or
git-commons?
I see no way to configure wagons, which I find a bit of a lack. I suppose the
URL structure and username/password info in settings.xml is supposed to take
care of everything. Should there be a branch element in the git scm url
structure a la the module element in CVS scm urls?
-K
On Apr 1, 2010, at 4:24 PM, Kathryn Huxtable wrote:
Yeah, that's more or less what I mean. -K
On Apr 1, 2010, at 4:09 PM, Mark Struberg wrote:
I honestly doubt that wagon-scm + CVS currently works when using branches
(from glimpsing at the sources).
And I'm not sure what you mean with forking it. Wouldn't it be much easier
to simply checkout wagon-scm and if you found a way to provide the branch as
ScmVersion (ScmBranch and ScmTag are subclassses of ScmVersion [3]), then
simply open a Jira issue and add your changes as patch. Patches are always
highly welcome :)
txs and LieGrue,
strub
[3] http://maven.apache.org/scm/apidocs/org/apache/maven/scm/ScmBranch.html
--- Kathryn Huxtable kath...@kathrynhuxtable.org schrieb am Do, 1.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and gitexe
An: Maven Users List users@maven.apache.org
Datum: Donnerstag, 1. April, 2010 22:43 Uhr
Thanks, Mark,
These are good points.
I'm thinking that the issues are in wagon-scm, which is
listed as being in progress, so I can't really expect
perfection. And they *do* say it's only been tested with svn
and cvs. I'm thinking that I may be modding wagon-svn, more
to see what's going on than to fork a project.
All of this is by the way. I really should be working on my
project, not fiddling with tools, but fiddling with tools is
fun sometimes.
-K
On Apr 1, 2010, at 3:37 PM, Mark Struberg wrote:
Kathryn,
I haven't used wagon-scm, so I can only make vague
assumptions.
Basically all the branches and tag stuff should be
working in maven-scm-provider-gitexe. But I'm not sure how
wagon-scm tells us what branch it likes to use.
From looking at the source [1] I only can see that all
ScmVersion parameters are always given as null. So I'm not
sure if that could work at all.
Please keep in mind that SVN is really exceptional
with handling branches by copying the trunk to a new
location. This way you get an own URL which you won't get in
most other SCMs like CVS, PVCS, git or hg. In fact SVN
doesn't have a 'real' branch and tag concept but internally
always performs a full shallow copy.
So it would be interesting if this would also work
e.g. with CVS.
LieGrue,
strub
[1]
http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-providers/wagon-scm/src/main/java/org/apache/maven/wagon/providers/scm/ScmWagon.java?view=markup
--- Kathryn Huxtable kath...@kathrynhuxtable.org
schrieb am Do, 1.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and gitexe
An: Maven Users List users@maven.apache.org
Datum: Donnerstag, 1. April, 2010 19:21 Uhr
Since it seems to be my practice to
have second thought after sending a message, I'll
add that I
can check out the gh-pages branch of my git
repository into
a separate directory and deploy there using a
file: URL
and then commit that and push it.
That works. I just think it should be able to be
automated.
-K
On Apr 1, 2010, at 12:14 PM, Kathryn Huxtable
wrote:
I know the docs say that wagon-scm has only
been
tested with CVS and Subversion, and I've run it
with
Subversion successfully.
Is anyone working on getting it to work with
Git, or
does it already?
I created a very simply project with a README
and a
pom.xml and nothing else. It's at
http://github.com/khuxtable/test-project
It uses versions 1.3 of the gitexe and
scm-manager-plexus extensions and version
1.0-beta-6 of the
scm wagon.
What I would like to do is deploy my site docs
(all
generated
Re: Problem with wagon-scm and gitexe
Here's an alternative script:
mkdir ${checkoutDirectory}
cd ${checkoutDirectory}
git init
git remote add -t ${siteBranch} origin ${gitRepoUrl}
git fetch
git checkout ${siteBranch}
replace the contents of the checkout directory, except for the .git
subdirectory, with the site docs
git add .
git commit -a -m Deploy site documentation
git push
rm -Rf ${checkoutDirectory}
-K
On Apr 2, 2010, at 11:28 AM, Kathryn Huxtable wrote:
So looking at the git SCM code (git-commons and gitexe) and at the wagon-scm
code, the problem I see is that there is no syntax in the git SCM url to
specify a branch to which to deploy the site. Not a surprise, since git
generally wants to clone an entire repository and then push and pull things.
The desired process would be something along the lines of the following. (In
UN*X-y/scripty/Velocity-y format.)
mkdir ${checkoutDirectory}
cd ${checkoutDirectory}
git init
git remote add origin ${gitRepoUrl}
git pull origin refs/heads/${siteBranch}
replace the contents of the checkout directory, except for the .git
subdirectory, with the site docs
git add .
git commit -a -m Deploy site documentation.
git push origin master:${siteBranch}
rm -Rf ${checkoutDirectory}
This works.
Obviously, we wouldn't want to mess up the git SCM for other uses. Does the
release plugin use the wagon? I *really* don't want to end up looking at all
the Maven source code.
Any ideas on where changes need to be made? In wagon-scm? In gitexe or
git-commons?
I see no way to configure wagons, which I find a bit of a lack. I suppose the
URL structure and username/password info in settings.xml is supposed to take
care of everything. Should there be a branch element in the git scm url
structure a la the module element in CVS scm urls?
-K
On Apr 1, 2010, at 4:24 PM, Kathryn Huxtable wrote:
Yeah, that's more or less what I mean. -K
On Apr 1, 2010, at 4:09 PM, Mark Struberg wrote:
I honestly doubt that wagon-scm + CVS currently works when using branches
(from glimpsing at the sources).
And I'm not sure what you mean with forking it. Wouldn't it be much easier
to simply checkout wagon-scm and if you found a way to provide the branch
as ScmVersion (ScmBranch and ScmTag are subclassses of ScmVersion [3]),
then simply open a Jira issue and add your changes as patch. Patches are
always highly welcome :)
txs and LieGrue,
strub
[3] http://maven.apache.org/scm/apidocs/org/apache/maven/scm/ScmBranch.html
--- Kathryn Huxtable kath...@kathrynhuxtable.org schrieb am Do, 1.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and gitexe
An: Maven Users List users@maven.apache.org
Datum: Donnerstag, 1. April, 2010 22:43 Uhr
Thanks, Mark,
These are good points.
I'm thinking that the issues are in wagon-scm, which is
listed as being in progress, so I can't really expect
perfection. And they *do* say it's only been tested with svn
and cvs. I'm thinking that I may be modding wagon-svn, more
to see what's going on than to fork a project.
All of this is by the way. I really should be working on my
project, not fiddling with tools, but fiddling with tools is
fun sometimes.
-K
On Apr 1, 2010, at 3:37 PM, Mark Struberg wrote:
Kathryn,
I haven't used wagon-scm, so I can only make vague
assumptions.
Basically all the branches and tag stuff should be
working in maven-scm-provider-gitexe. But I'm not sure how
wagon-scm tells us what branch it likes to use.
From looking at the source [1] I only can see that all
ScmVersion parameters are always given as null. So I'm not
sure if that could work at all.
Please keep in mind that SVN is really exceptional
with handling branches by copying the trunk to a new
location. This way you get an own URL which you won't get in
most other SCMs like CVS, PVCS, git or hg. In fact SVN
doesn't have a 'real' branch and tag concept but internally
always performs a full shallow copy.
So it would be interesting if this would also work
e.g. with CVS.
LieGrue,
strub
[1]
http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-providers/wagon-scm/src/main/java/org/apache/maven/wagon/providers/scm/ScmWagon.java?view=markup
--- Kathryn Huxtable kath...@kathrynhuxtable.org
schrieb am Do, 1.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and gitexe
An: Maven Users List users@maven.apache.org
Datum: Donnerstag, 1. April, 2010 19:21 Uhr
Since it seems to be my practice to
have second thought after sending a message, I'll
add that I
can check out the gh-pages branch of my git
repository into
a separate directory and deploy there using a
file: URL
and then commit that and push it.
That works. I just think it should be able to be
automated.
-K
On Apr 1, 2010, at 12:14 PM, Kathryn Huxtable
wrote:
I know the docs say that wagon-scm has only
been
tested with CVS
Re: Problem with wagon-scm and gitexe
I don't really think there's a conceptual misunderstanding on my part, since
the format for the CVS URL in the SCM code allows for a module_name as part
of the URL, and not in standard URL syntax.
But I take your point.
My basic question of the moment is, who calls putDirectory? Is it called from
the release plugin? It seems to be getting called from the site plugin.
The wagon documentation leaves something to be desired for the unfamiliar
developer. Yes, there are javadocs, but they don't tell you *how* the public
methods and classes are used. I'm trying to figure that out without complaining
too much, or looking at all the code that uses wagons.
-K
On Apr 2, 2010, at 12:43 PM, Mark Struberg wrote:
Kathryn, I think there is a conceptional misunderstanding here.
Subversion is actually almost the ONLY SCM which has different URLs on
different branches.
Usually the version gets set via the -DscmVersion parameter which transfers
into the ScmVersion parameter in various functions of the maven-scm-api!
Your attempt with first determining/setting the branch with native git
commands would actually work with git, but I'd prefer to give wagon-scm the
branch as parameter and use that inside the code.
txs and LieGrue,
strub
--- Kathryn Huxtable kath...@kathrynhuxtable.org schrieb am Fr, 2.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and gitexe
An: Maven Users List users@maven.apache.org
Datum: Freitag, 2. April, 2010 18:56 Uhr
Here's an alternative script:
mkdir ${checkoutDirectory}
cd ${checkoutDirectory}
git init
git remote add -t ${siteBranch} origin ${gitRepoUrl}
git fetch
git checkout ${siteBranch}
replace the contents of the checkout directory, except
for the .git subdirectory, with the site docs
git add .
git commit -a -m Deploy site documentation
git push
rm -Rf ${checkoutDirectory}
-K
On Apr 2, 2010, at 11:28 AM, Kathryn Huxtable wrote:
So looking at the git SCM code (git-commons and
gitexe) and at the wagon-scm code, the problem I see is that
there is no syntax in the git SCM url to specify a branch to
which to deploy the site. Not a surprise, since git
generally wants to clone an entire repository and then push
and pull things.
The desired process would be something along the lines
of the following. (In UN*X-y/scripty/Velocity-y format.)
mkdir ${checkoutDirectory}
cd ${checkoutDirectory}
git init
git remote add origin ${gitRepoUrl}
git pull origin refs/heads/${siteBranch}
replace the contents of the checkout
directory, except for the .git subdirectory, with the site
docs
git add .
git commit -a -m Deploy site documentation.
git push origin master:${siteBranch}
rm -Rf ${checkoutDirectory}
This works.
Obviously, we wouldn't want to mess up the git SCM for
other uses. Does the release plugin use the wagon? I
*really* don't want to end up looking at all the Maven
source code.
Any ideas on where changes need to be made? In
wagon-scm? In gitexe or git-commons?
I see no way to configure wagons, which I find a bit
of a lack. I suppose the URL structure and username/password
info in settings.xml is supposed to take care of everything.
Should there be a branch element in the git scm url
structure a la the module element in CVS scm urls?
-K
On Apr 1, 2010, at 4:24 PM, Kathryn Huxtable wrote:
Yeah, that's more or less what I mean. -K
On Apr 1, 2010, at 4:09 PM, Mark Struberg wrote:
I honestly doubt that wagon-scm + CVS
currently works when using branches (from glimpsing at the
sources).
And I'm not sure what you mean with forking
it. Wouldn't it be much easier to simply checkout wagon-scm
and if you found a way to provide the branch as ScmVersion
(ScmBranch and ScmTag are subclassses of ScmVersion [3]),
then simply open a Jira issue and add your changes as patch.
Patches are always highly welcome :)
txs and LieGrue,
strub
[3]
http://maven.apache.org/scm/apidocs/org/apache/maven/scm/ScmBranch.html
--- Kathryn Huxtable kath...@kathrynhuxtable.org
schrieb am Do, 1.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and
gitexe
An: Maven Users List users@maven.apache.org
Datum: Donnerstag, 1. April, 2010 22:43
Uhr
Thanks, Mark,
These are good points.
I'm thinking that the issues are in
wagon-scm, which is
listed as being in progress, so I can't
really expect
perfection. And they *do* say it's only
been tested with svn
and cvs. I'm thinking that I may be
modding wagon-svn, more
to see what's going on than to fork a
project.
All of this is by the way. I really should
be working on my
project, not fiddling with tools, but
fiddling with tools is
fun sometimes.
-K
On Apr 1, 2010, at 3:37 PM, Mark Struberg
wrote:
Kathryn,
I haven't used wagon-scm, so I can
only make vague
assumptions.
Basically all the branches and tag
Re: Problem with wagon-scm and gitexe
Okay, I'm not a CVS user, but I tried using wagon-scm with the
maven-scm-provider-cvsexe and a CVS URL and got:
Transfer error: org.apache.maven.scm.manager.NoSuchScmProviderException: No
such provider: 'cvs'.
I had given it the following site URL:
urlscm:cvs:ext:usern...@cvs.apache.org:/cvs/root:module/url
I know the connection stuff isn't valid, but surely that's not why I got that
error...
Also, one of the things I pointed out earlier on the particular git clone
command used by wagon-scm is the /. after the git repo name. This seems to be
an SVN holdover.
-K
On Apr 2, 2010, at 12:59 PM, Kathryn Huxtable wrote:
I don't really think there's a conceptual misunderstanding on my part, since
the format for the CVS URL in the SCM code allows for a module_name as part
of the URL, and not in standard URL syntax.
But I take your point.
My basic question of the moment is, who calls putDirectory? Is it called from
the release plugin? It seems to be getting called from the site plugin.
The wagon documentation leaves something to be desired for the unfamiliar
developer. Yes, there are javadocs, but they don't tell you *how* the public
methods and classes are used. I'm trying to figure that out without
complaining too much, or looking at all the code that uses wagons.
-K
On Apr 2, 2010, at 12:43 PM, Mark Struberg wrote:
Kathryn, I think there is a conceptional misunderstanding here.
Subversion is actually almost the ONLY SCM which has different URLs on
different branches.
Usually the version gets set via the -DscmVersion parameter which transfers
into the ScmVersion parameter in various functions of the maven-scm-api!
Your attempt with first determining/setting the branch with native git
commands would actually work with git, but I'd prefer to give wagon-scm the
branch as parameter and use that inside the code.
txs and LieGrue,
strub
--- Kathryn Huxtable kath...@kathrynhuxtable.org schrieb am Fr, 2.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and gitexe
An: Maven Users List users@maven.apache.org
Datum: Freitag, 2. April, 2010 18:56 Uhr
Here's an alternative script:
mkdir ${checkoutDirectory}
cd ${checkoutDirectory}
git init
git remote add -t ${siteBranch} origin ${gitRepoUrl}
git fetch
git checkout ${siteBranch}
replace the contents of the checkout directory, except
for the .git subdirectory, with the site docs
git add .
git commit -a -m Deploy site documentation
git push
rm -Rf ${checkoutDirectory}
-K
On Apr 2, 2010, at 11:28 AM, Kathryn Huxtable wrote:
So looking at the git SCM code (git-commons and
gitexe) and at the wagon-scm code, the problem I see is that
there is no syntax in the git SCM url to specify a branch to
which to deploy the site. Not a surprise, since git
generally wants to clone an entire repository and then push
and pull things.
The desired process would be something along the lines
of the following. (In UN*X-y/scripty/Velocity-y format.)
mkdir ${checkoutDirectory}
cd ${checkoutDirectory}
git init
git remote add origin ${gitRepoUrl}
git pull origin refs/heads/${siteBranch}
replace the contents of the checkout
directory, except for the .git subdirectory, with the site
docs
git add .
git commit -a -m Deploy site documentation.
git push origin master:${siteBranch}
rm -Rf ${checkoutDirectory}
This works.
Obviously, we wouldn't want to mess up the git SCM for
other uses. Does the release plugin use the wagon? I
*really* don't want to end up looking at all the Maven
source code.
Any ideas on where changes need to be made? In
wagon-scm? In gitexe or git-commons?
I see no way to configure wagons, which I find a bit
of a lack. I suppose the URL structure and username/password
info in settings.xml is supposed to take care of everything.
Should there be a branch element in the git scm url
structure a la the module element in CVS scm urls?
-K
On Apr 1, 2010, at 4:24 PM, Kathryn Huxtable wrote:
Yeah, that's more or less what I mean. -K
On Apr 1, 2010, at 4:09 PM, Mark Struberg wrote:
I honestly doubt that wagon-scm + CVS
currently works when using branches (from glimpsing at the
sources).
And I'm not sure what you mean with forking
it. Wouldn't it be much easier to simply checkout wagon-scm
and if you found a way to provide the branch as ScmVersion
(ScmBranch and ScmTag are subclassses of ScmVersion [3]),
then simply open a Jira issue and add your changes as patch.
Patches are always highly welcome :)
txs and LieGrue,
strub
[3]
http://maven.apache.org/scm/apidocs/org/apache/maven/scm/ScmBranch.html
--- Kathryn Huxtable kath...@kathrynhuxtable.org
schrieb am Do, 1.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and
gitexe
An: Maven Users List users@maven.apache.org
Datum: Donnerstag, 1. April, 2010 22:43
Uhr
Thanks
Re: Problem with wagon-scm and gitexe
On Apr 2, 2010, at 2:03 PM, Justin Edelson wrote: On Apr 2, 2010, at 1:59 PM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: I don't really think there's a conceptual misunderstanding on my part, since the format for the CVS URL in the SCM code allows for a module_name as part of the URL, and not in standard URL syntax. But I take your point. My basic question of the moment is, who calls putDirectory? Is it called from the release plugin? It seems to be getting called from the site plugin. This is a bit like asking who calls System.out.println; it's not really answerable. Wagon exposes an API and anyone is free to use it. I've written a few (closed source) plugins which use putDirectory and I suspect I'm not alone in this. Well, yeah, but I was trying to get at the expectations. The wagon-scm thing adds the target to the end of the repo, which, as has been pointed out, only works for subversion. *I'm* not the one doing it! AFAIK, the release plugin does not call putDirectory. The site:deploy mojo does. That was my guess. The wagon documentation leaves something to be desired for the unfamiliar developer. Yes, there are javadocs, but they don't tell you *how* the public methods and classes are used. I'm trying to figure that out without complaining too much, or looking at all the code that uses wagons. Doesn't matter *how* they're used. The only thing that matters is the contract of the API. If someone uses the Wagon API incorrectly, it sucks to be them, but it's not really your problem. If the API contract needs clarification, that's a seperate issue, but I seem to remember the Wagon API being relatively obvious. I think it needs a bit of clarification. IMHO, you should be writing your own wagon implementation and avoid using wagon-scm. This use case is very specific to github. This way, you're free to define your own URL syntax. Well, that's what I was thinking about doing. It looks to me as if the wagon-scm is in pretty early stages and really only works with svn. I'm still boggled that wagons don't seem to be configurable. I'll take a closer look at the API javadocs. Again, I think there should be more site docs for wagons. Thanks very much for your response, -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with wagon-scm and gitexe
On Apr 2, 2010, at 2:22 PM, Kathryn Huxtable wrote: On Apr 2, 2010, at 2:03 PM, Justin Edelson wrote: IMHO, you should be writing your own wagon implementation and avoid using wagon-scm. This use case is very specific to github. This way, you're free to define your own URL syntax. Well, that's what I was thinking about doing. It looks to me as if the wagon-scm is in pretty early stages and really only works with svn. I'm still boggled that wagons don't seem to be configurable. Okay, I see that wagons are configurable in the settings.xml file. Bleah. I've taken a chainsaw and hacked away at wagon-scm and have something that works to deploy to GitHub. I'll clean it up a bit and deploy it. Others who use GitHub may find it useful. Of course, I gather that things are changing quite a bit with Maven 3.0, but I haven't looked at it yet. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using variables in POM's version field
On Apr 2, 2010, at 5:39 PM, Scott Susslin wrote:
We're working in Agile, and QA needs to know what version number their
working against. Since they're QAing about every day, I'd like to have them
know exactly which version they're hitting without forcing the developers to
change the version number manually every day. We'd only be using this number
below the major.minor in our version, and only for SNAPSHOTs, so I don't see
the harm in using it for that. A release build will be an agreed-up, solid
number.
When I tried it, the output from install looked like the following:
[INFO] Installing PROJECT/artifact-0.1.334-SNAPSHOT.swc to
~.m2/repository/PROJECT/artifact/0.1.${buildNumber}-SNAPSHOT/artifact-0.1.${buildNumber}-SNAPSHOT.swc
Obviously, ${buildNumber} shoulda been 334
- Original Message
From: Wendy Smoak wsm...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 2:17:08 PM
Subject: Re: Using variables in POM's version field
On Fri, Apr 2, 2010 at 5:14 PM, Scott Susslin goi...@yahoo.com wrote:
Why?
Also, is it possible?
What happened when you tried it?
What are you trying to accomplish? Snapshots are already timestamped
with a build number...
As Wendy said, snapshots are already timestamped. You seem to be doing
something dangerous like not using a real repository manager such as
Artifactory or Nexus. (I prefer Nexus, having used both.)
If you are using NFS to share your .m2/repository directory you are in for
trouble.
-K
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Using variables in POM's version field
Correct, and it's a bad idea. -K
On Apr 2, 2010, at 6:15 PM, Scott Susslin wrote:
I figured something like this was why it wasn't working. So sounds like,
given Maven 2, it can't work. True?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 4:05:10 PM
Subject: Re: Using variables in POM's version field
Amongst other reasons, allowing runtime variable interpolation in the
coordinates would prevent the reactor from properly calculating a
multi-module build plan. The coordinates at the start of the build
must remain the coordinates throughout the build.
On Apr 2, 2010, at 5:14 PM, Scott Susslin goi...@yahoo.com wrote:
Why?
Also, is it possible?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 12:05:32 PM
Subject: Re: Using variables in POM's version field
This is a bad idea. Don't do it.
On Apr 2, 2010, at 2:21 PM, Scott Susslin goi...@yahoo.com wrote:
I'm trying to use the buildnumber plugin to control the version
field of a POM.
version1.0.${buildNumber}-SNAPSHOT/version
The package phase works fine, creating a file with the parsed
value in the filename. The install and deploy don't seem to
parse the variable. When they run, I get something like the
following:
[INFO] Installing PROJECT/artifact-0.1.334-SNAPSHOT.swc to ~.m2/
repository/PROJECT/artifact/0.1.${buildNumber}-SNAPSHOT/
artifact-0.1.${buildNumber}-SNAPSHOT.swc
Anyone have any experience with this?
Thanks
- Scott
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with wagon-scm and gitexe
I've deployed it to the URL below but it sucks. Seriously, I hacked it with a chainsaw. http://github.com/khuxtable/wagon-gitsite Actually, there are just a few changes necessary to the wagon-scm necessary to get it to work with git and site:deploy 1) Don't append the target directory to the repository. 2) Allow specification of the branch or revision information. The former is a one-line change and would be necessary, I think, for it to work with CVS anyway. The latter is pretty simple and would require configuring the scmRevision and scmRevisionType parameters in the settings.xml file, since parameters on the command line or the site plugin don't seem to propagate into the wagon. I'll submit patches for that, but in the spirit of Larry Wall (there's more than one way to do it) I'll go ahead and work on this and spiff it up. -K On Apr 2, 2010, at 7:13 PM, Justin Edelson wrote: Kathryn- I'm very curious to see your code. Please do let me know when it's posted somewhere (presumably github). Justin On Apr 2, 2010, at 7:08 PM, Kathryn Huxtable kath...@kathrynhuxtable.org wrote: On Apr 2, 2010, at 2:22 PM, Kathryn Huxtable wrote: On Apr 2, 2010, at 2:03 PM, Justin Edelson wrote: IMHO, you should be writing your own wagon implementation and avoid using wagon-scm. This use case is very specific to github. This way, you're free to define your own URL syntax. Well, that's what I was thinking about doing. It looks to me as if the wagon-scm is in pretty early stages and really only works with svn. I'm still boggled that wagons don't seem to be configurable. Okay, I see that wagons are configurable in the settings.xml file. Bleah. I've taken a chainsaw and hacked away at wagon-scm and have something that works to deploy to GitHub. I'll clean it up a bit and deploy it. Others who use GitHub may find it useful. Of course, I gather that things are changing quite a bit with Maven 3.0, but I haven't looked at it yet. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Problem with wagon-scm and gitexe
I know the docs say that wagon-scm has only been tested with CVS and
Subversion, and I've run it with Subversion successfully.
Is anyone working on getting it to work with Git, or does it already?
I created a very simply project with a README and a pom.xml and nothing else.
It's at
http://github.com/khuxtable/test-project
It uses versions 1.3 of the gitexe and scm-manager-plexus extensions and
version 1.0-beta-6 of the scm wagon.
What I would like to do is deploy my site docs (all generated by the site
plugin) to the gh-pages branch of the git repository. I don't see any way in
the Git SCM URL structure to specify a branch. If there was a way to do this it
would be cool.
But at the moment, with the URL
scm:git:ssh://g...@github.com/khuxtable/test-project.git
I get the following:
[INFO] [site:deploy {execution: default-cli}]
scm:git:ssh://github.com/khuxtable/test-project.git - Session: Opened
Uploading: . to scm:git:ssh://github.com/khuxtable/test-project.git
[INFO] Executing: /bin/sh -c cd
/Users/huxtable/Documents/workspace/test-project/. git ls-files
[INFO] Working directory: /Users/huxtable/Documents/workspace/test-project/.
[INFO] Executing: /bin/sh -c cd
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp- git clone
ssh://g...@github.com/khuxtable/test-project.git/.
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-/wagon-scm223596417.checkout
[INFO] Working directory: /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-
Transfer error: org.apache.maven.scm.ScmException: Unable to commit file. The
git-clone command failed. ERROR: Repository not found. Make sure you include
the .git, e.g. g...@github.com:defunkt/ambition.git
fatal: The remote end hung up unexpectedly
scm:git:ssh://github.com/khuxtable/test-project.git - Session: Disconnecting
scm:git:ssh://github.com/khuxtable/test-project.git - Session: Disconnected
I particularly like the /. after the repository name. Funny.
The maven release plugin behaves fine with the same developerConnection as my
site URL above.
Any ideas? I'm happy to help out with making this work, though I'm not a
committer at this point.
-K
Re: Problem with wagon-scm and gitexe
Since it seems to be my practice to have second thought after sending a
message, I'll add that I can check out the gh-pages branch of my git repository
into a separate directory and deploy there using a file: URL and then commit
that and push it.
That works. I just think it should be able to be automated.
-K
On Apr 1, 2010, at 12:14 PM, Kathryn Huxtable wrote:
I know the docs say that wagon-scm has only been tested with CVS and
Subversion, and I've run it with Subversion successfully.
Is anyone working on getting it to work with Git, or does it already?
I created a very simply project with a README and a pom.xml and nothing else.
It's at
http://github.com/khuxtable/test-project
It uses versions 1.3 of the gitexe and scm-manager-plexus extensions and
version 1.0-beta-6 of the scm wagon.
What I would like to do is deploy my site docs (all generated by the site
plugin) to the gh-pages branch of the git repository. I don't see any way in
the Git SCM URL structure to specify a branch. If there was a way to do this
it would be cool.
But at the moment, with the URL
scm:git:ssh://g...@github.com/khuxtable/test-project.git
I get the following:
[INFO] [site:deploy {execution: default-cli}]
scm:git:ssh://github.com/khuxtable/test-project.git - Session: Opened
Uploading: . to scm:git:ssh://github.com/khuxtable/test-project.git
[INFO] Executing: /bin/sh -c cd
/Users/huxtable/Documents/workspace/test-project/. git ls-files
[INFO] Working directory: /Users/huxtable/Documents/workspace/test-project/.
[INFO] Executing: /bin/sh -c cd
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp- git clone
ssh://g...@github.com/khuxtable/test-project.git/.
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-/wagon-scm223596417.checkout
[INFO] Working directory: /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-
Transfer error: org.apache.maven.scm.ScmException: Unable to commit file. The
git-clone command failed. ERROR: Repository not found. Make sure you include
the .git, e.g. g...@github.com:defunkt/ambition.git
fatal: The remote end hung up unexpectedly
scm:git:ssh://github.com/khuxtable/test-project.git - Session: Disconnecting
scm:git:ssh://github.com/khuxtable/test-project.git - Session: Disconnected
I particularly like the /. after the repository name. Funny.
The maven release plugin behaves fine with the same developerConnection as my
site URL above.
Any ideas? I'm happy to help out with making this work, though I'm not a
committer at this point.
-K
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with wagon-scm and gitexe
Thanks, Mark,
These are good points.
I'm thinking that the issues are in wagon-scm, which is listed as being in
progress, so I can't really expect perfection. And they *do* say it's only
been tested with svn and cvs. I'm thinking that I may be modding wagon-svn,
more to see what's going on than to fork a project.
All of this is by the way. I really should be working on my project, not
fiddling with tools, but fiddling with tools is fun sometimes.
-K
On Apr 1, 2010, at 3:37 PM, Mark Struberg wrote:
Kathryn,
I haven't used wagon-scm, so I can only make vague assumptions.
Basically all the branches and tag stuff should be working in
maven-scm-provider-gitexe. But I'm not sure how wagon-scm tells us what
branch it likes to use.
From looking at the source [1] I only can see that all ScmVersion parameters
are always given as null. So I'm not sure if that could work at all.
Please keep in mind that SVN is really exceptional with handling branches by
copying the trunk to a new location. This way you get an own URL which you
won't get in most other SCMs like CVS, PVCS, git or hg. In fact SVN doesn't
have a 'real' branch and tag concept but internally always performs a full
shallow copy.
So it would be interesting if this would also work e.g. with CVS.
LieGrue,
strub
[1]
http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-providers/wagon-scm/src/main/java/org/apache/maven/wagon/providers/scm/ScmWagon.java?view=markup
--- Kathryn Huxtable kath...@kathrynhuxtable.org schrieb am Do, 1.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and gitexe
An: Maven Users List users@maven.apache.org
Datum: Donnerstag, 1. April, 2010 19:21 Uhr
Since it seems to be my practice to
have second thought after sending a message, I'll add that I
can check out the gh-pages branch of my git repository into
a separate directory and deploy there using a file: URL
and then commit that and push it.
That works. I just think it should be able to be
automated.
-K
On Apr 1, 2010, at 12:14 PM, Kathryn Huxtable wrote:
I know the docs say that wagon-scm has only been
tested with CVS and Subversion, and I've run it with
Subversion successfully.
Is anyone working on getting it to work with Git, or
does it already?
I created a very simply project with a README and a
pom.xml and nothing else. It's at
http://github.com/khuxtable/test-project
It uses versions 1.3 of the gitexe and
scm-manager-plexus extensions and version 1.0-beta-6 of the
scm wagon.
What I would like to do is deploy my site docs (all
generated by the site plugin) to the gh-pages branch of the
git repository. I don't see any way in the Git SCM URL
structure to specify a branch. If there was a way to do this
it would be cool.
But at the moment, with the URL
scm:git:ssh://g...@github.com/khuxtable/test-project.git
I get the following:
[INFO] [site:deploy {execution: default-cli}]
scm:git:ssh://github.com/khuxtable/test-project.git -
Session: Opened
Uploading: . to
scm:git:ssh://github.com/khuxtable/test-project.git
[INFO] Executing: /bin/sh -c cd
/Users/huxtable/Documents/workspace/test-project/.
git ls-files
[INFO] Working directory:
/Users/huxtable/Documents/workspace/test-project/.
[INFO] Executing: /bin/sh -c cd
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-
git clone ssh://g...@github.com/khuxtable/test-project.git/.
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-/wagon-scm223596417.checkout
[INFO] Working directory:
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-
Transfer error: org.apache.maven.scm.ScmException:
Unable to commit file. The git-clone command failed. ERROR:
Repository not found. Make sure you include the .git,
e.g. g...@github.com:defunkt/ambition.git
fatal: The remote end hung up unexpectedly
scm:git:ssh://github.com/khuxtable/test-project.git -
Session: Disconnecting
scm:git:ssh://github.com/khuxtable/test-project.git -
Session: Disconnected
I particularly like the /. after the repository
name. Funny.
The maven release plugin behaves fine with the same
developerConnection as my site URL above.
Any ideas? I'm happy to help out with making this
work, though I'm not a committer at this point.
-K
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
gegen Massenmails.
http://mail.yahoo.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with wagon-scm and gitexe
Yeah, that's more or less what I mean. -K
On Apr 1, 2010, at 4:09 PM, Mark Struberg wrote:
I honestly doubt that wagon-scm + CVS currently works when using branches
(from glimpsing at the sources).
And I'm not sure what you mean with forking it. Wouldn't it be much easier to
simply checkout wagon-scm and if you found a way to provide the branch as
ScmVersion (ScmBranch and ScmTag are subclassses of ScmVersion [3]), then
simply open a Jira issue and add your changes as patch. Patches are always
highly welcome :)
txs and LieGrue,
strub
[3] http://maven.apache.org/scm/apidocs/org/apache/maven/scm/ScmBranch.html
--- Kathryn Huxtable kath...@kathrynhuxtable.org schrieb am Do, 1.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and gitexe
An: Maven Users List users@maven.apache.org
Datum: Donnerstag, 1. April, 2010 22:43 Uhr
Thanks, Mark,
These are good points.
I'm thinking that the issues are in wagon-scm, which is
listed as being in progress, so I can't really expect
perfection. And they *do* say it's only been tested with svn
and cvs. I'm thinking that I may be modding wagon-svn, more
to see what's going on than to fork a project.
All of this is by the way. I really should be working on my
project, not fiddling with tools, but fiddling with tools is
fun sometimes.
-K
On Apr 1, 2010, at 3:37 PM, Mark Struberg wrote:
Kathryn,
I haven't used wagon-scm, so I can only make vague
assumptions.
Basically all the branches and tag stuff should be
working in maven-scm-provider-gitexe. But I'm not sure how
wagon-scm tells us what branch it likes to use.
From looking at the source [1] I only can see that all
ScmVersion parameters are always given as null. So I'm not
sure if that could work at all.
Please keep in mind that SVN is really exceptional
with handling branches by copying the trunk to a new
location. This way you get an own URL which you won't get in
most other SCMs like CVS, PVCS, git or hg. In fact SVN
doesn't have a 'real' branch and tag concept but internally
always performs a full shallow copy.
So it would be interesting if this would also work
e.g. with CVS.
LieGrue,
strub
[1]
http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-providers/wagon-scm/src/main/java/org/apache/maven/wagon/providers/scm/ScmWagon.java?view=markup
--- Kathryn Huxtable kath...@kathrynhuxtable.org
schrieb am Do, 1.4.2010:
Von: Kathryn Huxtable kath...@kathrynhuxtable.org
Betreff: Re: Problem with wagon-scm and gitexe
An: Maven Users List users@maven.apache.org
Datum: Donnerstag, 1. April, 2010 19:21 Uhr
Since it seems to be my practice to
have second thought after sending a message, I'll
add that I
can check out the gh-pages branch of my git
repository into
a separate directory and deploy there using a
file: URL
and then commit that and push it.
That works. I just think it should be able to be
automated.
-K
On Apr 1, 2010, at 12:14 PM, Kathryn Huxtable
wrote:
I know the docs say that wagon-scm has only
been
tested with CVS and Subversion, and I've run it
with
Subversion successfully.
Is anyone working on getting it to work with
Git, or
does it already?
I created a very simply project with a README
and a
pom.xml and nothing else. It's at
http://github.com/khuxtable/test-project
It uses versions 1.3 of the gitexe and
scm-manager-plexus extensions and version
1.0-beta-6 of the
scm wagon.
What I would like to do is deploy my site docs
(all
generated by the site plugin) to the gh-pages
branch of the
git repository. I don't see any way in the Git SCM
URL
structure to specify a branch. If there was a way
to do this
it would be cool.
But at the moment, with the URL
scm:git:ssh://g...@github.com/khuxtable/test-project.git
I get the following:
[INFO] [site:deploy {execution: default-cli}]
scm:git:ssh://github.com/khuxtable/test-project.git -
Session: Opened
Uploading: . to
scm:git:ssh://github.com/khuxtable/test-project.git
[INFO] Executing: /bin/sh -c cd
/Users/huxtable/Documents/workspace/test-project/.
git ls-files
[INFO] Working directory:
/Users/huxtable/Documents/workspace/test-project/.
[INFO] Executing: /bin/sh -c cd
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-
git clone ssh://g...@github.com/khuxtable/test-project.git/.
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-/wagon-scm223596417.checkout
[INFO] Working directory:
/var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-
Transfer error:
org.apache.maven.scm.ScmException:
Unable to commit file. The git-clone command
failed. ERROR:
Repository not found. Make sure you include
the .git,
e.g. g...@github.com:defunkt/ambition.git
fatal: The remote end hung up unexpectedly
scm:git:ssh://github.com/khuxtable/test-project.git -
Session: Disconnecting
scm:git:ssh://github.com/khuxtable/test-project.git -
Session
Re: Does wagon-scm work with maven-scm-provider-gitexe?
Okay, updating the plexus utils has other issues in my project, but I'll figure them out. Reordering the extensions did the trick for the extension versions. Thanks. I've created a very simple project at http://github.com/khuxtable/test-project, which has no source (or docs) just to test site deploy. So the files I'm deploying are all just generated reports from the reporting element. I have the following in my POM: distributionManagement site idtest-project-site/id urlscm:git:git+ssh://g...@github.com/khuxtable/test-project.git/url !--urlscm:svn:https://seaglass.googlecode.com/svn/test-project-site/url-- /site /distributionManagement scm connectionscm:git:git://github.com/khuxtable/test-project.git/connection developerConnectionscm:git:git+ssh://g...@github.com/khuxtable/test-project.git/developerConnection urlhttp://github.com/khuxtable/test-project/url /scm I get the following error when I do mvn site:deploy: scm:git:git+ssh://github.com/khuxtable/test-project.git - Session: Opened Uploading: . to scm:git:git+ssh://github.com/khuxtable/test-project.git [INFO] Executing: /bin/sh -c cd /Users/huxtable/Documents/workspace/test-project/. git ls-files [INFO] Working directory: /Users/huxtable/Documents/workspace/test-project/. [INFO] Executing: /bin/sh -c cd /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp- git clone git+ssh//github.com/khuxtable/test-project.git/. /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-/wagon-scm472467110.checkout [INFO] Working directory: /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp- Transfer error: org.apache.maven.scm.ScmException: Unable to commit file. The git-clone command failed. fatal: Could not switch to 'git+ssh//github.com/khuxtable/test-project.git': No such file or directory scm:git:git+ssh://github.com/khuxtable/test-project.git - Session: Disconnecting scm:git:git+ssh://github.com/khuxtable/test-project.git - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site It looks to me as if someone is munging the repo URL. I'm using the same syntax for it that I use for the developerConnection element. Should I be? What I really want to do, of course, is to push to the gh-pages branch, but I don't see any configuration to allow me to do that. -K On Mar 29, 2010, at 1:18 PM, Brett Porter wrote: On 29/03/2010, at 1:29 PM, Kathryn Huxtable wrote: urls[1] = file:/Users/huxtable/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar It looks like the project is using an older version of this library than is needed (at least 1.5.6). You should add the newer version to you extensions also. Re-ordering the extensions so that SCM is listed first may also help. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: wagon-users-unsubscr...@maven.apache.org For additional commands, e-mail: wagon-users-h...@maven.apache.org
Re: Does wagon-scm work with maven-scm-provider-gitexe?
On Mar 30, 2010, at 11:29 AM, Kathryn Huxtable wrote: [INFO] Executing: /bin/sh -c cd /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp- git clone git+ssh//github.com/khuxtable/test-project.git/. /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-/wagon-scm472467110.checkout I especially like the /. after the test-project.git. Funny. I have just tried the url scm:git:g...@github.com:khuxtable/test-project.git and got [INFO] Executing: /bin/sh -c cd /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp- git clone 'g...@github.com:khuxtable/test-project.git gh-pages/.' /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-/wagon-scm587989183.checkout [INFO] Working directory: /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp- Transfer error: org.apache.maven.scm.ScmException: Unable to commit file. The git-clone command failed. ERROR: Repository not found. Make sure you include the .git, e.g. g...@github.com:defunkt/ambition.git Which is just as funny, if not funnier. It's a lot closer to what I want, which is of course git clone 'g...@github.com:khuxtable/test-project.git' -b gh-pages '/var/folders/blahblahblah' -K
Re: Does wagon-scm work with maven-scm-provider-gitexe?
Okay, I see, looking at the source for maven-scm-provider-gitexe that list
isn't implemented. It is apparently used by the wagen-scm extension. I've
verified that the wagon-scm does work with my subversion repo.
So git just isn't as mature at this point.
Is anyone actively developing wagon-scm?
Why aren't the wagons compatible with version 1.3 of the scm code. I couldn't
use anything later than 1.1 if I wanted the wagon-scm to work.
Inquiring minds want to know...
-K
On Mar 28, 2010, at 9:29 PM, Kathryn Huxtable wrote:
And if so, what versions?
I'm working on a plugin, so I'm including a bunch of plexus and other stuff.
Is that important?
I have the following in my POM:
extensions
extension
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-scm/artifactId
version1.0-beta-6/version
/extension
extension
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-manager-plexus/artifactId
version1.3/version
/extension
extension
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-provider-gitexe/artifactId
version1.3/version
/extension
/extensions
And:
distributionManagement
...
site
idgh-pages/id
urlscm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git/url
/site
/distributionManagement
I'm using version 2.1 of the site plugin. When I run mvn site:deploy I get:
[INFO] [site:deploy {execution: default-cli}]
scm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git - Session:
Opened
Uploading: . to
scm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git
scm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git - Session:
Disconnecting
scm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git - Session:
Disconnected
[FATAL ERROR] org.apache.maven.plugins.site.SiteDeployMojo#execute() caused a
linkage error (java.lang.NoSuchMethodError) and may be out-of-date. Check the
realms:
[FATAL ERROR] Plugin realm =
app0.child-container[org.apache.maven.plugins:maven-site-plugin:2.1]
urls[0] =
file:/Users/huxtable/.m2/repository/org/apache/maven/plugins/maven-site-plugin/2.1/maven-site-plugin-2.1.jar
urls[1] =
file:/Users/huxtable/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar
urls[2] =
file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.1.2/doxia-module-xhtml-1.1.2.jar
urls[3] =
file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-core/1.1.2/doxia-core-1.1.2.jar
urls[4] =
file:/Users/huxtable/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
urls[5] =
file:/Users/huxtable/.m2/repository/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar
urls[6] =
file:/Users/huxtable/.m2/repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
urls[7] =
file:/Users/huxtable/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar
urls[8] =
file:/Users/huxtable/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
urls[9] =
file:/Users/huxtable/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
urls[10] =
file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-module-apt/1.1.2/doxia-module-apt-1.1.2.jar
urls[11] =
file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.1.2/doxia-module-xdoc-1.1.2.jar
urls[12] =
file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.1.2/doxia-module-fml-1.1.2.jar
urls[13] =
file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.1.2/doxia-decoration-model-1.1.2.jar
urls[14] =
file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.1.2/doxia-site-renderer-1.1.2.jar
urls[15] =
file:/Users/huxtable/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar
urls[16] =
file:/Users/huxtable/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.8/plexus-velocity-1.1.8.jar
urls[17] =
file:/Users/huxtable/.m2/repository/org/apache/velocity/velocity/1.5/velocity-1.5.jar
urls[18] =
file:/Users/huxtable/.m2/repository/commons-collections/commons-collections/3.2/commons-collections-3.2.jar
urls[19] = file:/Users/huxtable/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar
urls[20] =
file:/Users/huxtable/.m2/repository/org/apache/maven/shared/maven-doxia-tools/1.2/maven-doxia-tools-1.2.jar
urls[21] =
file:/Users/huxtable/.m2/repository/commons-io/commons-io/1.4/commons-io-1.4.jar
urls[22] =
file:/Users/huxtable/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar
urls[23] =
file:/Users/huxtable/.m2/repository/org/mortbay/jetty/jetty/6.1.5/jetty-6.1.5.jar
urls[24] =
file:/Users/huxtable/.m2/repository/org/mortbay/jetty/jetty-util/6.1.5/jetty-util-6.1.5.jar
urls[25] =
file:/Users/huxtable/.m2/repository/org/mortbay/jetty/servlet-api-2.5/6.1.5/servlet-api-2.5-6.1.5
Re: Does wagon-scm work with maven-scm-provider-gitexe?
On Mar 28, 2010, at 9:29 PM, Kathryn Huxtable wrote: And if so, what versions? I'm working on a plugin, so I'm including a bunch of plexus and other stuff. Is that important? ... I should have mentioned that I'm running Maven 2.2.1. -K - To unsubscribe, e-mail: wagon-users-unsubscr...@maven.apache.org For additional commands, e-mail: wagon-users-h...@maven.apache.org
