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
