Re: Compilation errors in module javamail-transport
David Blevins wrote: On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/store code into the spec jar since they are so tightly coupled. If they are fundamentally one unit and completely tied together, it may make more sense to put them together. Course, I may not understand the implications of what I say :) The javamail-transport module got created, I believe, from a combination and history. The SMTP transport code was not originally included with the spec code, but resided in the sandbox for a while. When it got promoted out of the sandbox, it was placed into it's own module in the Geronimo tree rather than rolled into the spec code. Probably ok if this is only used bundled with Geronimo, but makes less sense if we believe this might be used standalone. I guess if the javamail-transport module is going to be where all the change occurs, then having it outside specs kind of handy -- provided the javamail module itself calms down and doesn't keep changing right along with it. I believe it's going to be a while before the spec module calms down. I'm finding more and more unimplemented/incompletely implemented features all the time. Could go a couple ways. -David
Re: Compilation errors in module javamail-transport
On Feb 9, 2006, at 5:06 AM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/ store code into the spec jar since they are so tightly coupled. If they are fundamentally one unit and completely tied together, it may make more sense to put them together. Course, I may not understand the implications of what I say :) The javamail-transport module got created, I believe, from a combination and history. The SMTP transport code was not originally included with the spec code, but resided in the sandbox for a while. When it got promoted out of the sandbox, it was placed into it's own module in the Geronimo tree rather than rolled into the spec code. Probably ok if this is only used bundled with Geronimo, but makes less sense if we believe this might be used standalone. I guess if the javamail-transport module is going to be where all the change occurs, then having it outside specs kind of handy -- provided the javamail module itself calms down and doesn't keep changing right along with it. I believe it's going to be a while before the spec module calms down. I'm finding more and more unimplemented/incompletely implemented features all the time. Hi Rick, I started to look at adding the javamail spec to GBuild, yesterday, before seeing this thread. Two benefits -- 1) forced me to look at how projects get added to continuum and 2) more importantly, should be much easier to make spec changes generally available. This will still require the occasional online build (or manual download) when the javamail spec changes, but is still better than the current situation. Since I'm ready to go, I'll go ahead and commit my changes and get things running. --kevan Could go a couple ways. -David
Re: Compilation errors in module javamail-transport
On 2/9/06, Kevan Miller [EMAIL PROTECTED] wrote: On Feb 9, 2006, at 5:06 AM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/ store code into the spec jar since they are so tightly coupled. If they are fundamentally one unit and completely tied together, it may make more sense to put them together. Course, I may not understand the implications of what I say :) The javamail-transport module got created, I believe, from a combination and history. The SMTP transport code was not originally included with the spec code, but resided in the sandbox for a while. When it got promoted out of the sandbox, it was placed into it's own module in the Geronimo tree rather than rolled into the spec code. Probably ok if this is only used bundled with Geronimo, but makes less sense if we believe this might be used standalone. I guess if the javamail-transport module is going to be where all the change occurs, then having it outside specs kind of handy -- provided the javamail module itself calms down and doesn't keep changing right along with it. I believe it's going to be a while before the spec module calms down. I'm finding more and more unimplemented/incompletely implemented features all the time. Hi Rick, I started to look at adding the javamail spec to GBuild, yesterday, before seeing this thread. Two benefits -- 1) forced me to look at how projects get added to continuum and 2) more importantly, should be much easier to make spec changes generally available. This will still require the occasional online build (or manual download) when the javamail spec changes, but is still better than the current situation. Since I'm ready to go, I'll go ahead and commit my changes and get things running. Thanks for doing this, Kevan, but shouldn't we put the entire specs project in there instead of just a single module? I'm not sure if other modules are going to be moving as much as JavaMail. Also, I'm not sure if GBuild will know to build the spec using Maven 2 or not - do you know? If not, as David Blevins advised me, we may need to just create a small shell script that calls mvn clean install, check it into the specs SVN base dir and then set up the JavaMail build as a shell script that calls the script. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
On Feb 9, 2006, at 9:43 AM, Bruce Snyder wrote: On 2/9/06, Kevan Miller [EMAIL PROTECTED] wrote: On Feb 9, 2006, at 5:06 AM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/ store code into the spec jar since they are so tightly coupled. If they are fundamentally one unit and completely tied together, it may make more sense to put them together. Course, I may not understand the implications of what I say :) The javamail-transport module got created, I believe, from a combination and history. The SMTP transport code was not originally included with the spec code, but resided in the sandbox for a while. When it got promoted out of the sandbox, it was placed into it's own module in the Geronimo tree rather than rolled into the spec code. Probably ok if this is only used bundled with Geronimo, but makes less sense if we believe this might be used standalone. I guess if the javamail-transport module is going to be where all the change occurs, then having it outside specs kind of handy -- provided the javamail module itself calms down and doesn't keep changing right along with it. I believe it's going to be a while before the spec module calms down. I'm finding more and more unimplemented/incompletely implemented features all the time. Hi Rick, I started to look at adding the javamail spec to GBuild, yesterday, before seeing this thread. Two benefits -- 1) forced me to look at how projects get added to continuum and 2) more importantly, should be much easier to make spec changes generally available. This will still require the occasional online build (or manual download) when the javamail spec changes, but is still better than the current situation. Since I'm ready to go, I'll go ahead and commit my changes and get things running. Thanks for doing this, Kevan, but shouldn't we put the entire specs project in there instead of just a single module? I'm not sure if other modules are going to be moving as much as JavaMail. Also, I'm not sure if GBuild will know to build the spec using Maven 2 or not - do you know? If not, as David Blevins advised me, we may need to just create a small shell script that calls mvn clean install, check it into the specs SVN base dir and then set up the JavaMail build as a shell script that calls the script. Hi Bruce, I was thinking of adding the entire specs project also. However, David Blevins advised against it and convinced me that it's not a wise thing to do. Let's see how I can do... ;-) The basic issue is that the specs project is composed of SNAPSHOT and non-SNAPSHOT modules. If we add the entire specs project to GBuild, we'll start publishing both types of modules (or it will be hard not to do so...). This seems unwise. Plus, if we update a spec without updating the spec version in pom.xml, we might start publishing non- SNAPSHOT modules with new content. Doubly unwise. I think it's best that we only add individual SNAPSHOT spec modules to GBuild. When these modules are released, we'll need to remove them from GBuild. This process could use a bit more rigor, but shouldn't be too hard to manage... Thoughts? FYI, after 1 misstep, javamail is building on GBuild. Now, just need to add specs to the rsync that's moving things to apache... --kevan
Re: Compilation errors in module javamail-transport
Hi, In this situation, I think that you should try: maven -U clean install -U means that newer versions of plugins should be checked from the plugin repositories. Thanks, Gianny Vamsavardhana Reddy wrote: Got the following error trying to build geronimo-spec-javamail. Help C:\GeronimoSource\geronimo\specs\trunk\geronimo-spec-javamailc:\maven-2.0.2\bi \mvn clean install [INFO] Scanning for projects... [INFO] --- [INFO] Building Java Mail [INFO]task-segment: [clean, install] [INFO] --- [INFO] [clean:clean] [INFO] --- [ERROR] BUILD ERROR [INFO] --- [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not ex st or no valid version could be found [INFO] --- [INFO] For more information, run Maven with the -e switch [INFO] --- [INFO] Total time: 2 seconds [INFO] Finished at: Wed Feb 08 16:11:36 IST 2006 [INFO] Final Memory: 2M/4M [INFO] --- On 2/7/06, *Bruce Snyder* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 2/6/06, Jian Liao [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo ( http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
Thanks Gianny. That worked!! -VamsiOn 2/8/06, Gianny Damour [EMAIL PROTECTED] wrote: Hi,In this situation, I think that you should try:maven -U clean install-U means that newer versions of plugins should be checked from theplugin repositories.Thanks,GiannyVamsavardhana Reddy wrote: Got the following error trying to build geronimo-spec-javamail.Help C:\GeronimoSource\geronimo\specs\trunk\geronimo-spec-javamailc:\maven-2.0.2\bi \mvn clean install [INFO] Scanning for projects... [INFO] --- [INFO] Building Java Mail [INFO]task-segment: [clean, install] [INFO] --- [INFO] [clean:clean] [INFO] --- [ERROR] BUILD ERROR [INFO] --- [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin ' does not ex st or no valid version could be found [INFO] --- [INFO] For more information, run Maven with the -e switch [INFO] --- [INFO] Total time: 2 seconds [INFO] Finished at: Wed Feb 08 16:11:36 IST 2006 [INFO] Final Memory: 2M/4M [INFO] --- On 2/7/06, *Bruce Snyder* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 2/6/06, Jian Liao [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec- 1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo ( http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. [javac] import org.apache.geronimo.mail.util.Hex; [javac] import org.apache.geronimo.mail.util.Base64; [javac] import org.apache.geronimo.mail.util.XText Is this the case or are there other things that make our javamail- transport module dependent on our specific javamail implementation? -David On Feb 6, 2006, at 11:04 PM, Bruce Snyder wrote: On 2/6/06, Jian Liao [EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo- javamail_1.3.1_spec-1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. [javac] import org.apache.geronimo.mail.util.Hex; [javac] import org.apache.geronimo.mail.util.Base64; [javac] import org.apache.geronimo.mail.util.XText Is this the case or are there other things that make our javamail-transport module dependent on our specific javamail implementation? I believe there are a few package-scope methods defined on some of the javax.mail.* classes that also introduce some dependencies (note that the Sun impl also appears to do that in some places). I placed those classes in the javamail jar rather than the javamail-transport module because the implementation of the MimeUtility class will also need the same converters. -David On Feb 6, 2006, at 11:04 PM, Bruce Snyder wrote: On 2/6/06, Jian Liao [EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. [javac] import org.apache.geronimo.mail.util.Hex; [javac] import org.apache.geronimo.mail.util.Base64; [javac] import org.apache.geronimo.mail.util.XText Is this the case or are there other things that make our javamail- transport module dependent on our specific javamail implementation? I believe there are a few package-scope methods defined on some of the javax.mail.* classes that also introduce some dependencies (note that the Sun impl also appears to do that in some places). I placed those classes in the javamail jar rather than the javamail- transport module because the implementation of the MimeUtility class will also need the same converters. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. -David
Re: Compilation errors in module javamail-transport
David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. [javac] import org.apache.geronimo.mail.util.Hex; [javac] import org.apache.geronimo.mail.util.Base64; [javac] import org.apache.geronimo.mail.util.XText Is this the case or are there other things that make our javamail-transport module dependent on our specific javamail implementation? I believe there are a few package-scope methods defined on some of the javax.mail.* classes that also introduce some dependencies (note that the Sun impl also appears to do that in some places). I placed those classes in the javamail jar rather than the javamail-transport module because the implementation of the MimeUtility class will also need the same converters. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/store code into the spec jar since they are so tightly coupled. Rick -David
Re: Compilation errors in module javamail-transport
On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/store code into the spec jar since they are so tightly coupled. If they are fundamentally one unit and completely tied together, it may make more sense to put them together. Course, I may not understand the implications of what I say :) I guess if the javamail-transport module is going to be where all the change occurs, then having it outside specs kind of handy -- provided the javamail module itself calms down and doesn't keep changing right along with it. Could go a couple ways. -David
Re: Compilation errors in module javamail-transport
On 2/7/06, Jian Liao [EMAIL PROTECTED] wrote: Hi Bruce, I rebuild geronimo-spec with mvn clean install, then I try to build geronimo svn head with: maven -o m:clean new. I got the following exception from the javamail-transport module: Jian, I fixed the compilation issues and the build should now complete without error. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Compilation errors in module javamail-transport
Compilation errors in modules\javamail-transport\src\java\org\apache\geronimo\javamail\authentication\CramMD5Authenticator.java Command line output from running rebuild on the project is given below. C:\GeronimoSource\geronimo\modules\javamail-transportmaven -Dmaven.test.skip=true -Dmaven.itest.skip=true rebuild __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-2 DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml Attempting to download geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar. build:start: rebuild: clean:clean: xdoc:clean: [delete] Deleting directory C:\GeronimoSource\geronimo\modules\javamail-tran sport\target clean: build: default: java:prepare-filesystem: [mkdir] Created dir: C:\GeronimoSource\geronimo\modules\javamail-transport\t arget\classes java:compile: depend closure=false srcdir=1.4 dump=false destdir=C:\GeronimoSource\ger onimo\modules\javamail-transport/target/classes/depend [echo] Compiling t o C:\GeronimoSource\geronimo\modules\javamail-transport/target/classes [javac] Compiling 31 source files to C:\GeronimoSource\geronimo\modules\java mail-transport\target\classes [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\CramMD5Authenticator.java:26: package org .apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\CramMD5Authenticator.java:27: package org .apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Hex; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:29: package o rg.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:30: package o rg.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Hex; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\LoginAuthenticator.java:24: package org.a pache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\PlainAuthenticator.java:24: package org.a pache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\transport\smtp\SMTPTransport.java:53: package org.apache .geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\transport\smtp\SMTPTransport.java:54: package org.apache .geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.XText; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\CramMD5Authenticator.java:99: cannot reso lve symbol [javac] symbol : variable Hex [javac] location: class org.apache.geronimo.javamail.authentication.CramMD5A uthenticator [javac] String responseString = username + + new String(Hex. encode(digest)); [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:168: cannot r esolve symbol [javac] symbol : variable Hex [javac] location: class org.apache.geronimo.javamail.authentication.DigestMD 5Authenticator [javac] String responseString = clientResponse + new String(Hex. encode(digest.digest())); [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:172: cannot r esolve symbol [javac] symbol : variable Hex [javac] location: class org.apache.geronimo.javamail.authentication.DigestMD 5Authenticator [javac] String validationText = new String(Hex.encode(digest.dig est())); [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:228: cannot r esolve symbol [javac] symbol : variable Base64 [javac] location: class org.apache.geronimo.javamail.authentication.DigestMD 5Authenticator [javac] String cnonce = new String(Base64.encode(cnonceBytes)); [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
Re: Compilation errors in module javamail-transport
Hi,Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml.Hope it help,- Jian Liao On 2/7/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Compilation errors in modules\javamail-transport\src\java\org\apache\geronimo\javamail\authentication\CramMD5Authenticator.java Command line output from running rebuild on the project is given below. C:\GeronimoSource\geronimo\modules\javamail-transportmaven -Dmaven.test.skip=true -Dmaven.itest.skip=true rebuild __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-2 DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml Attempting to download geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar. build:start: rebuild: clean:clean: xdoc:clean: [delete] Deleting directory C:\GeronimoSource\geronimo\modules\javamail-tran sport\target clean: build: default: java:prepare-filesystem: [mkdir] Created dir: C:\GeronimoSource\geronimo\modules\javamail-transport\t arget\classes java:compile: depend closure=false srcdir=1.4 dump=false destdir=C:\GeronimoSource\ger onimo\modules\javamail-transport/target/classes/depend [echo] Compiling t o C:\GeronimoSource\geronimo\modules\javamail-transport/target/classes [javac] Compiling 31 source files to C:\GeronimoSource\geronimo\modules\java mail-transport\target\classes [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\CramMD5Authenticator.java:26: package org .apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\CramMD5Authenticator.java:27: package org .apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Hex; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:29: package o rg.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:30: package o rg.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Hex; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\LoginAuthenticator.java:24: package org.a pache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\PlainAuthenticator.java:24: package org.a pache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\transport\smtp\SMTPTransport.java:53: package org.apache .geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\transport\smtp\SMTPTransport.java:54: package org.apache .geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.XText; [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\CramMD5Authenticator.java:99: cannot reso lve symbol [javac] symbol : variable Hex [javac] location: class org.apache.geronimo.javamail.authentication.CramMD5A uthenticator [javac] String responseString = username + + new String(Hex. encode(digest)); [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:168: cannot r esolve symbol [javac] symbol : variable Hex [javac] location: class org.apache.geronimo.javamail.authentication.DigestMD 5Authenticator [javac] String responseString = clientResponse + new String(Hex. encode(digest.digest())); [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:172: cannot r esolve symbol [javac] symbol : variable Hex [javac] location: class org.apache.geronimo.javamail.authentication.DigestMD 5Authenticator [javac] String validationText = new String(Hex.encode(digest.dig est())); [javac] ^ [javac] C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:228: cannot r esolve symbol [javac] symbol : variable Base64 [javac] location: class
Re: Compilation errors in module javamail-transport
On 2/6/06, Jian Liao [EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
Hi Bruce,I rebuild geronimo-spec with mvn clean install, then I try to build geronimo svn head with: maven -o m:clean new. I got the following exception from the javamail-transport module:java:compile:depend closure=false srcdir=
1.4 dump=false destdir=D:\eclipse\workspace\geronimo-local\modules\javamail-transport/target/classes/depend [echo] Compiling to D:\eclipse\workspace\geronimo-local\modules\javamail-transport/target
/classes [javac] Compiling 3 source files to D:\eclipse\workspace\geronimo-local\modules\javamail-transport\target\classes [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\j
ava\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:343: exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException is never thrown in body of corresponding try statement [javac] } catch (SMTPTransportException e) {
[javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\java\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:348: exception org.apache.geronimo.javamail.transport.smtp.MalformedSMTPReplyException
is never thrown in body of corresponding try statement [javac] } catch (MalformedSMTPReplyException e) { [javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\j
ava\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1268: unreported exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException; must be caught or declared to be thrown [javac] throw new SMTPTransportException(e);
[javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\java\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1270: unreported exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException
; must be caught or declared to be thrown [javac] throw new SMTPTransportException(e); [javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\j
ava\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1278: unreported exception org.apache.geronimo.javamail.transport.smtp.MalformedSMTPReplyException; must be caught or declared to be thrown
[javac] line = new SMTPReply(receiveLine(TIMEOUT * 2)); [javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\java\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1400: unrepor
ted exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException; must be caught or declared to be thrown [javac] throw new SMTPTransportException(no FROM address);
[javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\java\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1518: unreported exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException
; must be caught or declared to be thrown [javac] throw new SMTPTransportException(no connection); [javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\j
ava\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1526: unreported exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException; must be caught or declared to be thrown [javac] throw new SMTPTransportException(e);
[javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\java\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1546: unreported exception org.apache.geronimo.javamail.transport.smtp.MalformedSMTPReplyExce
ption; must be caught or declared to be thrown [javac] lastServerResponse = new SMTPReply(receiveLine()); [javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\j
ava\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1573: unreported exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException; must be caught or declared to be thrown [javac] throw new SMTPTransportException(no connection);
[javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\java\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1611: unreported exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException
; must be caught or declared to be thrown [javac] throw new SMTPTransportException(e); [javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\j
ava\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1613: unreported exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException; must be caught or declared to be thrown [javac] throw new SMTPTransportException(e);
[javac] ^ [javac] D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\java\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1763: unreported exception org.apache.geronimo.javamail.transport.smtp.SMTPTransportException
; must be caught or declared to be thrown [javac] throw new SMTPTransportException(Can't get local hostname.
