Hi, Please use Eugen. That is my given name. Stan is my family name.
La 11.06.2020 11:27, Tellier Benoit a scris: > On 10/06/2020 15:19, Eugen Stan wrote: >> I'm mostly referring to libraries. Having a library bring a dependency >> like scala is a no-no on my part. >> >> Ideally the lower parts of James should not bring any dependencies. >> Guava is also big and I would like to see that gone as well. >> >> [...] > Hello Stan, > > It is unclear to me what you actually call a library. > > Could you provide us with an explanation? Maybe with a list of what you > consider being libraries within the James project? > > I think sharing your thoughts here would help reaching a common vision. Sure. I'll give it a try. My version of a library definition is: "A library is a piece of code that is designed to used by other pieces of code (libraries or applications). It encapsulates some behaviors that are specific to an area. It's designed to be reused. It targets developers." Examples of libraries from James: - mime4j - the mailbox implementations - the protocol implementations: smtp, lmtp, etc There can be libraries internal to a project and not very useful outside of the project, because they are specific. I think james-core fits this profile and some others. Libraries can depend on internal libraries - since they form a closed world (of course the other libraries should have no or few external dependencies). For an application: Something that is meant to be used "as is" by end users (download and run). It can be customized and tweaked by end user (branding, change implementations, etc). Examples of applications in James: - James Server - all the flavors - mbox parser - mpt Please keep in mind that a single piece of source code can be packaged in many forms for delivery. Taking the mailbox import/export functionality as an example we could have it part of the James server and we could have it packaged as a CLI application that is distributed separately . The core functionality of import/export in the above examples is the same, however each use case comes with it's specifics and might (will) bring in other dependencies and steps: the CLI will probably require an argument parsing library. The binaries for the CLI could be built for arm64, amd64, etc. When talking about libraries, we don't usually discuss all those points. Libraries should be small and focused. They should have minimal / no dependencies (maybe logging). Libraries can be used to compose one or many applications (via guice modules or spring beans) as we do for James Server. IMO the composability part should not be in the library (no spring annotations like @Component or @Autowired, probably not @Inject either). Libraries following the above guidelines/rules are usually very stable and very easy to upgrade. They compose easily. Please share your feedback on this. The list of libraries is not complete. Regards, -- Eugen Stan +40720 898 747 / netdava.com
<<attachment: eugen_stan.vcf>>
signature.asc
Description: OpenPGP digital signature
