[
https://issues.apache.org/jira/browse/JAMES-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150415#comment-17150415
]
Ioan Eugen Stan edited comment on JAMES-2877 at 7/2/20, 4:17 PM:
-----------------------------------------------------------------
While working on the gradle migration I've noticed that you produce a lot of
similar artifacts.
In issue https://issues.apache.org/jira/browse/JAMES-3273 [~btellier]
mentioned these modules.
{noformat}
server/container/guice/cassandra-guice
server/container/guice/cassandra-ldap-guice
server/container/guice/cassandra-rabbitmq-guice
server/container/guice/cassandra-rabbitmq-ldap-guice
{noformat}
While analyzing them I noticed a few things that I am going to present.
Please keep in mind they are opinions and
* they are applications - which is nice
* they are coupled (one depends on antother) - which is not nice since they are
applications and not libraries
* they are very similar an we can avoid some /all of them by merging them
together.
We can have multiple main classes in a single Jar file and we can specify the
main class when we start the application.
I don't think we should provide too many pre-built configurations out of the
box for many reasons, but mainly it is a maintenance cost.
Since they share so much I do think that we can bundle all jars and have a 1-2
Cassandra offerings with multiple main classes.
We can have the same for the other projects.
My personal opinion is that we should keep it simple for our basic users.
We should provide more documentation and examples on how they can build their
own distributions instead of us providing many distributions for them.
We can provide an example repo like this
https://github.com/ieugen/james-self-hosting-sandbox/ .
I've built the above repo to serve as an example for who wants to build their
own James distribution.
With an example like that and documentation on how to configure each server
(SMTP, IMAP, etc) I think we can avoid publishing a lot of binaries that people
will probably expect us to maintain and offer support.
was (Author: ieugen):
While working on the gradle migration I've noticed that you produce a lot of
similar artifacts.
In issue https://issues.apache.org/jira/browse/JAMES-3273 [~btellier]
mentioned these modules.
{noformat}
server/container/guice/cassandra-guice
server/container/guice/cassandra-ldap-guice
server/container/guice/cassandra-rabbitmq-guice
server/container/guice/cassandra-rabbitmq-ldap-guice
{noformat}
While analyzing them I noticed a few things that I am going to present.
Please keep in mind they are opinions and
* they are applications - which is nice
* they are coupled (one depends on antother) - which is not nice since they are
applications and not libraries
* they are very similar an we can avoid some /all of them by merging them
together.
We can have multiple main classes in a single Jar file and we can specify the
main class when we start the application.
I don't think we should provide too many pre-built configurations out of the
box for many reasons, but mainly it is a maintenance cost.
Since they share so much I do think that we can bundle all jars and have a 1-2
Cassandra offerings with multiple main classes.
We can have the same for the other projects.
My personal opinion is that we should keep it simple for our basic users.
We should provide more documentation and examples on how they can build their
own distributions instead of us providing many distributions for them.
> release process should deploy and generate more artifacts
> ---------------------------------------------------------
>
> Key: JAMES-2877
> URL: https://issues.apache.org/jira/browse/JAMES-2877
> Project: James Server
> Issue Type: Improvement
> Components: Build System
> Affects Versions: 3.4.0
> Reporter: Matthieu Baechler
> Priority: Major
>
> During the release of James, we lack some artifacts that in theory should be
> part of the staging repository before the vote then would go to Apache Dist
> when releasing.
> Here is the list of artifacts we should produce and deploy to staging:
> - the zip file containing all the source code (it's generated but not
> uploaded)
> - a zip file for each product we provide with compiled artifacts (spring-app
> is handled but guice products are not)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
