zorzella / test-libraries-for-java

Automatically exported from code.google.com/p/test-libraries-for-java
Apache License 2.0
0 stars 0 forks source link

Maven-ize test-libraries-for-java #1

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Is there any chance test-libraries-for-java to be mavenized ? 

It would be really nice if test-libraries-for-java can be used as a maven 
artifact by any other maven projects.

Original issue reported on code.google.com by MGe...@gmail.com on 4 Apr 2009 at 5:54

GoogleCodeExporter commented 8 years ago
Here is a draft version of the current version of the project with a maven 
project 
file. 

Please note that the maven module does not currently has an ability to be 
deployed on 
a remote repository. Currently I found the following project 
http://code.google.com/p/google-apis-mavenized/ that is providing such 
infrastructure, but I'm not sure how it's working. Probably we have to contact 
the 
owner of the project and to ask him for information how to do this.

Original comment by MGe...@gmail.com on 4 Apr 2009 at 6:42

Attachments:

GoogleCodeExporter commented 8 years ago
I'll take a look at your draft in the next few days. 

The "remote deploy" you talk about is to upload new releases to googlecode, 
right? If
so, this is *the most* compelling reason (for me) to buy into the maven-ized 
build.
It would be great if you can try to make it work.

Thanks,

Z

Original comment by zorze...@gmail.com on 4 Apr 2009 at 7:28

GoogleCodeExporter commented 8 years ago
"The "remote deploy" you talk about is to upload new releases to googlecode, 
right?"

Yes, That is what I mean. 

You are right, it is some kind useless if the dependencies management is not 
working. 
I'll search for an way to do it, but I can't promise that this can be done soon.

Original comment by MGe...@gmail.com on 4 Apr 2009 at 8:03

GoogleCodeExporter commented 8 years ago
I think that I found some example how to do it: 

 <distributionManagement>
    <repository>
      <id>google-maven-repository</id>
      <name>Google Maven Repository</name>
      <url>dav:https://google-maven-repository.googlecode.com/svn/repository/</url>
    </repository>
    <snapshotRepository>
      <id>google-maven-snapshot-repository</id>
      <name>Google Maven Snapshot Repository</name>
      <url>dav:https://google-maven-repository.googlecode.com/svn/snapshot-
repository/</url>
      <uniqueVersion>true</uniqueVersion>
    </snapshotRepository>
  </distributionManagement>

The only think that we have to do is to get an access to the repository. It 
would be 
nice if you could try to log with your google project account. Try opening: 
https://google-maven-repository.googlecode.com/svn/repository/ 
and enter your project account. I'm mostly sure that will not work, but we have 
to 
try :)

If the attempt is not successful then we have to ask the project owner to give 
us a 
write access to that repository and then we may upload new releases to that 
repository. 

btw, About the correspondence between guys from Google I'm not sure that I'm 
the 
right person, probably your team friends or maybe you ( if you work for google 
) can 
help much more then I.

Original comment by MGe...@gmail.com on 4 Apr 2009 at 8:18

GoogleCodeExporter commented 8 years ago
I'm really sorry it took my 11 days to reply -- I got swamped here. I tried the 
link,
and with my username + my googlecode password I managed to get to the SVN web
interface (i.e. it seems to work just fine).

While I look at your rar, would you make the changes to incorporate this 
feature?
I'll be talking to the other parties (devs) involved here.

Original comment by zorze...@gmail.com on 16 Apr 2009 at 4:45

GoogleCodeExporter commented 8 years ago
Ok, I've got questions and comments, now. Pardon my lack of maven knowhow here, 
if
that be the case:

1) good, the only "major" change in project structure I see is the "build" 
directory
is now "target", which is a very acceptable change to me.

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.

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.

4) If I get this right, we should be also deleting the files "build.xml" and
"build.properties", right?

5) The .classpath and .project: are these generated by maven? 

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. 

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).

Original comment by zorze...@gmail.com on 16 Apr 2009 at 5:24

GoogleCodeExporter commented 8 years ago
Hello again :)
  I'm attaching the completed application with fully configuration and also my maven 
settings.xml (located at user_home/.m2/) that contains information about the 
user 
credentials. I tried to test the configuration on my side and it seems that is 
working exception the part with the credentials. This is the message that I'm 
getting 
when I type: mvn deploy -X (where -X is for debug):

