This sounds legitimate to me.

Across the line, there is however the thought that the main - if not
only - delivery of the Apache James project is a mail server.

Things like mailet-api, mailbox, protocols will end up with the same
naming than some over server components like (say) queue.

I personally agree with such a statement. I wonder if it could bring
further discussions here.

I also agree on the "iterative" approach.

Cheers,

Benoit

Le 13/11/2020 à 17:39, Jean Helou a écrit :
>>  >  Here is why I chose this naming scheme instead of the prevalent one in
>> the
> 
>> guice module:
>>> - I felt the `james-server` prefix which is in most artifact names
>> doesn't
>>> bring much. There are a few other modules which dropped the prefix in
>>> `server/container/guice` , and I prefer the lighter names. I am
>> considering
>>> also dropping the prefix from the 2 other queue modules in
>>> `server/container/guice/queue` if I get positive feedback.
>>
>> Overall +1 but imo we should be consistent.
>>
>> Maybe we should rename them all, or rename none.
>>
> 
> I don't think that's a viable option, at least not in a single PR. It would
> entail a modification of almost every single POM files in the project,
> that in turn has impacts on almost everything (docker images, build
> scripts, documentation, etc which contain various references to artifact
> names)
> 
> As an experiment, I attempted moving the `server/app` module to
> `/server/assemblies/spring-jpa-activemq` because I wanted to separate
> modules which produce actual runnable apps away from modules that only
> define binding modules
> I also renamed the artifact to something a bit closer to what was done for
> the guice based apps.
> This ended up in an evening of tracking dependencies and references all
> over the place and I'm not entirely confident that my end result is
> correct, I dropped that effort.
> 
> A more feasible approach would be to incrementally rename the modules I
> will be touching/needing to build my SMTP only relay and their immediate
> siblings.
> I thus would submit a sequence of PRs to do so, If I identify easy wins
> doing that I´ll include them as well.
> If everyone takes a bit of time to similarly rename the modules they are
> immediately working on this could converge
> 
> I´ll list the modules I intend to rename here in each PR to limit conflicts
> with other's work
> 
> jean
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to