> 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.
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.
The question is: do others agree about my assessment?
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.
Cheers,
=David