org.apache.maven.lifecycle.LifecycleExecutionException: Error retrieving 
previous 
build number for artifact 'com.google.testing:test-libraries-for-java:jar': 
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: Authorization failed: Not authorized.

Please test it on your side, and if there are some problems, do not hesitate to 
contact me.

Original comment by MGe...@gmail.com on 16 Apr 2009 at 5:41

Attachments:

GoogleCodeExporter commented 8 years ago
"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+fol
ders

Hope this information will help you.

Original comment by MGe...@gmail.com on 16 Apr 2009 at 6:09

Attachments:

GoogleCodeExporter commented 8 years ago
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...

Original comment by zorze...@gmail.com on 16 Apr 2009 at 6:36

GoogleCodeExporter commented 8 years ago
"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. 

Original comment by MGe...@gmail.com on 16 Apr 2009 at 7:23

Attachments:

GoogleCodeExporter commented 8 years ago
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>

Original comment by MGe...@gmail.com on 16 Apr 2009 at 8:16

GoogleCodeExporter commented 8 years ago
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] ------------------------------------------------------------------------

Original comment by zorze...@gmail.com on 21 Apr 2009 at 4:57

GoogleCodeExporter commented 8 years ago
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)

Original comment by MGe...@gmail.com on 21 Apr 2009 at 6:31

GoogleCodeExporter commented 8 years ago
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

Original comment by zorze...@gmail.com on 21 Apr 2009 at 7:46

Attachments:

GoogleCodeExporter commented 8 years ago
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.

Original comment by MGe...@gmail.com on 21 Apr 2009 at 8:09

GoogleCodeExporter commented 8 years ago
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

Original comment by zorze...@gmail.com on 21 Apr 2009 at 8:23

GoogleCodeExporter commented 8 years ago
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>

Original comment by MGe...@gmail.com on 21 Apr 2009 at 8:39

Attachments:

GoogleCodeExporter commented 8 years ago
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/googl
e/testing/test-libraries-for-java/0.0.1-SNAPSHOT/test-libraries-for-java-0.0.1-2
0090421.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.

Original comment by zorze...@gmail.com on 21 Apr 2009 at 9:02

GoogleCodeExporter commented 8 years ago
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/goog
le/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/googl
e/testing/test-libraries-for-java/0.0.1-SNAPSHOT/test-libraries-for-java-0.0.1-2
0090421.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] --------------------------------------------------------------------

Original comment by zorze...@gmail.com on 21 Apr 2009 at 9:06

GoogleCodeExporter commented 8 years ago
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.

Original comment by zorze...@gmail.com on 21 Apr 2009 at 9:18

GoogleCodeExporter commented 8 years ago
about 2) A new pom.xml which fixes and that issue.

Original comment by MGe...@gmail.com on 21 Apr 2009 at 9:24

Attachments:

GoogleCodeExporter commented 8 years ago
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.

Original comment by MGe...@gmail.com on 28 Apr 2009 at 5:34

Attachments:

GoogleCodeExporter commented 8 years ago
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.

Original comment by MGe...@gmail.com on 28 Apr 2009 at 9:13

Attachments:

GoogleCodeExporter commented 8 years ago
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>

Original comment by MGe...@gmail.com on 1 May 2009 at 6:37

Attachments:

GoogleCodeExporter commented 8 years ago
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>
"

Original comment by MGe...@gmail.com on 1 May 2009 at 8:19

Attachments:

GoogleCodeExporter commented 8 years ago
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-librari
es-for-java-1.1.1-SNAPSHOT.jar
to
/home/zorzella/.m2/repository/com/google/testing/test-libraries-for-java/1.1.1-S
NAPSHOT/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.

Original comment by zorze...@gmail.com on 1 May 2009 at 9:26

Attachments:

GoogleCodeExporter commented 8 years ago
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.

Original comment by MGe...@gmail.com on 1 May 2009 at 9:52

GoogleCodeExporter commented 8 years ago
Ok, I mvn deployed successfully (I think). Please confirm that things look 
good, and
I'll check in the pom to svn.

Original comment by zorze...@gmail.com on 4 May 2009 at 6:21

GoogleCodeExporter commented 8 years ago
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 !

Original comment by MGe...@gmail.com on 4 May 2009 at 8:55

GoogleCodeExporter commented 8 years ago

Original comment by zorze...@gmail.com on 6 May 2009 at 8:56