La 18.05.2020 03:02, David Leangen a scris: >> I think it is a good initiative. since mie4j is a library, and a lower >> level one, we can announce the change intention on the mailing list. > > Ok, thanks. > > Since we’re on the topic… > > What is the purpose of having multiple jars? Why is the project organized the > way it is? > > I am saying this without knowing much about Mime4j… but IMO a library jar > should be really simple to integrate. It would be simpler to have one and > only one release jar, which includes the API, implementation, and all the > dependencies bundled together. By the way, ideally there should not be any > transitive dependencies. Those are definitely the best libraries! > > In a nutshell, as a library we should be thinking more about the users, and > less about the developers, as there are likely many more users than > developers. The users just want to integrate the library with as few > headaches as possible, so reducing dependencies is critical, i.e. only a > single released jar with zero transitive dependencies should be the goal.
Hi, Very good points. I will try to answer as best I can. Please use this in the documentation we are building. From Maven we get: [INFO] Reactor Build Order: [INFO] [INFO] Apache James :: Mime4j :: Project [pom] [INFO] Apache James :: Mime4j :: Core [bundle] [INFO] Apache James :: Mime4j :: DOM [bundle] [INFO] Apache James :: Mime4j :: Storage [bundle] [INFO] Apache James :: Mime4j :: Benchmarks [bundle] [INFO] Apache James :: Mime4j :: Mbox Iterator [bundle] [INFO] Apache James :: Mime4j :: Code Examples [bundle] [INFO] Apache James :: Mime4j :: Assembly [pom] [INFO] Apache James :: Mime4j :: James utils [bundle] == Apache James :: Mime4j :: Project Contains common configuration for the other projects. Groups the other modules together. == Apache James :: Mime4j :: Core Contains the core API for working with email content and email the email parts. You can find code and structure to work with: headers, body, fields, mime format, quoted printed characters and other email specific elements (dictated by RFC's). Contains low level utilities and code to deal with parsing the mime format mostly. == Apache James :: Mime4j :: DOM Contains higher level structure. Here we deal with email address, different body types (text, binary, single, multipart), email message. We also have concepts of: mailbox, groups, domain lists, etc. This converts a mime message format and builds a document model that exposes the email elements, instead of the low level data format used to transfer email. == Apache James :: Mime4j :: Storage Provides different providers to store and retrieve emails. It deals only with one email so it's not a replacement for Apache James Mailbox API. It deals with storing parts of the email in memory and on disk, transparent encryption for emails during storage and other related strategies. == Apache James :: Mime4j :: Mbox Iterator I wrote this module because I needed a fast way to iterate over thousands of emails in a single mbox file. It uses memory mapped files and it very efficient. It's an utility when you need to import/export to mbox. Should not be packaged with the library. The other projects are self explanatory: - Benchmarks: simple benchmarks for mime4j parsing speed. Should not be bundled with the library IMO. Keep separate. - Code examples: How to use the libraries. Examples should be added to docs. - Assembly - builds the binary distributions for release: zip and others. > > I am not very familiar with Maven. Is it possible to bundle together > everything as a single jar even if it is separated into different projects? > > —> If yes: we could keep the same project structure, but only deploy a > single jar. > —> If no: we could restructure the project. This would only affect > developers. Yes it is possible to bundle a single jar out of the others. I've been off of Maven for some time myself but if I remember correctly, Maven assembly plugin could work. https://maven.apache.org/plugins/maven-assembly-plugin/index.html Maven Shade plugin is another option (better suited I think) https://maven.apache.org/plugins/maven-shade-plugin/ > > The question is: do others agree about my assessment? > It's debatable. It's very easy for them to build the assembly if they need to. We could offer something like this and/or write the documentation on how they can do it ? I'm not the best to ask what the users of mime4j need. And if they nobody complained about it I guess it's not that big of a deal in practice. IMO: Provide docs, give the users options, be as lazy as possible :). > With regards to the currently released jars and the project organization: > > * core - ideally deployed as mime4j (drop the “core” as there would be only > a single jar) > * dom - I understand that there is a cohesion thing going on as this is all > related to “dom”… > —> But is this even useful on its own? Why is it separate from the core? > * utils - really? There is only a single class!! > * examples - why deploy this as a jar?? People who really want a jar could > just build it. > * mbox-iterator - again, really? There are only 3 classes? Why create so > much pain? > * storage - There are a few more classes here, but the real question is: > what does this do? > —> Depending on the purpose, it may or may not be preferable to deploy > separately > * benchmark - what is this for? Perhaps it could be deployed, but does > anybody even use this? > > As part of my documentation project, if I can understand these better, I > could help to create some basic documentation. Since the project is tiny > enough, I could help reorganize in a push for a 1.0.0 release. > > Please let me know what you think. I'm not against keeping them together or separate. I am lazy enough to not change things that work and for which there is no incentive to do the work. Bundling them together means that people will get some extra classes, even if they don't use them. The project is small so that might not be a big issue. If we go the change route, here are my thoughts: Storage can be merged with dom, brings in commons-io - we might ditch or shade commons-io to avoid transitive dependencies. Mbox can be merged in core or storage perhaps? Utils !?? Examples, benchmarks should stay separate. If we decide for unification, we might end up with: - mime4j: core + dom + storage + utils + mbox - examples - benchmarks - assembly I hope this helps. > Cheers, > =David > >
