The only clean place I could see would be a new module of VFS so it does not introduce a new dependency to commons-mail, I am not sure if this one class is worth the work and management overhead for a new jar.
As sample code we could put it in the Maven site or maybe as a test dependency? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Xeno Amess <xenoam...@gmail.com> Gesendet: Wednesday, May 27, 2020 12:16:22 PM An: Commons Developers List <dev@commons.apache.org> Betreff: Re: [email and vfs] about adding class FileObjectDataSource Yeh that is the function I used. I want to put the class FileObjectDataSource I made to some repo, because I think it is somehow useful, and everybody who use commons-vfs&&commons-email will benefit from it. but I just don't know where should I put it to. Siegfried Goeschl <siegfried.goes...@gmail.com> 于2020年5月27日周三 下午6:11写道： > Hi, > > I do not fully understand the problem - AFAIK there is an attach method > which takes a DataSource sou can just pass your FileObjectDataSource? > > But I guess I miss something here :-) > > Thanks in advance, > > Siegfried Goeschl > > > > On 27.05.2020, at 11:30, Xeno Amess <xenoam...@gmail.com> wrote: > > > > Hi. > > I'm trying to maintain commons-email today, and I want to make a new > class > > FileObjectDataSource, who implements javax.activation.DataSource. > > But things is not as easy as I want. > > 1. the reason. > > the reason for making such a class is when last month I was doing some > > school work for graduation project, and in that system I need a backend > > server to send emails. > > And I want to attach some FileObject (from vfs) as attachments of the > > emails sent, so I have to make a class FileObjectDataSource (something > > which is actually very similar to javax.activation.FileDataSource but > > dealing not File but FileObject). > > then I thought this class might be helpful to others, so I want to put it > > into some place. > > the question is, where shall I put it? commons-email, or commons-vfs? > > 2. commons-email. > > start with commons-email. > > If I make such a class into commons-email, then commons-email must add > > commons-vfs as a dependency. > > which sounds crazy to implement so small a feature to include a large new > > dependency. > > 3. commons-vfs > > If I make such a class into commons-vfs, then some worse things might > > happen. > > First, the javax.activation.DataSource is actually deleted since jdk11, > and > > commons-email use [jakarta.mail] for Infrastructure, whitch contains a > copy > > of javax.activation.DataSource. > > So commons-vfs must make [jakarta.mail] as a dependency. > > which sounds crazy to implement so small a feature to include a large new > > dependency. > > Second, [jakarta.mail] is actually 2.0rc now, and they claimed they > would > > release 2.0 soon. > > and in jakarta2.0, all uses of javax.activation.DataSource will be > > replaced by jakarta.activation.DataSource. > > Also, it is not actually related to vfs itself, but only a usage of vfs, > so > > I don't think it good to be added to vfs. > > 4. so maybe I should make another repo for storing such a class? > > man, starting a repo for a single class sounds crazy. > > 5. any better ideas? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
