Sorry, https://github.com/XenoAmess/commons-vfs2-email I mean.
Xeno Amess <xenoam...@gmail.com> 于2020年5月27日周三 下午10:46写道： > Oh as related. > I put this poor little thing at > https://github.com/XenoAmess/commons-vfs2-email/blob/master/pom.xml for > now. > If anybody need it just grab it. > > Xeno Amess <xenoam...@gmail.com> 于2020年5月27日周三 下午6:26写道： > >> > I am not sure if this one class is worth the work and management >> overhead for a new jar. >> me neither:-) >> >> Bernd Eckenfels <e...@zusammenkunft.net> 于2020年5月27日周三 下午6:19写道： >> >>> 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 >>> > >>> > >>> >>
