test-libraries-for-java - Project Hosting on Google Code

Today 60 min ago issue 3 (Add TestNG support) reported by Krishnan.1000 - TestNG test framework is not supported in this libraries, which I think is a shame because of the same principles that apply to JUnit 4.x can apply to TestNG framework. I have written code intended to support TestNG framework and I would like to submit it for check in. Any feedback would be appreciated and welcome. I have included JUnit tests for TearDownTestCase and TestNGAsserts. TestNG test framework is not supported in this libraries, which I think is a shame because of the same principles that apply to JUnit 4.x can apply to TestNG framework. I have written code intended to support TestNG framework and I would like to submit it for check in. Any feedback would be appreciated and welcome. I have included JUnit tests for TearDownTestCase and TestNGAsserts. Older Jun 30, 2009 tl4j-junit4-1.1.1.jar (JUnit 4 self-contained jar (this is tl4j-junit4-only + agnos...) file uploaded by zorzella - Labels: Featured Type-Package OpSys-All Labels: Featured Type-Package OpSys-All Jun 30, 2009 tl4j-1.1.1-src.jar (source jars (has all the sources)) file uploaded by zorzella - Labels: Type-Source OpSys-All Labels: Type-Source OpSys-All Jun 30, 2009 tl4j-junit3-1.1.1.jar (JUnit 3 self-contained jar (this is tl4j-junit3-only + agnos...) file uploaded by zorzella - Labels: Type-Package OpSys-All Labels: Type-Package OpSys-All Jun 30, 2009 tl4j-agnostic-1.1.1.jar (jar with the non-junit (agnostic) classes) file uploaded by zorzella - Labels: Type-Package OpSys-All Labels: Type-Package OpSys-All Jun 30, 2009 tl4j-junit4-only-1.1.1.jar (jar with only the JUnit 4-specific classes) file uploaded by zorzella - Labels: Type-Package OpSys-All Labels: Type-Package OpSys-All Jun 30, 2009 tl4j-junit3-only-1.1.1.jar (jar with only the JUnit 3-specific classes) file uploaded by zorzella - Labels: Type-Package OpSys-All Labels: Type-Package OpSys-All Jun 30, 2009 tl4j-release-1.1.1.zip (Full project tree zip) file uploaded by zorzella - Labels: Type-Source OpSys-All Labels: Type-Source OpSys-All Jun 30, 2009 issue 2 (Add JUnit4 support) commented on by zorzella - I've commited a new pom (modified from Miroslav's latest) together with a set of instructions on how to release (run doc/howtorelease.sh). The most notable change is that junit-common is really not junit-specific, so I renamed the pom profile to "agnostic". A few issues/quirks remain, and I'll just list them here from most to least annoying: * releasing is a multi-step pain in the neck. Anything that can be done to automate/simplify is welcome * the HOW_TO_RELEASE.txt doc still lacks the "mvn deploy" instructions * there's a single source jar that gets generated, which has jars for all bin jars. * the same tests get run multiple times while "install"ing * "mvn install" should simply print out a message telling the person to run doc/howtorelease, rather than do whatever it is doing right now I'm going to be testing the instructions right now. I've commited a new pom (modified from Miroslav's latest) together with a set of instructions on how to release (run doc/howtorelease.sh). The most notable change is that junit-common is really not junit-specific, so I renamed the pom profile to "agnostic". A few issues/quirks remain, and I'll just list them here from most to least annoying: * releasing is a multi-step pain in the neck. Anything that can be done to automate/simplify is welcome * the HOW_TO_RELEASE.txt doc still lacks the "mvn deploy" instructions * there's a single source jar that gets generated, which has jars for all bin jars. * the same tests get run multiple times while "install"ing * "mvn install" should simply print out a message telling the person to run doc/howtorelease, rather than do whatever it is doing right now I'm going to be testing the instructions right now. Jun 30, 2009 r31 (JUnitAsserts moved (duplicated) to junit3 and junit4 subpack...) committed by zorzella - JUnitAsserts moved (duplicated) to junit3 and junit4 subpackages JUnitAsserts moved (duplicated) to junit3 and junit4 subpackages Jun 30, 2009 r30 (Junit4 support. doc/howtorelease.sh) committed by zorzella - Junit4 support. doc/howtorelease.sh Junit4 support. doc/howtorelease.sh Jun 19, 2009 issue 2 (Add JUnit4 support) commented on by zorzella - 1) Hmm, this page seems to imply I can issue comma-separated profiles: http://maven.apache.org/guides/introduction/introduction-to-profiles.html But, as you say, this does not seem to be working (that was my confusion -- I thought profiles were overwriting each other's jars). That kind of sucks, but it's not the end of the world. 4) If you want to do the release plugin thing, I'd be grateful. Otherwise, a HOW_TO_RELEASE.txt is a great start... Thanks, Z 1) Hmm, this page seems to imply I can issue comma-separated profiles: http://maven.apache.org/guides/introduction/introduction-to-profiles.html But, as you say, this does not seem to be working (that was my confusion -- I thought profiles were overwriting each other's jars). That kind of sucks, but it's not the end of the world. 4) If you want to do the release plugin thing, I'd be grateful. Otherwise, a HOW_TO_RELEASE.txt is a great start... Thanks, Z Jun 19, 2009 issue 2 (Add JUnit4 support) commented on by MGenov - About 1) For badness I think that maven allows only one profile to be executed at time. For example mvn install -P junit3 "It seems the names in the pom are declared to overwrite each other, but I can't quite figure out the best change, and why "junit4" has its own different name." I can't figure out what you mean. Please elaborate. About 2) We could set some of the profiles as a default profile which will be used by default without the "-P" switch. About 3) I'm on a way of doing this. Please wait for the next version of the pom file. It's on my todo list right now. About 4) To make this as simple as possible, we have to configure the release plugin of maven ( http://maven.apache.org/plugins/maven-release-plugin/ ). As I remember with this plugin you have to execute one or maybe two goals ( one to test whether the new release could be created and one to create it ). The plugin is responsible for the creation of a new branch, copying the trunk into that branch, modifies the pom version number and commits the changes into the trunk and etc. If you would like this future, I could add this plugin to the pom.xml and to create some kind of HOW_TO_RELEASE.txt which describes with few words the basic usage of the release plugin and the other stuff if it's necessary. About 1) For badness I think that maven allows only one profile to be executed at time. For example mvn install -P junit3 "It seems the names in the pom are declared to overwrite each other, but I can't quite figure out the best change, and why "junit4" has its own different name." I can't figure out what you mean. Please elaborate. About 2) We could set some of the profiles as a default profile which will be used by default without the "-P" switch. About 3) I'm on a way of doing this. Please wait for the next version of the pom file. It's on my todo list right now. About 4) To make this as simple as possible, we have to configure the release plugin of maven ( http://maven.apache.org/plugins/maven-release-plugin/ ). As I remember with this plugin you have to execute one or maybe two goals ( one to test whether the new release could be created and one to create it ). The plugin is responsible for the creation of a new branch, copying the trunk into that branch, modifies the pom version number and commits the changes into the trunk and etc. If you would like this future, I could add this plugin to the pom.xml and to create some kind of HOW_TO_RELEASE.txt which describes with few words the basic usage of the release plugin and the other stuff if it's necessary. Jun 17, 2009 r29 (Delete lib) committed by zorzella - Delete lib Delete lib Jun 17, 2009 r28 (Delete build.xml and build.properties) committed by zorzella - Delete build.xml and build.properties Delete build.xml and build.properties Jun 17, 2009 issue 2 (Add JUnit4 support) commented on by zorzella - I've got questions: 1. The way I understand is that now I would do something like: $ mvn install -P junit3,junit4,junit3-only,junit4-only,junit3-common But I get only 2 jars generated: ./target/tl4j.jar ./target/tl4j-junit4.jar It seems the names in the pom are declared to overwrite each other, but I can't quite figure out the best change, and why "junit4" has its own different name. 2. "mvn install" (no "-P") now does its own thing that has no use. Is it possible to have "mvn install" trigger the command at "1"? Or, at least, simply print out a message instructing "run it with -P ..." 3. It seems the generated jars have no version number. 4. Not really related to this, but what's the canonical set of commands I would run for a complete release build? I need to create a HOW_TO_RELEASE document, and at this point I already forgot. The steps are: create svn branch, change version in pom.xml, clean, compile/run tests, package sources, package zip, deploy to maven repo, manually deploy to googlecode. BTW, I just realized I forgot to delete build.xml and build.properties. I'll do that soon. I've got questions: 1. The way I understand is that now I would do something like: $ mvn install -P junit3,junit4,junit3-only,junit4-only,junit3-common But I get only 2 jars generated: ./target/tl4j.jar ./target/tl4j-junit4.jar It seems the names in the pom are declared to overwrite each other, but I can't quite figure out the best change, and why "junit4" has its own different name. 2. "mvn install" (no "-P") now does its own thing that has no use. Is it possible to have "mvn install" trigger the command at "1"? Or, at least, simply print out a message instructing "run it with -P ..." 3. It seems the generated jars have no version number. 4. Not really related to this, but what's the canonical set of commands I would run for a complete release build? I need to create a HOW_TO_RELEASE document, and at this point I already forgot. The steps are: create svn branch, change version in pom.xml, clean, compile/run tests, package sources, package zip, deploy to maven repo, manually deploy to googlecode. BTW, I just realized I forgot to delete build.xml and build.properties. I'll do that soon. Jun 17, 2009 issue 2 (Add JUnit4 support) commented on by MGenov - Here is an updated version of the pom which has few lines less then the previous pom. I know that the switching between profiles is not so good, but as I know in maven 2 it's the only solution. Here is a quote from the plugin documentation: -- Quote Starts Here -- If you are looking to produce JARs that are different (ie, they have their own dependencies and metadata), Maven doesn't support this. This usually is only needed when sharing a source directory for intrinsically different things, so the use case above applies instead. If you are producing a JAR that is a derivative of the original (eg, just a subset of classes, or the same JAR with debugging enabled), the Maven supports this completely using profiles. See Introduction to Profiles for more information. -- Quote Ends Here -- Here is an updated version of the pom which has few lines less then the previous pom. I know that the switching between profiles is not so good, but as I know in maven 2 it's the only solution. Here is a quote from the plugin documentation: -- Quote Starts Here -- If you are looking to produce JARs that are different (ie, they have their own dependencies and metadata), Maven doesn't support this. This usually is only needed when sharing a source directory for intrinsically different things, so the use case above applies instead. If you are producing a JAR that is a derivative of the original (eg, just a subset of classes, or the same JAR with debugging enabled), the Maven supports this completely using profiles. See Introduction to Profiles for more information. -- Quote Ends Here -- Jun 17, 2009 issue 2 (Add JUnit4 support) commented on by MGenov - I think that I got a solution. I'm attaching a sample pom.xml which is doing this by specifying the name of the profile. Here are some examples that may help you how to use them: mvn clean package -P junit3-only Would generate the output file: target\tl4j-junit3-only.jar and etc. The available profiles currently are: junit3-only, junit4-only, junit3- common,junit3,junit4 Hope this will help. If you have some thoughts or comments about the solution, please let me know about them. I think that I got a solution. I'm attaching a sample pom.xml which is doing this by specifying the name of the profile. Here are some examples that may help you how to use them: mvn clean package -P junit3-only Would generate the output file: target\tl4j-junit3-only.jar and etc. The available profiles currently are: junit3-only, junit4-only, junit3- common,junit3,junit4 Hope this will help. If you have some thoughts or comments about the solution, please let me know about them. Jun 17, 2009 r27 (non-public ClusterException) committed by zorzella - non-public ClusterException non-public ClusterException Jun 17, 2009 issue 2 (Add JUnit4 support) reported by zorzella - The code has already been added (there's a new junit4.TearDownTestCase class that mirrors junit3.TearDownTestCase). What's left is to change the pom. Here's what I want: it needs to generate 5 jars: a. tl4j-junit3-only.jar: just the "junit3" package b. tl4j-junit4-only.jar: just the "junit4" package c. tl4j-junit3-common.jar: all package except junit3 and junit4 d. tl4j-junit3.jar: contains a+c e. tl4j-junit4.jar: contains b+c The last two packages is what I will feature, as most people will simply choose junit3 or junit4. For reasons I won't go into, I also need the other packages above generated somehow... The code has already been added (there's a new junit4.TearDownTestCase class that mirrors junit3.TearDownTestCase). What's left is to change the pom. Here's what I want: it needs to generate 5 jars: a. tl4j-junit3-only.jar: just the "junit3" package b. tl4j-junit4-only.jar: just the "junit4" package c. tl4j-junit3-common.jar: all package except junit3 and junit4 d. tl4j-junit3.jar: contains a+c e. tl4j-junit4.jar: contains b+c The last two packages is what I will feature, as most people will simply choose junit3 or junit4. For reasons I won't go into, I also need the other packages above generated somehow... Jun 15, 2009 r26 (Junit4 TearDownTestCase) committed by zorzella - Junit4 TearDownTestCase Junit4 TearDownTestCase Jun 12, 2009 r25 (JUnit 4 support embryo) committed by zorzella - JUnit 4 support embryo JUnit 4 support embryo Jun 12, 2009 r24 ('Moved' JUnitAsserts to common package, since it's not JUnit...) committed by zorzella - 'Moved' JUnitAsserts to common package, since it's not JUnit3-specific 'Moved' JUnitAsserts to common package, since it's not JUnit3-specific Jun 12, 2009 r23 (svnignore) committed by zorzella - svnignore svnignore May 06, 2009 issue 1 (Maven-ize test-libraries-for-java) Status changed by zorzella - Status: Fixed Status: Fixed May 06, 2009 r22 (Mavenized) committed by zorzella - Mavenized Mavenized May 04, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - Everything seems perfect. I'm looking at http://google-maven-repository.googlecode.com/svn/snapshot- repository/com/google/testing/test-libraries-for-java/1.1.1-SNAPSHOT/ and it seems that the build is already there and also can be accessed from other project without any problems. Well done ! Everything seems perfect. I'm looking at http://google-maven-repository.googlecode.com/svn/snapshot- repository/com/google/testing/test-libraries-for-java/1.1.1-SNAPSHOT/ and it seems that the build is already there and also can be accessed from other project without any problems. Well done ! May 04, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by zorzella - Ok, I mvn deployed successfully (I think). Please confirm that things look good, and I'll check in the pom to svn. Ok, I mvn deployed successfully (I think). Please confirm that things look good, and I'll check in the pom to svn. May 01, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - We got that error before. The error is caused by the webdav plugin - http://docs.codehaus.org/display/MAVENUSER/Deploying+3rd+Party+Jars+With+WebDAV. I think that we have two options here. 1) Install the latest version of maven 2) Ask maintainers for more information about there parent pom, because as I remember they told us to remove the webdav plugin. ************ - the wagon-webdav plugin declaration is unnecessary because it's defined in the parent ********** Now we have defined parent but it seems that it uses a different wagon plugin version. Thats why you are getting the same problem. I'm not sure that maintainers will help us on this and I think that the only way is described at 1). BTW: The current version of maven is 2.1.0. On my machine maven's version is 2.0.9 and I don't have this problem. We got that error before. The error is caused by the webdav plugin - http://docs.codehaus.org/display/MAVENUSER/Deploying+3rd+Party+Jars+With+WebDAV. I think that we have two options here. 1) Install the latest version of maven 2) Ask maintainers for more information about there parent pom, because as I remember they told us to remove the webdav plugin. ********** - the wagon-webdav plugin declaration is unnecessary because it's defined in the parent ********** Now we have defined parent but it seems that it uses a different wagon plugin version. Thats why you are getting the same problem. I'm not sure that maintainers will help us on this and I think that the only way is described at 1). BTW: The current version of maven is 2.1.0. On my machine maven's version is 2.0.9 and I don't have this problem. May 01, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by zorzella - I made one last change (deleted bogus test output dir from the eclipse section) -- see attached pom.xml. Then I tried deploy, and got an error. See if you understand this: Results : Tests run: 29, Failures: 0, Errors: 0, Skipped: 0 [INFO] [jar:jar] [INFO] [install:install] [INFO] Installing /home/zorzella/Desktop/rar/test-libraries-for-java-read-only/target/test-libraries-for-java-1.1.1-SNAPSHOT.jar to /home/zorzella/.m2/repository/com/google/testing/test-libraries-for-java/1.1.1-SNAPSHOT/test-libraries-for-java-1.1.1-SNAPSHOT.jar [INFO] [deploy:deploy] [INFO] Retrieving previous build number from google-maven-snapshot-repository [WARNING] repository metadata for: 'snapshot com.google.testing:test-libraries-for-java:1.1.1-SNAPSHOT' could not be retrieved from repository: google-maven-snapshot-repository due to an error: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav [INFO] Repository 'google-maven-snapshot-repository' will be blacklisted [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagondav. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3 seconds [INFO] Finished at: Fri May 01 14:22:42 PDT 2009 [INFO] Final Memory: 13M/217M [INFO] ------------------------------------------------------------------------ **** If you don't know what it is, I'll ask the maintainers. I made one last change (deleted bogus test output dir from the eclipse section) -- see attached pom.xml. Then I tried deploy, and got an error. See if you understand this: Results : Tests run: 29, Failures: 0, Errors: 0, Skipped: 0 [INFO] [jar:jar] [INFO] [install:install] [INFO] Installing /home/zorzella/Desktop/rar/test-libraries-for-java-read-only/target/test-libraries-for-java-1.1.1-SNAPSHOT.jar to /home/zorzella/.m2/repository/com/google/testing/test-libraries-for-java/1.1.1-SNAPSHOT/test-libraries-for-java-1.1.1-SNAPSHOT.jar [INFO] [deploy:deploy] [INFO] Retrieving previous build number from google-maven-snapshot-repository [WARNING] repository metadata for: 'snapshot com.google.testing:test-libraries-for-java:1.1.1-SNAPSHOT' could not be retrieved from repository: google-maven-snapshot-repository due to an error: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav [INFO] Repository 'google-maven-snapshot-repository' will be blacklisted [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagondav. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3 seconds [INFO] Finished at: Fri May 01 14:22:42 PDT 2009 [INFO] Final Memory: 13M/217M [INFO] ------------------------------------------------------------------------ **** If you don't know what it is, I'll ask the maintainers. May 01, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - Here is a new version of the pom with the following fixes: " You want to set that option on the eclipse plugin, _not_ the project. What you're doing here is resetting the directory for all build operations, not the plugin. <plugin> <artifactId>maven-eclipse-plugin <configuration> <outputDirectory>${basedir}/target-eclipse> " Here is a new version of the pom with the following fixes: " You want to set that option on the eclipse plugin, _not_ the project. What you're doing here is resetting the directory for all build operations, not the plugin. <plugin> <artifactId>maven-eclipse-plugin <configuration> <outputDirectory>${basedir}/target-eclipse> " May 01, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - Here is a new version of the pom with the following fixes: - spaces instead of tabs would make this a lot cleaner - why are we using 'target-eclipse' rather than the default 'target'? - the groupId on the plugins is unnecessary. org.apache.maven.plugins is the default - the wagon-webdav plugin declaration is unnecessary because it's defined in the parent - the parent is usually right under <modelVersion> Here is a new version of the pom with the following fixes: - spaces instead of tabs would make this a lot cleaner - why are we using 'target-eclipse' rather than the default 'target'? - the groupId on the plugins is unnecessary. org.apache.maven.plugins is the default - the wagon-webdav plugin declaration is unnecessary because it's defined in the parent - the parent is usually right under <modelVersion> Apr 28, 2009 r21 (src and test directories moved to src/main/java and src/test...) committed by zorzella - src and test directories moved to src/main/java and src/test/java in preparation to maven-ization src and test directories moved to src/main/java and src/test/java in preparation to maven-ization Apr 28, 2009 r20 (src and test directories moved to src/main/java and src/test...) committed by zorzella - src and test directories moved to src/main/java and src/test/java in preparation to maven-ization src and test directories moved to src/main/java and src/test/java in preparation to maven-ization Apr 28, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - About the last conversation that we had over the emails I'm attaching a new version of the pom xml which fixes the following issue: "Anyway, if there's a way for me, upon a "mvn deploy", to print a message like "Please follow directions at doc/HOW_TO_RELEASE.txt to make the release", that'd be the next best thing." All plugins regarding javadocs,sources and etc are removed now. About the last conversation that we had over the emails I'm attaching a new version of the pom xml which fixes the following issue: "Anyway, if there's a way for me, upon a "mvn deploy", to print a message like "Please follow directions at doc/HOW_TO_RELEASE.txt to make the release", that'd be the next best thing." All plugins regarding javadocs,sources and etc are removed now. Apr 28, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - Here is a new version of the pom.xml which now inherits main google's pom and also removes the unnecessary groupid's in the plugins sections. Here is a new version of the pom.xml which now inherits main google's pom and also removes the unnecessary groupid's in the plugins sections. Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - about 2) A new pom.xml which fixes and that issue. about 2) A new pom.xml which fixes and that issue. Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by zorzella - It seems that my svn privileges are not being honored by the maven repo or something. I'll try to solve this issue. Another issue I'll try to solve is how to, then, integrate with the "Download" page in my project, so I can use maven to really make a release. Hang on tight. It seems that my svn privileges are not being honored by the maven repo or something. I'll try to solve this issue. Another issue I'll try to solve is how to, then, integrate with the "Download" page in my project, so I can use maven to really make a release. Hang on tight. Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by zorzella - Stupid me, now I added a google-maven-snapshot-repository (which is what I try to deploy by default), and I get past the warning. I still have an auth failed, but a different thing altogether. Check it: [INFO] [deploy:deploy] [INFO] Retrieving previous build number from google-maven-snapshot-repository Uploading: https://google-maven-repository.googlecode.com/svn/snapshot-repository//com/google/testing/test-libraries-for-java/0.0.1-SNAPSHOT/test-libraries-for-java-0.0.1-20090421.210401-1.jar [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error deploying artifact: Authorization failed: Access denied to: https://google-maven-repository.googlecode.com/svn/snapshot-repository/com/google/testing/test-libraries-for-java/0.0.1-SNAPSHOT/test-libraries-for-java-0.0.1-20090421.210401-1.jar [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 8 seconds [INFO] Finished at: Tue Apr 21 14:04:03 PDT 2009 [INFO] Final Memory: 21M/216M [INFO] -------------------------------------------------------------------- Stupid me, now I added a google-maven-snapshot-repository (which is what I try to deploy by default), and I get past the warning. I still have an auth failed, but a different thing altogether. Check it: [INFO] [deploy:deploy] [INFO] Retrieving previous build number from google-maven-snapshot-repository Uploading: https://google-maven-repository.googlecode.com/svn/snapshot-repository//com/google/testing/test-libraries-for-java/0.0.1-SNAPSHOT/test-libraries-for-java-0.0.1-20090421.210401-1.jar [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error deploying artifact: Authorization failed: Access denied to: https://google-maven-repository.googlecode.com/svn/snapshot-repository/com/google/testing/test-libraries-for-java/0.0.1-SNAPSHOT/test-libraries-for-java-0.0.1-20090421.210401-1.jar [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 8 seconds [INFO] Finished at: Tue Apr 21 14:04:03 PDT 2009 [INFO] Final Memory: 21M/216M [INFO] -------------------------------------------------------------------- Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by zorzella - So I tried it, and I got a: [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error deploying artifact: Failed to transfer file: https://google-maven-repository.googlecode.com/svn/snapshot-repository/com/google/testing/test-libraries-for-java/0.0.1-SNAPSHOT/test-libraries-for-java-0.0.1-20090421.205728-1.jar. Return code is: 401 Unauthorized **** A little upwards I can see a warning: WARNING: No credentials available for the 'Google Code Subversion Repository' authentication realm at google-maven-repository.googlecode.com ** Googling around I found out I need a settings.xml with my username and password: http://www.nabble.com/Another-401-tt15909154.html#a15909154 http://maven.apache.org/settings.html I created one under ~/.m2 with these contents (suppressing the password): <settings> <servers> <server> <id>google-maven-repository</id> <username>zorzella</username> <password>MYPASSWORD</password> </server> </servers> </settings> Still I get the same warning and subsequent error. So I tried it, and I got a: [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error deploying artifact: Failed to transfer file: https://google-maven-repository.googlecode.com/svn/snapshot-repository/com/google/testing/test-libraries-for-java/0.0.1-SNAPSHOT/test-libraries-for-java-0.0.1-20090421.205728-1.jar. Return code is: 401 Unauthorized **** A little upwards I can see a warning: WARNING: No credentials available for the 'Google Code Subversion Repository' authentication realm at google-maven-repository.googlecode.com ** Googling around I found out I need a settings.xml with my username and password: http://www.nabble.com/Another-401-tt15909154.html#a15909154 http://maven.apache.org/settings.html I created one under ~/.m2 with these contents (suppressing the password): <settings> <servers> <server> <id>google-maven-repository</id> <username>zorzella</username> <password>MYPASSWORD</password> </server> </servers> </settings> Still I get the same warning and subsequent error. Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - My email address is: mgenov at gmail dot com. About the issue I'm attaching you the new version of the pom.xml which is defining wagon extension. It seems that in maven 2.0.9 that is not necessary ( http://docs.codehaus.org/display/MAVENUSER/Deploying+3rd+Party+Jars+With+WebDAV ), but in old version it's. I tried again on my side to execute the deploy command and my log contains the following statement: [INFO] Retrieving previous build number from google-maven-snapshot-repository 2009-4-21 23:22:39 org.apache.commons.httpclient.HttpMethodBase processAuthenticationResponse Which I can't find in the log from the previous post. Hope that this will help Added Lines <build> .. <extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-webdav</artifactId> <version>1.0-beta-2</version> </extension> </extensions> </build> My email address is: mgenov at gmail dot com. About the issue I'm attaching you the new version of the pom.xml which is defining wagon extension. It seems that in maven 2.0.9 that is not necessary ( http://docs.codehaus.org/display/MAVENUSER/Deploying+3rd+Party+Jars+With+WebDAV ), but in old version it's. I tried again on my side to execute the deploy command and my log contains the following statement: [INFO] Retrieving previous build number from google-maven-snapshot-repository 2009-4-21 23:22:39 org.apache.commons.httpclient.HttpMethodBase processAuthenticationResponse Which I can't find in the log from the previous post. Hope that this will help Added Lines <build> .. <extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-webdav</artifactId> <version>1.0-beta-2</version> </extension> </extensions> </build> Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by zorzella - I get notified of the changes to this bug, and email is my primary form of communicating, so it won't make my turnaround any faster. But if you do think it can make it more efficient for you, feel free to post your email here, and I'll reply to that. Answers below. **** $ mvn -v Maven version: 2.0.8 Java version: 1.6.0_01 OS name: "linux" version: "2.6.24-gg23-generic" arch: "i386" Family: "unix" **** This maven is a Ubuntu Hardy Heron package: $ dpkg -l maven2 Desired=Unknown/Install/Remove/Purge/Hold \| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend \|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) \|\|/ Name Version Description +++-============================-============================-======================================================================== ii maven2 2.0.8-3 Java software project management and comprehension tool I get notified of the changes to this bug, and email is my primary form of communicating, so it won't make my turnaround any faster. But if you do think it can make it more efficient for you, feel free to post your email here, and I'll reply to that. Answers below. **** $ mvn -v Maven version: 2.0.8 Java version: 1.6.0_01 OS name: "linux" version: "2.6.24-gg23-generic" arch: "i386" Family: "unix" ****** This maven is a Ubuntu Hardy Heron package: $ dpkg -l maven2 Desired=Unknown/Install/Remove/Purge/Hold \| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend \|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) \|\|/ Name Version Description +++-============================-============================-======================================================================== ii maven2 2.0.8-3 Java software project management and comprehension tool Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - About 3) I would like to get your maven version. It seems that the problem is with the wagon extension and commons-http library version that is using. btw: Can you give me some skype account,icq account or email ?. I think that will facilitate the communication. About 3) I would like to get your maven version. It seems that the problem is with the wagon extension and commons-http library version that is using. btw: Can you give me some skype account,icq account or email ?. I think that will facilitate the communication. Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by zorzella - 2) this is not a deal breaker for this tl4j lib, but we'll definitely need that for guiceberry... 3) output of mvn deploy -X added. 8) I'll try that Thanks, Z 2) this is not a deal breaker for this tl4j lib, but we'll definitely need that for guiceberry... 3) output of mvn deploy -X added. 8) I'll try that Thanks, Z Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - about 2) I don't know too. I think that with a little googling we can find the solution how to solve this issue. But currently I don't have so much time to do that. about 8). Yes it's possible. There two things that have to be done. The first one is to tell on maven to download and the sources: mvn dependency:sources. After that you are free to attach the downloaded jars with sources as a sources. ctrl + click on TestCase and then Attach Source -> from variable M2_HOME and then the extension that points to the right jar archive. btw, m2eclipse (eclipse's plugin for maven can do this automatically for you) about 3) Can you run the same command in debug mode ? (Hint: mvn deploy -X) about 2) I don't know too. I think that with a little googling we can find the solution how to solve this issue. But currently I don't have so much time to do that. about 8). Yes it's possible. There two things that have to be done. The first one is to tell on maven to download and the sources: mvn dependency:sources. After that you are free to attach the downloaded jars with sources as a sources. ctrl + click on TestCase and then Attach Source -> from variable M2_HOME and then the extension that points to the right jar archive. btw, m2eclipse (eclipse's plugin for maven can do this automatically for you) about 3) Can you run the same command in debug mode ? (Hint: mvn deploy -X) Apr 21, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by zorzella - Ok, again I apologize for the delay. 7) eclipse is a-ok with the new pom. Awesome! 2) Now (after mvn install) I see the regular jar, a source jar and a javadoc jar! Very awesome! The only thing missing is a zip/jar of the whole current cvs source tree. I was told by my friend (way back when) that there's a bona fide construct in maven to do just that (though I don't know what it is) 8) a nitpick here, if you can make it work: the eclipse-generated project should ideally link the referenced lib (junit) to its source jar, so one can use eclipse to browse, say, TestCase. I do know my current tl4j project does not do that either, but, again, I'd be awesome to take the opportunity to make it pristine. 3) mvn deploy is not working. This is pretty much the only real sticking point here before I can make this live, btw. Here's the output, I hope that helps you help me. It complains about now knowing about the dav protocol: $ mvn deploy [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building Unnamed - com.google.testing:test-libraries-for-java:jar:0.0.1-SNAPSHOT [INFO] task-segment: [deploy] [INFO] ------------------------------------------------------------------------ [...] [INFO] [deploy:deploy] [INFO] Retrieving previous build number from google-maven-snapshot-repository [WARNING] repository metadata for: 'snapshot com.google.testing:test-libraries-for-java:0.0.1-SNAPSHOT' could not be retrieved from repository: google-maven-snapshot-repository due to an error: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav [INFO] Repository 'google-maven-snapshot-repository' will be blacklisted [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagondav. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 7 seconds [INFO] Finished at: Tue Apr 21 09:56:41 PDT 2009 [INFO] Final Memory: 19M/216M [INFO] ------------------------------------------------------------------------ Ok, again I apologize for the delay. 7) eclipse is a-ok with the new pom. Awesome! 2) Now (after mvn install) I see the regular jar, a source jar and a javadoc jar! Very awesome! The only thing missing is a zip/jar of the whole current cvs source tree. I was told by my friend (way back when) that there's a bona fide construct in maven to do just that (though I don't know what it is) 8) a nitpick here, if you can make it work: the eclipse-generated project should ideally link the referenced lib (junit) to its source jar, so one can use eclipse to browse, say, TestCase. I do know my current tl4j project does not do that either, but, again, I'd be awesome to take the opportunity to make it pristine. 3) mvn deploy is not working. This is pretty much the only real sticking point here before I can make this live, btw. Here's the output, I hope that helps you help me. It complains about now knowing about the dav protocol: $ mvn deploy [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building Unnamed - com.google.testing:test-libraries-for-java:jar:0.0.1-SNAPSHOT [INFO] task-segment: [deploy] [INFO] ------------------------------------------------------------------------ [...] [INFO] [deploy:deploy] [INFO] Retrieving previous build number from google-maven-snapshot-repository [WARNING] repository metadata for: 'snapshot com.google.testing:test-libraries-for-java:0.0.1-SNAPSHOT' could not be retrieved from repository: google-maven-snapshot-repository due to an error: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav [INFO] Repository 'google-maven-snapshot-repository' will be blacklisted [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find wagon which supports the requested protocol: dav Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagondav. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 7 seconds [INFO] Finished at: Tue Apr 21 09:56:41 PDT 2009 [INFO] Final Memory: 19M/216M [INFO] ------------------------------------------------------------------------ Apr 16, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - One correction: "This will tell on maven to compile classes into that folders. If you think that it's not okay, you can change them to different ones." --> I mean eclipse classpath to point to other location. mvn eclipse:eclipse generates a new classpath file with the following content: <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="src" path="test" output="target-eclipse/test-classes"/> <classpathentry kind="output" path="target-eclipse/classes"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="var" path="M2_REPO/junit/junit/3.8.2/junit-3.8.2.jar"/> </classpath> One correction: "This will tell on maven to compile classes into that folders. If you think that it's not okay, you can change them to different ones." --> I mean eclipse classpath to point to other location. mvn eclipse:eclipse generates a new classpath file with the following content: <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="src" path="test" output="target-eclipse/test-classes"/> <classpathentry kind="output" path="target-eclipse/classes"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="var" path="M2_REPO/junit/junit/3.8.2/junit-3.8.2.jar"/> </classpath> Apr 16, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - "2) The javadoc works, good! I will try the "deploy" target later (today, hopefully), but I wanted to reiterate: I need the source jar, full zip and javadoc jars also deployed." I see. Now I'm attaching an updated version with some more configurations about that. When you type mvn deploy then maven will deploy source jar, java docs and the compiled jar to the repository. I think that it's possible and full-zip of the whole directory, but for the moment I don't have an idea how to do it. I'll spent some time on that in next two, tree days. "3) "the maven is using the standard repository to deploy the new version" What is the standard repository? What I still don't understand is: will this deploy under the googlecode project's "download" section?" My thought about standart repository was for the release repository. In our case "https://google-maven-repository.googlecode.com/svn/repository/". In the current configuration maven contains two repositories: "repository" ( this is the standard one) and "snapshotRepository". The standart "repository" is also known as release repository where all stable releases must go. The snapshot repository is for the unstable version which are currently at the development phase. "5+6) The rar you sent had some modifications to .classpath and .project, but that's irrelevant. I was bummed for a while when you said that using the generated project would require the m2eclipse plugin. But this is not the case! I generated the project, and all I had to do was set the M2_REPO variable, and all is working (no m2eclipse -- that's good!)" About that I wanna metion that probably we may have a problems with GuiceBerry, because if we want to use different modules, probably we will have to use the plugin. But for sure, we have to try it first. "7) The article seems to say the same as me: it's a bad idea to share the output. But maven is still generating the eclipse project with that dir being shared..." Yes, this is an issue, but you will do mvn clean package or mvn clean compile when you are deploying a new version of the project, after that in eclipse you can fix the problem with the classes by cleaning the project. btw, In this version of the pom.xml I've changed the output directory to: <outputDirectory>${basedir}/target-eclipse/classes</outputDirectory> <testOutputDirectory>${basedir}/target-eclipse/testclasses</testOutputDirectory> This will tell on maven to compile classes into that folders. If you think that it's not okay, you can change them to different ones. "2) The javadoc works, good! I will try the "deploy" target later (today, hopefully), but I wanted to reiterate: I need the source jar, full zip and javadoc jars also deployed." I see. Now I'm attaching an updated version with some more configurations about that. When you type mvn deploy then maven will deploy source jar, java docs and the compiled jar to the repository. I think that it's possible and full-zip of the whole directory, but for the moment I don't have an idea how to do it. I'll spent some time on that in next two, tree days. "3) "the maven is using the standard repository to deploy the new version" What is the standard repository? What I still don't understand is: will this deploy under the googlecode project's "download" section?" My thought about standart repository was for the release repository. In our case "https://google-maven-repository.googlecode.com/svn/repository/". In the current configuration maven contains two repositories: "repository" ( this is the standard one) and "snapshotRepository". The standart "repository" is also known as release repository where all stable releases must go. The snapshot repository is for the unstable version which are currently at the development phase. "5+6) The rar you sent had some modifications to .classpath and .project, but that's irrelevant. I was bummed for a while when you said that using the generated project would require the m2eclipse plugin. But this is not the case! I generated the project, and all I had to do was set the M2_REPO variable, and all is working (no m2eclipse -- that's good!)" About that I wanna metion that probably we may have a problems with GuiceBerry, because if we want to use different modules, probably we will have to use the plugin. But for sure, we have to try it first. "7) The article seems to say the same as me: it's a bad idea to share the output. But maven is still generating the eclipse project with that dir being shared..." Yes, this is an issue, but you will do mvn clean package or mvn clean compile when you are deploying a new version of the project, after that in eclipse you can fix the problem with the classes by cleaning the project. btw, In this version of the pom.xml I've changed the output directory to: <outputDirectory>${basedir}/target-eclipse/classes</outputDirectory> <testOutputDirectory>${basedir}/target-eclipse/testclasses</testOutputDirectory> This will tell on maven to compile classes into that folders. If you think that it's not okay, you can change them to different ones. Apr 16, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by zorzella - 2) The javadoc works, good! I will try the "deploy" target later (today, hopefully), but I wanted to reiterate: I need the source jar, full zip and javadoc jars also deployed. 3) "the maven is using the standard repository to deploy the new version" What is the standard repository? What I still don't understand is: will this deploy under the googlecode project's "download" section? 4) It's ok, just wanted to understand how to get it from here to there. 5+6) The rar you sent had some modifications to .classpath and .project, but that's irrelevant. I was bummed for a while when you said that using the generated project would require the m2eclipse plugin. But this is not the case! I generated the project, and all I had to do was set the M2_REPO variable, and all is working (no m2eclipse -- that's good!) 7) The article seems to say the same as me: it's a bad idea to share the output. But maven is still generating the eclipse project with that dir being shared... 2) The javadoc works, good! I will try the "deploy" target later (today, hopefully), but I wanted to reiterate: I need the source jar, full zip and javadoc jars also deployed. 3) "the maven is using the standard repository to deploy the new version" What is the standard repository? What I still don't understand is: will this deploy under the googlecode project's "download" section? 4) It's ok, just wanted to understand how to get it from here to there. 5+6) The rar you sent had some modifications to .classpath and .project, but that's irrelevant. I was bummed for a while when you said that using the generated project would require the m2eclipse plugin. But this is not the case! I generated the project, and all I had to do was set the M2_REPO variable, and all is working (no m2eclipse -- that's good!) 7) The article seems to say the same as me: it's a bad idea to share the output. But maven is still generating the eclipse project with that dir being shared... Apr 16, 2009 issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - "2) I issued a "mvn install" command (not sure this is the correct one), and it generated one jar output: test-libraries-for-java-0.0.1-SNAPSHOT.jar. Ok, but if you compare to the current "ant dist" target, I also generate a source jar, and a full source tree zip. I also just realized I'm not generating a javadoc jar, which I think we should (ouch). But at least I generate the javadocs, which I can't find under your maven project." To generate a javadoc files, you can execute: mvn javadoc:javadoc. The result of the exection will be at target/site/apidocs/. More information about javadoc plugin can be taken from the following url: http://maven.apache.org/plugins/maven-javadoc- plugin/ "3) This 0.0.1-SNAPSHOT number is, of course, bogus. With ant, I've been using a "version=" property under build.properties. I have no problem using a different mechanism, but I need some guidance here." In pom.xml there is a line <version>0.0.1-SNAPSHOT</version>. Here I want to note that this version will be uploaded to the repository and if anyone wants to use this library, has to add dependency to: groupId:com.google.testing, artifactId:test- libraries-for-java, version: 0.0.1-SNAPSHOT and a scope (test, provided) which is not necessary. The last part of the version, i.e "-SNAPSHOT" is recognized by maven and it places it in the snapshot repository. In our case - https://google-maven- repository.googlecode.com/svn/snapshot-repository/. If that keyword does not exists, then, the maven is using the standard repository to deploy the new version. "4) If I get this right, we should be also deleting the files "build.xml" and "build.properties", right?" Yes, I left them in the archive, because they can help in somehow. But if you want to remove them, it's okay for me. "5) The .classpath and .project: are these generated by maven?" No, these are the original ones. To generate an eclipse project, please type: mvn eclipse:eclipse and maven will generate these files for you and you can import the new project in eclipse or to refresh the existing one (the command will replace the existing project configuration). Please note that if you are using eclipse, then you have to install m2eclipse plugin to enable maven support in your IDE. "6) I imported the project in Eclipse, and that does not seem to be working! It can't find any of the needed JUnit classes. " Please, check point 5. "7) the .classpath points the output to "target/classes", which seems to be the output of the classes compiled by maven from "src". This is wrong -- it should point to its own "eclipse-bin" directory (otherwise, it will, for example, put test classes in that output directory, causing maven to mispackage them as source classes)." Please, check the following article about this issue: http://docs.codehaus.org/display/M2ECLIPSE/Separate+Eclipse+and+Maven+output+folders Hope this information will help you. "2) I issued a "mvn install" command (not sure this is the correct one), and it generated one jar output: test-libraries-for-java-0.0.1-SNAPSHOT.jar. Ok, but if you compare to the current "ant dist" target, I also generate a source jar, and a full source tree zip. I also just realized I'm not generating a javadoc jar, which I think we should (ouch). But at least I generate the javadocs, which I can't find under your maven project." To generate a javadoc files, you can execute: mvn javadoc:javadoc. The result of the exection will be at target/site/apidocs/. More information about javadoc plugin can be taken from the following url: http://maven.apache.org/plugins/maven-javadoc- plugin/ "3) This 0.0.1-SNAPSHOT number is, of course, bogus. With ant, I've been using a "version=" property under build.properties. I have no problem using a different mechanism, but I need some guidance here." In pom.xml there is a line <version>0.0.1-SNAPSHOT</version>. Here I want to note that this version will be uploaded to the repository and if anyone wants to use this library, has to add dependency to: groupId:com.google.testing, artifactId:test- libraries-for-java, version: 0.0.1-SNAPSHOT and a scope (test, provided) which is not necessary. The last part of the version, i.e "-SNAPSHOT" is recognized by maven and it places it in the snapshot repository. In our case - https://google-maven- repository.googlecode.com/svn/snapshot-repository/. If that keyword does not exists, then, the maven is using the standard repository to deploy the new version. "4) If I get this right, we should be also deleting the files "build.xml" and "build.properties", right?" Yes, I left them in the archive, because they can help in somehow. But if you want to remove them, it's okay for me. "5) The .classpath and .project: are these generated by maven?" No, these are the original ones. To generate an eclipse project, please type: mvn eclipse:eclipse and maven will generate these files for you and you can import the new project in eclipse or to refresh the existing one (the command will replace the existing project configuration). Please note that if you are using eclipse, then you have to install m2eclipse plugin to enable maven support in your IDE. "6) I imported the project in Eclipse, and that does not seem to be working! It can't find any of the needed JUnit classes. " Please, check point 5. "7) the .classpath points the output to "target/classes", which seems to be the output of the classes compiled by maven from "src". This is wrong -- it should point to its own "eclipse-bin" directory (otherwise, it will, for example, put test classes in that output directory, causing maven to mispackage them as source classes)." Please, check the following article about this issue: http://docs.codehaus.org/display/M2ECLIPSE/Separate+Eclipse+and+Maven+output+folders Hope this information will help you.

issue 1 (Maven-ize test-libraries-for-java) commented on by MGenov - "2) I issued a "mvn install" command (not sure this is the correct one), and it generated one jar output: test-libraries-for-java-0.0.1-SNAPSHOT.jar. Ok, but if you compare to the current "ant dist" target, I also generate a source jar, and a full source tree zip. I also just realized I'm not generating a javadoc jar, which I think we should (ouch). But at least I generate the javadocs, which I can't find under your maven project." To generate a javadoc files, you can execute: mvn javadoc:javadoc. The result of the exection will be at target/site/apidocs/. More information about javadoc plugin can be taken from the following url: http://maven.apache.org/plugins/maven-javadoc- plugin/ "3) This 0.0.1-SNAPSHOT number is, of course, bogus. With ant, I've been using a "version=" property under build.properties. I have no problem using a different mechanism, but I need some guidance here." In pom.xml there is a line <version>0.0.1-SNAPSHOT</version>. Here I want to note that this version will be uploaded to the repository and if anyone wants to use this library, has to add dependency to: groupId:com.google.testing, artifactId:test- libraries-for-java, version: 0.0.1-SNAPSHOT and a scope (test, provided) which is not necessary. The last part of the version, i.e "-SNAPSHOT" is recognized by maven and it places it in the snapshot repository. In our case - https://google-maven- repository.googlecode.com/svn/snapshot-repository/. If that keyword does not exists, then, the maven is using the standard repository to deploy the new version. "4) If I get this right, we should be also deleting the files "build.xml" and "build.properties", right?" Yes, I left them in the archive, because they can help in somehow. But if you want to remove them, it's okay for me. "5) The .classpath and .project: are these generated by maven?" No, these are the original ones. To generate an eclipse project, please type: mvn eclipse:eclipse and maven will generate these files for you and you can import the new project in eclipse or to refresh the existing one (the command will replace the existing project configuration). Please note that if you are using eclipse, then you have to install m2eclipse plugin to enable maven support in your IDE. "6) I imported the project in Eclipse, and that does not seem to be working! It can't find any of the needed JUnit classes. " Please, check point 5. "7) the .classpath points the output to "target/classes", which seems to be the output of the classes compiled by maven from "src". This is wrong -- it should point to its own "eclipse-bin" directory (otherwise, it will, for example, put test classes in that output directory, causing maven to mispackage them as source classes)." Please, check the following article about this issue: http://docs.codehaus.org/display/M2ECLIPSE/Separate+Eclipse+and+Maven+output+folders Hope this information will help you.

"2) I issued a "mvn install" command (not sure this is the correct one), and it generated one jar output: test-libraries-for-java-0.0.1-SNAPSHOT.jar. Ok, but if you compare to the current "ant dist" target, I also generate a source jar, and a full source tree zip. I also just realized I'm not generating a javadoc jar, which I think we should (ouch). But at least I generate the javadocs, which I can't find under your maven project." To generate a javadoc files, you can execute: mvn javadoc:javadoc. The result of the exection will be at target/site/apidocs/. More information about javadoc plugin can be taken from the following url: http://maven.apache.org/plugins/maven-javadoc- plugin/ "3) This 0.0.1-SNAPSHOT number is, of course, bogus. With ant, I've been using a "version=" property under build.properties. I have no problem using a different mechanism, but I need some guidance here." In pom.xml there is a line <version>0.0.1-SNAPSHOT</version>. Here I want to note that this version will be uploaded to the repository and if anyone wants to use this library, has to add dependency to: groupId:com.google.testing, artifactId:test- libraries-for-java, version: 0.0.1-SNAPSHOT and a scope (test, provided) which is not necessary. The last part of the version, i.e "-SNAPSHOT" is recognized by maven and it places it in the snapshot repository. In our case - https://google-maven- repository.googlecode.com/svn/snapshot-repository/. If that keyword does not exists, then, the maven is using the standard repository to deploy the new version. "4) If I get this right, we should be also deleting the files "build.xml" and "build.properties", right?" Yes, I left them in the archive, because they can help in somehow. But if you want to remove them, it's okay for me. "5) The .classpath and .project: are these generated by maven?" No, these are the original ones. To generate an eclipse project, please type: mvn eclipse:eclipse and maven will generate these files for you and you can import the new project in eclipse or to refresh the existing one (the command will replace the existing project configuration). Please note that if you are using eclipse, then you have to install m2eclipse plugin to enable maven support in your IDE. "6) I imported the project in Eclipse, and that does not seem to be working! It can't find any of the needed JUnit classes. " Please, check point 5. "7) the .classpath points the output to "target/classes", which seems to be the output of the classes compiled by maven from "src". This is wrong -- it should point to its own "eclipse-bin" directory (otherwise, it will, for example, put test classes in that output directory, causing maven to mispackage them as source classes)." Please, check the following article about this issue: http://docs.codehaus.org/display/M2ECLIPSE/Separate+Eclipse+and+Maven+output+folders Hope this information will help you.

Today

Older