You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Martin Cooper <mf...@gmail.com> on 2004/09/30 21:54:00 UTC
Re: [email] Please add new build to ibiblio
On Fri, 01 Oct 2004 13:45:43 -0400, Mike Stanley <ms...@mstanley.net> wrote:
> On Thu, 2004-09-30 at 11:30, Joe Germuska wrote:
>
> > At 10:32 AM -0400 10/1/04, Mike Stanley wrote:
> > >I don't think there is a maintainer for this (ultra-tiny but useful),
> > >sandbox component. Can someone take the initiative and push the latest
> > >build to the repository at ibiblio? Maybe even coordinate a 0.2 release
> > >:-)
> >
> > I'm not the maintainer, but I recently got sandbox karma and I'm
> > interested in commons-email.
>
>
> cool.
>
>
> >
> > 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).
>
> 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.
>
>
> > Maybe I'm making too much of the "sandbox" status and the like, but
> > my sense has been that the ibiblio mirror is intended for more
> > official, finished stuff.
> >
> > >In addition, I have a basic class VelocityHtmlEmail that extends
> > >HtmlEmail and adds support for setting the Html Msg with a template, and
> > >Plain Text Msg with templates. This is very basic, but I find it very
> > >useful, especially when working with other developers that aren't
> > >familiar with Velocity. I there is interest I will contribute this
> > >class to the project.
> >
> > 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 ;-).
I'd prefer to avoid a required build-time dependency on something like
Velocity. Better would be to borrow the approach Commons Chain uses,
and only build Velocity-specific code if the Velocity jar is present.
--
Martin Cooper
>
>
> > Once upon a time, I wrote a template abstraction API which could be
> > brought to bear on this problem. It was quite simple, but I was able
> > to use it to set up templated email that could use Velocity or Jelly
> > as template languages. The Jelly template thing was just a proof of
> > concept.
>
>
> Alternatively, we can borrow the template abstraction used in Groovy
> for this sort of thing.
>
>
> > For now, why don't you file a Bugzilla ticket and attach the source
> > for the class. That will put it somewhere where it won't get lost
> > while we see if anyone else out there has strong feelings about some
> > of these questions...
>
>
> Will do.
>
> >
> > Joe
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Please add new build to ibiblio
Posted by Mike Stanley <ms...@mstanley.net>.
Hey...
On Thu, 2004-09-30 at 19:58, Joe Germuska wrote:
> At 12:54 PM -0700 9/30/04, Martin Cooper wrote:
> > > 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 ;-).
> >
> >I'd prefer to avoid a required build-time dependency on something like
> >Velocity. Better would be to borrow the approach Commons Chain uses,
> >and only build Velocity-specific code if the Velocity jar is present.
>
> I'm kind of ambivalent about this approach. I would be concerned
> that you'd be building jars which are supposed to represent the same
> artifact but which have different contents based on the build
> circumstances. I guess also since I'm generally accustomed to using
> Maven for builds, I don't really see the gain in conditional
> compilation, because satisfying dependencies is automatic.
I agree with this as well. If adding support for velocity adds a build
time dependency that people aren't comfortable with, I'd rather find a
different home, but I do believe this is the best place for it (as it is
probably common practice).
I'd rather not see different build flavors. That could seems to be more
confusing in the end. I believe the added confusion doesn't justify the
gains.
>
> Do you suggest the conditional compilation because you don't want
> people to have to bother with the dependency? Or because you want to
> make it possible for people to keep the Velocity dependency out of
> their commons-email jar for some reason?
>
> Joe
Re: [VFS] Is there a different list for the sandbox projects?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Andy Lewis wrote:
> I do understand about the native code issue. There are simply a
> limited number of ways to do certain things though. And I believe even
> in the to do list where this is mentioned it specifies that in any
> case, the native code should be completely optional. I could also do a
> fall back to other methods if the native code isn't present - like
> command lines tools for example. If I can get something working, that
> would probably be the best time to check and see what the community
> thinks...say, before it is committed.
I know the original authors of VFS added this to the todo list, but i am
not sure how we should add this to VFS.
VFS tries to abstract as much as it can from the underlaying filesystem
- but this might be nearly impossible in the case of permissions - think
about unix/windows differences in handling of these things.
And even then, it might work only with one kind of filesystem - the
local filesystem.
That said, i can think about a utility-helper-class which do this stuff
- e.g. UnixUtils.setPermission(FileObject, permission)
That way it is not strongly coupled with vfs and we do not have to find
a common abstraction.
It would be nice if you could take a look at jsch and sshd. jsch defines
a SftpAttrs.setPermissions(int) - maybe your "permission" argument could
be compatible with it - then the utility wrapper could set the
permission on two filesystems ;-)
What do you think?
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Is there a different list for the sandbox projects?
Posted by Andy Lewis <aj...@ascii27.net>.
I'm currently working with a CVS build from late August (I built on the
25th, it may have been a day or two old CVS at that point though). I'll
definitely check out the latest and see if that takes care of the cache
problem. If not, I'll get it into bugzilla.
I do understand about the native code issue. There are simply a limited
number of ways to do certain things though. And I believe even in the to
do list where this is mentioned it specifies that in any case, the
native code should be completely optional. I could also do a fall back
to other methods if the native code isn't present - like command lines
tools for example. If I can get something working, that would probably
be the best time to check and see what the community thinks...say,
before it is committed.
Mario Ivankovits wrote:
> Andy Lewis schrieb:
>
>> I ran into a problem for example with the cache not picking up new
>> files on an FTP site, so I needed to manually force the cache to
>> clear (I use reflection with setAccessible to get it done instead of
>> using a modified build though).
>
>
> Do you use the CVS version or one of the nightlies?
> It should be possible to clear the cache (in case of ftp) by simply
> call close() on the parent.
>
>> I can also see value in additional providers - both those on the list
>> and maybe some that are not. Again, my time constraints tend to align
>> with my current needs , but as an example I have an upcoming need for
>> the ability to modify unix file permissions from Java (appears it
>> will require native interaction), and noticed this is something on
>> the list of desired eventual features.
>
>
> This is on the todo list - this list where created by the original
> maintainers. But I have to warn you ;-) I would like to poll the
> community what they do think about native code in jakarta projects.
>
>> In terms of immeidate contributions, I'd love to get a patch in to
>> make it easier to avoid the cache problems, and I'm willing to take a
>> look at anything (bug ot feature) that is deemed highest priority.
>
>
> The right way to send the path it to open a bugzilla tiket at
> http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons
> I will be happy to pick it up. Please prefix your subject with [vfs]
>
>> The effort I'll be able to spend on it wil;l, like nearly everyone
>> I'm sure, fluctuate, but it is a cool project, I use it, and I'm
>> interested in helping it move forward....
>
>
> Thats the way we work. Every help is welcome.
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Is there a different list for the sandbox projects?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Andy Lewis schrieb:
> I ran into a problem for example with the cache not picking up new
> files on an FTP site, so I needed to manually force the cache to clear
> (I use reflection with setAccessible to get it done instead of using a
> modified build though).
Do you use the CVS version or one of the nightlies?
It should be possible to clear the cache (in case of ftp) by simply call
close() on the parent.
> I can also see value in additional providers - both those on the list
> and maybe some that are not. Again, my time constraints tend to align
> with my current needs , but as an example I have an upcoming need for
> the ability to modify unix file permissions from Java (appears it will
> require native interaction), and noticed this is something on the list
> of desired eventual features.
This is on the todo list - this list where created by the original
maintainers. But I have to warn you ;-) I would like to poll the
community what they do think about native code in jakarta projects.
> In terms of immeidate contributions, I'd love to get a patch in to
> make it easier to avoid the cache problems, and I'm willing to take a
> look at anything (bug ot feature) that is deemed highest priority.
The right way to send the path it to open a bugzilla tiket at
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons
I will be happy to pick it up. Please prefix your subject with [vfs]
> The effort I'll be able to spend on it wil;l, like nearly everyone I'm
> sure, fluctuate, but it is a cool project, I use it, and I'm
> interested in helping it move forward....
Thats the way we work. Every help is welcome.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Is there a different list for the sandbox projects?
Posted by Andy Lewis <aj...@ascii27.net>.
I'm using VFS in an application now at work and there are a number of
things I'd love to do to it. Most of them will be driven by my needs as
much as anything else obviously. But I have no problem helping with
documentation, but my main interests would be with fixing bugs and
adding features. I ran into a problem for example with the cache not
picking up new files on an FTP site, so I needed to manually force the
cache to clear (I use reflection with setAccessible to get it done
instead of using a modified build though). I can also see value in
additional providers - both those on the list and maybe some that are
not. Again, my time constraints tend to align with my current needs ,
but as an example I have an upcoming need for the ability to modify unix
file permissions from Java (appears it will require native interaction),
and noticed this is something on the list of desired eventual features.
So I guess my main goal was to get in touch with you and get a read on
the status. I'm actually kind of surprised there isn't more community
effort behind this, but I guess everybody is still content using thier
own approach to it. In terms of immeidate contributions, I'd love to get
a patch in to make it easier to avoid the cache problems, and I'm
willing to take a look at anything (bug ot feature) that is deemed
highest priority. And of course as I get the native unix stuff in place,
I'll add that too.
The effort I'll be able to spend on it wil;l, like nearly everyone I'm
sure, fluctuate, but it is a cool project, I use it, and I'm interested
in helping it move forward....
Mario Ivankovits wrote:
> Andy Lewis wrote:
>
>> I have been subscribed here for a bit now, particularly looking for
>> traffic relating to the VFS project, but have not seen any. I know
>> there is some recent work going on on the project (just from CVS) but
>> have seen nothing on this list. I am hoping to be able to help with
>> it. Am I in the right place?
>
>
> Yes - there is not much community driven work.
> But I am still there and pick up every user request. And the bursts
> Gary talked about are those where i try to implement something
> completley new - due to the low user traffic here I try to move slowly
> to not run into a situation where VFS is completley unusable and
> nobody complains about, though I use it in our application and it
> still works very well.
>
> Next thing i would like to do is to make the FileObject thread-safe
> (which again will show up as burst on the list ;-)) but this is
> something I have to plan very carefully.
>
> And - fore sure - the documentation should be updated, but I am still
> in hope i find some native english speaker who would like to reread
> what i write - or even better - one who would like to write the
> documentation ;-)
>
> However, every contribution is welcome.
> What do you have in mind?
>
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Is there a different list for the sandbox projects?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Andy Lewis wrote:
> I have been subscribed here for a bit now, particularly looking for
> traffic relating to the VFS project, but have not seen any. I know
> there is some recent work going on on the project (just from CVS) but
> have seen nothing on this list. I am hoping to be able to help with
> it. Am I in the right place?
Yes - there is not much community driven work.
But I am still there and pick up every user request. And the bursts Gary
talked about are those where i try to implement something completley new
- due to the low user traffic here I try to move slowly to not run into
a situation where VFS is completley unusable and nobody complains about,
though I use it in our application and it still works very well.
Next thing i would like to do is to make the FileObject thread-safe
(which again will show up as burst on the list ;-)) but this is
something I have to plan very carefully.
And - fore sure - the documentation should be updated, but I am still in
hope i find some native english speaker who would like to reread what i
write - or even better - one who would like to write the documentation ;-)
However, every contribution is welcome.
What do you have in mind?
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[VFS] Is there a different list for the sandbox projects?
Posted by Andy Lewis <aj...@ascii27.net>.
I have been subscribed here for a bit now, particularly looking for
traffic relating to the VFS project, but have not seen any. I know there
is some recent work going on on the project (just from CVS) but have
seen nothing on this list. I am hoping to be able to help with it. Am I
in the right place?
Many thanks...
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Please add new build to ibiblio
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 30 Sep 2004 18:58:45 -0500, Joe Germuska <jo...@germuska.com> wrote:
> At 12:54 PM -0700 9/30/04, Martin Cooper wrote:
> > > 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 ;-).
> >
> >I'd prefer to avoid a required build-time dependency on something like
> >Velocity. Better would be to borrow the approach Commons Chain uses,
> >and only build Velocity-specific code if the Velocity jar is present.
>
> I'm kind of ambivalent about this approach. I would be concerned
> that you'd be building jars which are supposed to represent the same
> artifact but which have different contents based on the build
> circumstances. I guess also since I'm generally accustomed to using
> Maven for builds, I don't really see the gain in conditional
> compilation, because satisfying dependencies is automatic.
It wouldn't be any different from Chain, Logging and DBCP, to name
just a few of the Commons components that do this kind of thing.
> Do you suggest the conditional compilation because you don't want
> people to have to bother with the dependency? Or because you want to
> make it possible for people to keep the Velocity dependency out of
> their commons-email jar for some reason?
Both. Right now, the discussion is about Velocity. But what if all of
the other folks want in on the act? We'd have dependencies on Struts,
Tapestry, Turbine, Avalon (in its multiple variations), ... Where does
it end?
I'd rather keep such a simple component simple, and let the clients
that want it add the glue that they need where they need it.
--
Martin Cooper
>
> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Please add new build to ibiblio
Posted by Mike Stanley <ms...@mstanley.net>.
On Fri, 2004-10-01 at 08:21, Martin van den Bemt wrote:
> Maybe this has a better home at velocity ?
Maybe, but this does seem like common practice with the email.
But lets talk about this for a second. (and revisit - the plug-in
adapter idea that I gracefully spoke up against earlier).
For my project, I developed an alternative way to use email in the
Spring Framework. I don't terribly care for the approach taken by the
Spring Framework (discussed in this blog entry -
http://www.jroller.com/page/raible?anchor=sending_velocity_based_e_mail)
In fact, I prefer the commons-email component. I believe it has a
straight forward, OO design for creating and sending mail in Java.
To centralize my SMTP configuration, and utilize Spring IOC, I created a
Factory for generating Email objects. This is very basic, but offers
a clean way to both integrate commons-email into IOC containers, and
provide TemplateEmail apdapters. The factory interface looks something
like:
public interface EmailFactory
{
public TemplateEmail createEmail();
// other convenience methods such as the following
public TemplateEmail createEmail(Collection toList, Collection
ccList);
public void setHost(String host)
public void setPort(int port)
public void setUsername(String username);
public void setPassword(String username);
public void setFromEmail(String fromEmail);
public void setFromName(String fromName);
}
Then in my Spring config file. I have the following.
<bean id="beanThatSendsEmail" class="some.bean.that.sends.Email">
<constructor-arg><ref local="emailFactory"/></constructor-arg>
</bean>
<bean id="emailFactory" class="net.mstanley.email.VelocityEmailFactory">
<constructor-arg><ref local="velocityEngine"/></constructor-arg>
<property name="host">localhost</property>
<property name="fromEmail">myApp@mstanley.net</property>
</bean>
<bean id="velocityEngine"
class="org.springframework.ui.velocity.VelocityEngineFactoryBean">
<property name="velocityProperties">
<props>
<prop key="resource.loader">class</prop>
<prop key="class.resource.loader.class">
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
</prop>
</props>
</property>
</bean>
My client code simply becomes:
TemplateEmail email = emailFactory.createEmail(toList, ccList);
email.setSubject("Some meaningful subject");
email.setPlainTextTemplate("velocity/mail/SampleEmail.vm");
email.send();
I'll send the interface, abstract implementation, and Velocity
implementation of TemplateEmail and email factory.
With this approach VelocityEmailFactory and VelocityEmail can become
"template mail adapters". These adapters can be additional modules.
Thoughts?
- Mike
>
> Mvgr,
> Martin
>
> On Fri, 2004-10-01 at 01:58, Joe Germuska wrote:
> > At 12:54 PM -0700 9/30/04, Martin Cooper wrote:
> > > > 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 ;-).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Please add new build to ibiblio
Posted by Martin van den Bemt <ml...@mvdb.net>.
Maybe this has a better home at velocity ?
Mvgr,
Martin
On Fri, 2004-10-01 at 01:58, Joe Germuska wrote:
> At 12:54 PM -0700 9/30/04, Martin Cooper wrote:
> > > 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 ;-).
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [email] Please add new build to ibiblio
Posted by Joe Germuska <Jo...@Germuska.com>.
At 12:54 PM -0700 9/30/04, Martin Cooper wrote:
> > 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 ;-).
>
>I'd prefer to avoid a required build-time dependency on something like
>Velocity. Better would be to borrow the approach Commons Chain uses,
>and only build Velocity-specific code if the Velocity jar is present.
I'm kind of ambivalent about this approach. I would be concerned
that you'd be building jars which are supposed to represent the same
artifact but which have different contents based on the build
circumstances. I guess also since I'm generally accustomed to using
Maven for builds, I don't really see the gain in conditional
compilation, because satisfying dependencies is automatic.
Do you suggest the conditional compilation because you don't want
people to have to bother with the dependency? Or because you want to
make it possible for people to keep the Velocity dependency out of
their commons-email jar for some reason?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org