You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Vamsavardhana Reddy <c1...@gmail.com> on 2006/02/07 07:31:11 UTC
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-transport>maven -
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
pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:247:
cannot r
esolve symbol
[javac] symbol : variable Hex
[javac] location: class
org.apache.geronimo.javamail.authentication.DigestMD
5Authenticator
[javac] clientResponse = new String(Hex.encode(digest.digest
()))
+ ":" + nonce + ":00000001:" + cnonce + ":auth:";
[javac] ^
[javac]
C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:255:
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:260:
cannot r
esolve symbol
[javac] symbol : variable Hex
[javac] location: class
org.apache.geronimo.javamail.authentication.DigestMD
5Authenticator
[javac] String challengeResponse = new String(Hex.encode
(digest.
digest()));
[javac] ^
[javac]
C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
pache\geronimo\javamail\transport\smtp\SMTPTransport.java:1460: cannot
resolve s
ymbol
[javac] symbol : variable XText
[javac] location: class
org.apache.geronimo.javamail.transport.smtp.SMTPTran
sport
[javac] command.append(new String(XText.encode
(submitter
.getBytes("US-ASCII"))));
[javac] ^
[javac]
C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
pache\geronimo\javamail\transport\smtp\SMTPTransport.java:1998: cannot
resolve s
ymbol
[javac] symbol : variable Base64
[javac] location: class
org.apache.geronimo.javamail.transport.smtp.SMTPTran
sport
[javac] command.append(new String(Base64.encode(
authenticator.ev
aluateChallenge(null))));
[javac] ^
[javac]
C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
pache\geronimo\javamail\transport\smtp\SMTPTransport.java:2035: cannot
resolve s
ymbol
[javac] symbol : variable Base64
[javac] location: class
org.apache.geronimo.javamail.transport.smtp.SMTPTran
sport
[javac] byte[] challenge = Base64.decode(line.getMessage
().g
etBytes());
[javac] ^
[javac]
C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
pache\geronimo\javamail\transport\smtp\SMTPTransport.java:2038: cannot
resolve s
ymbol
[javac] symbol : variable Base64
[javac] location: class
org.apache.geronimo.javamail.transport.smtp.SMTPTran
sport
[javac] sendLine(new String(Base64.encode(
authenticator.eval
uateChallenge(challenge))));
[javac] ^
[javac] 19 errors
BUILD FAILED
File...... C:\Documents and
Settings\Administrator\.maven\cache\maven-java-plugi
n-1.5\plugin.jelly
Element... ant:javac
Line...... 63
Column.... -1
Compile failed; see the compiler error output for details.
Total time : 19 seconds
Finished at : Tuesday, February 7, 2006 11:55:15 AM IST
Re: Compilation errors in module javamail-transport
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
Thanks Gianny. That worked!!
-Vamsi
On 2/8/06, Gianny Damour <gi...@optusnet.com.au> 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 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-javamail>c:\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* <bruce.snyder@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > On 2/6/06, Jian Liao <norwaywoods@gmail.com
> > <ma...@gmail.com>> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> > );'
> >
> > Apache Geronimo ( http://geronimo.apache.org/)
> >
> > Castor (http://castor.org/)
> >
> >
>
>
>
Re: Compilation errors in module javamail-transport
Posted by Gianny Damour <gi...@optusnet.com.au>.
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-javamail>c:\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* <bruce.snyder@gmail.com
> <ma...@gmail.com>> wrote:
>
> On 2/6/06, Jian Liao <norwaywoods@gmail.com
> <ma...@gmail.com>> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo ( http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
>
>
Re: Compilation errors in module javamail-transport
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
Got the following error trying to build geronimo-spec-javamail. Help!!!!
C:\GeronimoSource\geronimo\specs\trunk\geronimo-spec-javamail>c:\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 <br...@gmail.com> wrote:
>
> On 2/6/06, Jian Liao <no...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
>
Re: Compilation errors in module javamail-transport
Posted by Kevan Miller <ke...@gmail.com>.
On Feb 9, 2006, at 9:43 AM, Bruce Snyder wrote:
> On 2/9/06, Kevan Miller <ke...@gmail.com> 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
Posted by Bruce Snyder <br...@gmail.com>.
On 2/9/06, Kevan Miller <ke...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Rick McGuire <ri...@gmail.com>.
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
Posted by David Blevins <da...@visi.com>.
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
Posted by Rick McGuire <ri...@gmail.com>.
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
Posted by David Blevins <da...@visi.com>.
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
Posted by Rick McGuire <ri...@gmail.com>.
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 <no...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>>
>> Apache Geronimo (http://geronimo.apache.org/)
>>
>> Castor (http://castor.org/)
>>
>
>
Re: Compilation errors in module javamail-transport
Posted by David Blevins <da...@visi.com>.
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 <no...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
>
Re: Compilation errors in module javamail-transport
Posted by Bruce Snyder <br...@gmail.com>.
On 2/7/06, Jian Liao <no...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
Posted by Jian Liao <no...@gmail.com>.
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] Co
mpiling to
D:\eclipse\workspace\geronimo-local\modules\javamail-transport/target
/classes
[javac] Compiling 3 source files to
D:\eclipse\workspace\geronimo-local\modu
les\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:
exceptio
n org.apache.geronimo.javamail.transport.smtp.SMTPTransportException is
never th
rown in body of corresponding try statement
[javac] } catch (SMTPTransportException e) {
[javac] ^
[javac]
D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\j
ava\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:348:
exceptio
n org.apache.geronimo.javamail.transport.smtp.MalformedSMTPReplyException is
nev
er 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:
unrepor
ted 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:1270:
unrepor
ted 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:
unrepor
ted exception
org.apache.geronimo.javamail.transport.smtp.MalformedSMTPReplyExce
ption; 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\j
ava\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\j
ava\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:1518:
unrepor
ted 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:
unrepor
ted 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:1546:
unrepor
ted 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:
unrepor
ted 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:1611:
unrepor
ted 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:
unrepor
ted 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:1763:
unrepor
ted exception
org.apache.geronimo.javamail.transport.smtp.SMTPTransportException
; must be caught or declared to be thrown
[javac] throw new SMTPTransportException("Can't get
local ho
stname. " +
[javac] ^
[javac]
D:\eclipse\workspace\geronimo-local\modules\javamail-transport\src\j
ava\org\apache\geronimo\javamail\transport\smtp\SMTPTransport.java:2017:
unrepor
ted exception
org.apache.geronimo.javamail.transport.smtp.MalformedSMTPReplyExce
ption; must be caught or declared to be thrown
[javac] SMTPReply line = new SMTPReply(receiveLine());
[javac] ^
[javac] 14 errors
BUILD FAILED
File...... D:\Maven\local\repository\cache\maven-
java-plugin-1.5\plugin.jelly
Element... ant:javac
Line...... 63
Column.... -1
Compile failed; see the compiler error output for details.
Total time : 3 seconds
My env:
OS: WinXP SP2
JDK: 1.4.2_10
thanks,
- Jian Liao
On 2/7/06, Bruce Snyder <br...@gmail.com> wrote:
>
> On 2/6/06, Jian Liao <no...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo ( http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
>
Re: Compilation errors in module javamail-transport
Posted by Bruce Snyder <br...@gmail.com>.
On 2/6/06, Jian Liao <no...@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
Posted by Jian Liao <no...@gmail.com>.
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 <c1...@gmail.com> 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-transport>maven -
> 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
> pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:247:
> cannot r
> esolve symbol
> [javac] symbol : variable Hex
> [javac] location: class
> org.apache.geronimo.javamail.authentication.DigestMD
> 5Authenticator
> [javac] clientResponse = new String(Hex.encode(
> digest.digest()))
> + ":" + nonce + ":00000001:" + cnonce + ":auth:";
> [javac] ^
> [javac]
> C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
> pache\geronimo\javamail\authentication\DigestMD5Authenticator.java:255:
> 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:260:
> cannot r
> esolve symbol
> [javac] symbol : variable Hex
> [javac] location: class
> org.apache.geronimo.javamail.authentication.DigestMD
> 5Authenticator
> [javac] String challengeResponse = new String(Hex.encode
> (digest.
> digest()));
> [javac] ^
> [javac]
> C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
> pache\geronimo\javamail\transport\smtp\SMTPTransport.java:1460: cannot
> resolve s
> ymbol
> [javac] symbol : variable XText
> [javac] location: class
> org.apache.geronimo.javamail.transport.smtp.SMTPTran
> sport
> [javac] command.append(new String(XText.encode
> (submitter
> .getBytes("US-ASCII"))));
> [javac] ^
> [javac]
> C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
> pache\geronimo\javamail\transport\smtp\SMTPTransport.java:1998: cannot
> resolve s
> ymbol
> [javac] symbol : variable Base64
> [javac] location: class
> org.apache.geronimo.javamail.transport.smtp.SMTPTran
> sport
> [javac] command.append(new String(Base64.encode(
> authenticator.ev
> aluateChallenge(null))));
> [javac] ^
> [javac]
> C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
> pache\geronimo\javamail\transport\smtp\SMTPTransport.java:2035: cannot
> resolve s
> ymbol
> [javac] symbol : variable Base64
> [javac] location: class
> org.apache.geronimo.javamail.transport.smtp.SMTPTran
> sport
> [javac] byte[] challenge = Base64.decode(
> line.getMessage().g
> etBytes());
> [javac] ^
> [javac]
> C:\GeronimoSource\geronimo\modules\javamail-transport\src\java\org\a
> pache\geronimo\javamail\transport\smtp\SMTPTransport.java:2038: cannot
> resolve s
> ymbol
> [javac] symbol : variable Base64
> [javac] location: class
> org.apache.geronimo.javamail.transport.smtp.SMTPTran
> sport
> [javac] sendLine(new String(Base64.encode(
> authenticator.eval
> uateChallenge(challenge))));
> [javac] ^
> [javac] 19 errors
>
> BUILD FAILED
> File...... C:\Documents and
> Settings\Administrator\.maven\cache\maven-java-plugi
> n-1.5\plugin.jelly
> Element... ant:javac
> Line...... 63
> Column.... -1
> Compile failed; see the compiler error output for details.
> Total time : 19 seconds
> Finished at : Tuesday, February 7, 2006 11:55:15 AM IST