commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject Re: [email] Please add new build to ibiblio
Date Thu, 30 Sep 2004 18:27:03 GMT
>  >
>>  I guess I wouldn't think it appropriate to put on ibiblio as it is
>>  now.  Would you be satisfied with a SNAPSHOT build on the Apache
>>  "nightly-build/beta" repository?  http://cvs.apache.org/repository/
>
>
>Well, there is currently two different (and old) Snapshot builds on
>ibiblio and a very old 0.1 release.  I'd prefer to see an updated
>snapshot build (with the timestamp format preferably) or something get
>put up there.  After all the code does work right now, and has changed
>significantly since the last snapshot build (the build doesn't even have
>the authentication support).

The SNAPSHOT I deployed is also available via the timestamped version.

>I would think that moving this to a 0.2 release would be acceptable.
>After all 0.2 is still indicates that the code is very pre-pre-alpha.

In general, I agree with you -- commons-email is just looking for 
someone to shepherd it along -- it is definitely functional.  I've 
had less time than I thought I would since I requested karma to be 
able to apply patches and such, but I will continue to look for time 
to move it along...
>
>>  That sounds interesting.  If the class takes the responsibility for
>>  interacting with Velocity, I kind of feel that it should be in some
>>  alternate package, to keep the core dependencies lighter -- but for
>>  one class, that feels a little bit much too.
>
>
>Hmmm..  Personally, I don't think putting it in a different package is
>overkill.  Adding velocity requires the addition of Velocity.jar to
>build, but not to run (unless of course, you use the class ;-).

No, an alternate Java package is no big deal -- I meant more like an 
alternate "artifact."  But I agree that if it only brings a runtime 
dependency, it isn't worth creating a second artifact for it, 
especially in the absence of any other reasons to make another 
artifact.

>Alternatively,  we can borrow the template abstraction used in Groovy
>for this sort of thing.

I hadn't realized there was one -- do you have a pointer?  However, 
if using that requires a dependency on Groovy, then I'd want to wait 
until Groovy hits 1.0.  My sense is that it's still prone to a lot of 
change.

Mike, do you know that your e-mail is timestamped one day ahead?  Is 
that your way of staying on the cutting edge? ;^)

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn 
back; I'll know I'm in the wrong place."
    - Carlos Santana
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message