Re: Deploying artifacts: 0 byte files
Just wanted to update where I stand on this issue. I switched over to using sftp instead of scp and it seems to be working much more reliably. Thanks for everyone's input. -wr [EMAIL PROTECTED] on 09/28/2004 01:45:17 AM Please respond to Maven Users List [EMAIL PROTECTED] To:Maven Users List [EMAIL PROTECTED] cc: (bcc: Winston Rast/Jeppesen/TMC) Subject:Re: Deploying artifacts: 0 byte files (Embedded image moved to file: pic29358.jpg) This sound like my Problem with dependancies where snapshot are download with 0K if they are all ready present on my local repo. Unfurtunatlety no body answer me. I am curious to see if your -X trace is same as mine : Getting URL: http://arsodev1:8080/maven-repo/arsoe-socle/jars/socle-util-1.2-SNAPSHOT.jar sending == If-Modified-Since: mer., 15-sept.-04 16:24:26 GMT (1095265466000) Received status code: 200 warning: last-modified not specified 0K downloaded Local timestamp: 1095265466000 Remote timestamp: 0 Nicolas Carlos Sanchez [EMAIL PROTECTED] 28/09/2004 01:16 Veuillez répondre à Maven Users List Pour : 'Maven Users List' [EMAIL PROTECTED] cc : Objet : RE: Deploying artifacts: 0 byte files -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 28, 2004 12:38 AM To: Maven Users List Subject: RE: Deploying artifacts: 0 byte files I should probably elaborate more... None of the 0-byte files are symlinks. In addition to the original problem, sometimes the build will say that the artifact has been deployed, but when I go to check the repository, it's not there. I can recall at one point it would take us several builds to get the artifact to show up that first time. Now it seems that sometimes the artifact appears, sometimes it doesn't, and sometimes when it does show up, it's 0 bytes. This really causes lots of issues later as other projects try to get the artifact as a dependency only to get a ZipException because of the file size. That sounds really extrange and it's the first time I hear something like that I will try to delete everything as you suggest to see if that fixes anything. Perhaps there's a way to add a postGoal to maven's deployment process to check the file size after it's done to validate that it got there already? Should this be done by maven out of the box? It's being done in next versions. -wr Carlos Sanchez [EMAIL PROTECTED] on 09/27/2004 04:25:34 PM Please respond to Maven Users List [EMAIL PROTECTED] To:'Maven Users List' [EMAIL PROTECTED] cc: (bcc: Winston Rast/Jeppesen/TMC) Subject:RE: Deploying artifacts: 0 byte files (Embedded image moved to file: pic04827.jpg) Hi, Maybe those snapshots are symlinks created with versions previous to 1.0? Try the universal solution: Delete them and deploy again. Regards Carlos Sanchez A Coruña, Spain http://www.jroller.com/page/carlossg/Weblog Oness Project http://oness.sourceforge.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 28, 2004 12:20 AM To: [EMAIL PROTECTED] Subject: Deploying artifacts: 0 byte files We have an issue with maven's handling of artifact deployment to our remote repository. Sometimes (not always), when a new snapshot artifact is generated it doesn't get completely written to the remote repository. The size is 0 bytes. We are using the scp:// protocol. The origin machine is solaris and the destination box is linux. Anyone have thoughts on this or experienced it before? This has been very problematic in our environment because other team members depend on the snapshot artifact almost as soon as it's generated. Thanks. -wr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploying artifacts: 0 byte files
I am running v1.0. To follow up with Carlos' suggestion of deleting everything in my repository...it seems (so far) I have had a degree of success. I have yet to see a 0 byte file show up. However, I do see some inconsistency in the behavior of the deployment. Namely, I have one project that deploys a set of files like this: name-timestamp.jar name-timestamp.jar.md5 name-SNAPSHOT.jar name-SNAPSHOT.jar.md5 name-snapshot-version And yet another project that does the exact same deployment only has this set of files: name-timestamp.jar name-SNAPSHOT.jar name-SNAPSHOT.jar.md5 Why the difference? It is as if some of the commands being run remotely are unsuccessful. The build results don't reflect any such failure. As I said things seem ok for now after deleting a bunch of the repo's files, but I have a hunch bad things will be happening here in the next day or two. -wr Jefferson K. French [EMAIL PROTECTED] on 09/27/2004 05:16:58 PM Please respond to Maven Users List [EMAIL PROTECTED]; Please respond to [EMAIL PROTECTED] To:Maven Users List [EMAIL PROTECTED] cc: (bcc: Winston Rast/Jeppesen/TMC) Subject:Re: Deploying artifacts: 0 byte files (Embedded image moved to file: pic19912.jpg) What version of Maven are you running? I remember something similar happening to me (although Linux to Linux), a while back, but I have not had a problem since v1.0. On Mon, 27 Sep 2004, at 16:37:57 [GMT -0600] [EMAIL PROTECTED] wrote: I should probably elaborate more... None of the 0-byte files are symlinks. In addition to the original problem, sometimes the build will say that the artifact has been deployed, but when I go to check the repository, it's not there. I can recall at one point it would take us several builds to get the artifact to show up that first time. Now it seems that sometimes the artifact appears, sometimes it doesn't, and sometimes when it does show up, it's 0 bytes. This really causes lots of issues later as other projects try to get the artifact as a dependency only to get a ZipException because of the file size. I will try to delete everything as you suggest to see if that fixes anything. Perhaps there's a way to add a postGoal to maven's deployment process to check the file size after it's done to validate that it got there already? Should this be done by maven out of the box? -- mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deploying artifacts: 0 byte files
We have an issue with maven's handling of artifact deployment to our remote repository. Sometimes (not always), when a new snapshot artifact is generated it doesn't get completely written to the remote repository. The size is 0 bytes. We are using the scp:// protocol. The origin machine is solaris and the destination box is linux. Anyone have thoughts on this or experienced it before? This has been very problematic in our environment because other team members depend on the snapshot artifact almost as soon as it's generated. Thanks. -wr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deploying artifacts: 0 byte files
I should probably elaborate more... None of the 0-byte files are symlinks. In addition to the original problem, sometimes the build will say that the artifact has been deployed, but when I go to check the repository, it's not there. I can recall at one point it would take us several builds to get the artifact to show up that first time. Now it seems that sometimes the artifact appears, sometimes it doesn't, and sometimes when it does show up, it's 0 bytes. This really causes lots of issues later as other projects try to get the artifact as a dependency only to get a ZipException because of the file size. I will try to delete everything as you suggest to see if that fixes anything. Perhaps there's a way to add a postGoal to maven's deployment process to check the file size after it's done to validate that it got there already? Should this be done by maven out of the box? -wr Carlos Sanchez [EMAIL PROTECTED] on 09/27/2004 04:25:34 PM Please respond to Maven Users List [EMAIL PROTECTED] To:'Maven Users List' [EMAIL PROTECTED] cc: (bcc: Winston Rast/Jeppesen/TMC) Subject:RE: Deploying artifacts: 0 byte files (Embedded image moved to file: pic04827.jpg) Hi, Maybe those snapshots are symlinks created with versions previous to 1.0? Try the universal solution: Delete them and deploy again. Regards Carlos Sanchez A Coruña, Spain http://www.jroller.com/page/carlossg/Weblog Oness Project http://oness.sourceforge.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 28, 2004 12:20 AM To: [EMAIL PROTECTED] Subject: Deploying artifacts: 0 byte files We have an issue with maven's handling of artifact deployment to our remote repository. Sometimes (not always), when a new snapshot artifact is generated it doesn't get completely written to the remote repository. The size is 0 bytes. We are using the scp:// protocol. The origin machine is solaris and the destination box is linux. Anyone have thoughts on this or experienced it before? This has been very problematic in our environment because other team members depend on the snapshot artifact almost as soon as it's generated. Thanks. -wr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-proxy configuration
Anyone? Surely people have tackled this problem before. Anyone have example configurations they'd like to share that have proper snapshot handling? -wr [EMAIL PROTECTED] on 09/15/2004 11:09:11 AM Please respond to Maven Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Winston Rast/Jeppesen/TMC) Subject: maven-proxy configuration I'm having some serious problems trying to configure maven-proxy the way I want. I have a private remote repository the developers share. It contains snapshots of numerous projects under development. We are trying to eliminate ibiblio as a remote repository as well. I have configured maven-proxy on the same machine as our private remote repo. It's download directory currently points directly to our private remote repo location. My problem lies in the fact that regardless of how I seem to configure maven-proxy, it always wants to go and look at ibiblio for our projects' snapshots. What I want to do is have maven-proxy NOT look at external remote repositories for snapshots but everything else (real, versioned artifacts) *should* look at them. Surely this has been tackled before. Hopefully someone has some ideas on this subject. I am using the SNAPSHOT version of maven-proxy along with the snapshot configuration example currently available. Thanks. -wr __ NOTICE: This communication and any files transmitted with it (communication) may contain privileged or other confidential information. This communication is intended solely for the individual or entity to whom it is addressed. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use this communication. Also, please indicate to the sender that you have received this communication in error, and then delete this communication and any copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-proxy configuration
I'm having some serious problems trying to configure maven-proxy the way I want. I have a private remote repository the developers share. It contains snapshots of numerous projects under development. We are trying to eliminate ibiblio as a remote repository as well. I have configured maven-proxy on the same machine as our private remote repo. It's download directory currently points directly to our private remote repo location. My problem lies in the fact that regardless of how I seem to configure maven-proxy, it always wants to go and look at ibiblio for our projects' snapshots. What I want to do is have maven-proxy NOT look at external remote repositories for snapshots but everything else (real, versioned artifacts) *should* look at them. Surely this has been tackled before. Hopefully someone has some ideas on this subject. I am using the SNAPSHOT version of maven-proxy along with the snapshot configuration example currently available. Thanks. -wr __ NOTICE: This communication and any files transmitted with it (communication) may contain privileged or other confidential information. This communication is intended solely for the individual or entity to whom it is addressed. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use this communication. Also, please indicate to the sender that you have received this communication in error, and then delete this communication and any copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: Weblogic plugin
Siegfried, would you mind making your plugin generally available? If that's not possible I'd love to get a copy! -wr Göschl,Siegfried [EMAIL PROTECTED] on 06/28/2004 10:23:36 AM Please respond to Maven Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Winston Rast/Jeppesen/TMC) Subject: FW: Weblogic plugin Sorry folks, I just love to post success stories ... :-) Cheers, Siegfried Goeschl -Original Message- From: Shon Schetnan [mailto:[EMAIL PROTECTED] Sent: Montag, 28. Juni 2004 18:16 To: Göschl,Siegfried Subject: Weblogic plugin Siegfried, I just dropped your plugin into my maven plugins directory, setup the properties, and it works like a charm! Thanks much for your work! Shon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RC3 Property Inheritance Problem
Thanks Brett. I followed my mistakenly missing attachment with another post but for some reason it never made it to the list. I created MAVEN-1296 in JIRa for the issue. Hope you can get the chance to look at this as it is pretty important in my view. -wr Brett Porter [EMAIL PROTECTED] on 05/26/2004 05:08:56 PM Please respond to Maven Users List [EMAIL PROTECTED] To: 'Maven Users List' [EMAIL PROTECTED] cc:(bcc: Winston Rast/Jeppesen/TMC) Subject: RE: RC3 Property Inheritance Problem Attachement is not there. Can you post the contents of your message to JIRA and attach the example? Thanks, Brett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, 27 May 2004 7:36 AM To: [EMAIL PROTECTED] Subject: Re: RC3 Property Inheritance Problem I've been doing a lot of trial and error with this problem and I've narrowed it down to what I think is a problem in multiproject environments with inherited properties. It is *not* an issue strictly with the maven.compile.* properties as I've previously mentioned. I'm attaching a jar file of my stripped down example to demonstrate. In my example, I'm demonstrating the problem with the maven.repo.remote property. To replicate the problem, do the following: * Edit project.properties under test/ and change maven.repo.remote to something other than ibiblio. * Edit test/service/myservice/ejb/project.xml with a dependency (something NOT on ibiblio, but on the remote repo specified previously) * Remove this dependent jar from your local repository so it's forced to download it again * From test/service/myservice, execute a maven goal (I generally do clean) This should fail to download. Strangely, if I run the same maven goal from test/service/myservice/ejb, it DOES download! Anyone have a clue what's happening here? -wr __ NOTICE: This communication and any files transmitted with it (communication) may contain privileged or other confidential information. This communication is intended solely for the individual or entity to whom it is addressed. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use this communication. Also, please indicate to the sender that you have received this communication in error, and then delete this communication and any copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue with incomplete plugin downloads
I have seen this behavior as well. It would be nice if it was transactional. -wr Carlos Sanchez [EMAIL PROTECTED] on 05/27/2004 08:50:56 AM Please respond to Maven Users List [EMAIL PROTECTED] To: 'Maven Users List' [EMAIL PROTECTED] cc:(bcc: Winston Rast/Jeppesen/TMC) Subject: Issue with incomplete plugin downloads Hi, When a plugin download is incomplete the partial file is kept in local repository. Next time maven is run it will try to uncompress the plugin, getting a java.io.EOFException: Unexpected end of ZLIB input stream, which is logical. When you try to download again it is not downloaded, instead the incomplete file is got from local repository and must be manually removed. Is this a known issue? You can try with maven plugin:download -DartifactId=maven-xdoclet-plugin -DgroupId=xdoclet -Dversion=1.2 And hit Ctrl-Break while downloading Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RC3 Property Inheritance Problem
The properties are defined in only a single place. Would it help if I posted all of my properties files? If I put these properties in my root/project.properties, it all works, which is confusing to me. -wr Brett Porter [EMAIL PROTECTED] on 05/25/2004 05:18:00 PM Please respond to Maven Users List [EMAIL PROTECTED] To: 'Maven Users List' [EMAIL PROTECTED] cc:(bcc: Winston Rast/Jeppesen/TMC) Subject: RE: RC3 Property Inheritance Problem Do any of the plugins you use (eg the xdoclet one) override the values? - Brett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 May 2004 3:56 AM To: Maven Users List Subject: Re: RC3 Property Inheritance Problem Just to follow up with some more info that I discovered... I created a root/maven.xml to echo the maven.compile.* properties during the build. Somewhere along the way my property values are being lost: build: [echo] maven.compile.source=1.4 [echo] maven.compile.target=1.4 multiproject:install: multiproject:projects-init: [echo] Gathering project list Starting the reactor... snip xdoclet:ejbdoclet: java:prepare-filesystem: java:compile: [echo] maven.compile.source=1.3 [echo] maven.compile.target=1.1 So is the problem in the property inheritance, the java plugin, or the multiproject plugin? Your help is greatly appreciated. -wr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RC3 Property Inheritance Problem
I've been doing a lot of trial and error with this problem and I've narrowed it down to what I think is a problem in multiproject environments with inherited properties. It is *not* an issue strictly with the maven.compile.* properties as I've previously mentioned. I'm attaching a jar file of my stripped down example to demonstrate. In my example, I'm demonstrating the problem with the maven.repo.remote property. To replicate the problem, do the following: * Edit project.properties under test/ and change maven.repo.remote to something other than ibiblio. * Edit test/service/myservice/ejb/project.xml with a dependency (something NOT on ibiblio, but on the remote repo specified previously) * Remove this dependent jar from your local repository so it's forced to download it again * From test/service/myservice, execute a maven goal (I generally do clean) This should fail to download. Strangely, if I run the same maven goal from test/service/myservice/ejb, it DOES download! Anyone have a clue what's happening here? -wr __ NOTICE: This communication and any files transmitted with it (communication) may contain privileged or other confidential information. This communication is intended solely for the individual or entity to whom it is addressed. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use this communication. Also, please indicate to the sender that you have received this communication in error, and then delete this communication and any copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RC3 Property Inheritance Problem
I'm trying to generate 1.4 friendly compiled classes. I'm getting failures on the assert keyword. Here's a rundown of my multiproject structure: root/ project.xml (extends root/service/project.xml) project.ent common/ maven/ project.properties project.xml (Parent) entities/ versions.ent dependencies.ent developers.ent service/ maven.xml project.properties project.xml (extends root/common/maven/project.xml) ejb/ project.ent project.properties project.xml (extends root/project.xml) I have the maven.compile.source and maven.compile.target properties set in root/service/project.properties. Yet when I run maven multiproject:install from my root directory I get a warning and error regarding the assert keyword. If I put these properties in a root/project.properties file it works fine. Can anyone tell me if this is a bug or if I'm doing something wrong? -wr __ NOTICE: This communication and any files transmitted with it (communication) may contain privileged or other confidential information. This communication is intended solely for the individual or entity to whom it is addressed. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use this communication. Also, please indicate to the sender that you have received this communication in error, and then delete this communication and any copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RC3 Property Inheritance Problem
Just to follow up with some more info that I discovered... I created a root/maven.xml to echo the maven.compile.* properties during the build. Somewhere along the way my property values are being lost: build: [echo] maven.compile.source=1.4 [echo] maven.compile.target=1.4 multiproject:install: multiproject:projects-init: [echo] Gathering project list Starting the reactor... snip xdoclet:ejbdoclet: java:prepare-filesystem: java:compile: [echo] maven.compile.source=1.3 [echo] maven.compile.target=1.1 So is the problem in the property inheritance, the java plugin, or the multiproject plugin? Your help is greatly appreciated. -wr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
