[jira] [Commented] (JAMES-3674) Support password salting and hash scheme upgrading
[
https://issues.apache.org/jira/browse/JAMES-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447261#comment-17447261
]
Ioan Eugen Stan commented on JAMES-3674:
+1 for doing things right the first time and for stronger crypto.
I don't care what or if any crypto lib is used.
Using no crypto lib is preferale if code is simple enough.
> Support password salting and hash scheme upgrading
> --
>
> Key: JAMES-3674
> URL: https://issues.apache.org/jira/browse/JAMES-3674
> Project: James Server
> Issue Type: Improvement
> Components: UsersStore UsersRepository
>Affects Versions: master
>Reporter: Karsten Otto
>Priority: Major
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> Currently, James does not use salt during password hashing, so its password
> database is vulnerable to rainbow table cracking if someone ever manages to
> steal it. Furthermore, there is no mechanism to upgrade user passwords to
> stronger/different hashing once they are created (cf. legacy hashing mode).
> This is a problem for any installation that does not employ an external LDAP
> user database.
> A simple solution is to include the user name as salt in the password hash.
> For this purpose, the {{hashingMode}} choices in {{usersrepository.xml}}
> should include an new mode "salted" in addition to "legacy" and "default".
> Additionally, the database should include an explicit column in the user
> table, which specifies the {{hashingMode}} of the stored password, and is
> used during verification. However, when a user changes the password, the
> configured {{algorithm}} and {{hashingMode}} from {{usersrepository.xml}}
> will be used instead. This way, the database gradually upgrades over time to
> the preferred setting.
> T-Shirt size L.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3674) Support password salting and hash scheme upgrading
[
https://issues.apache.org/jira/browse/JAMES-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446127#comment-17446127
]
Ioan Eugen Stan commented on JAMES-3674:
Also, the username could change and the password would fail.
Salt should be stored as a value in DB next to password.
To prevent password cracking the hashing is done multiple times by the
algorithm and it's intentionally slow.
Slowness can usually be configured to be 500 ms, 1000ms ,etc.
> Support password salting and hash scheme upgrading
> --
>
> Key: JAMES-3674
> URL: https://issues.apache.org/jira/browse/JAMES-3674
> Project: James Server
> Issue Type: Improvement
> Components: UsersStore UsersRepository
>Affects Versions: master
>Reporter: Karsten Otto
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Currently, James does not use salt during password hashing, so its password
> database is vulnerable to rainbow table cracking if someone ever manages to
> steal it. Furthermore, there is no mechanism to upgrade user passwords to
> stronger/different hashing once they are created (cf. legacy hashing mode).
> This is a problem for any installation that does not employ an external LDAP
> user database.
> A simple solution is to include the user name as salt in the password hash.
> For this purpose, the {{hashingMode}} choices in {{usersrepository.xml}}
> should include an new mode "salted" in addition to "legacy" and "default".
> Additionally, the database should include an explicit column in the user
> table, which specifies the {{hashingMode}} of the stored password, and is
> used during verification. However, when a user changes the password, the
> configured {{algorithm}} and {{hashingMode}} from {{usersrepository.xml}}
> will be used instead. This way, the database gradually upgrades over time to
> the preferred setting.
> T-Shirt size L.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3674) Support password salting and hash scheme upgrading
[
https://issues.apache.org/jira/browse/JAMES-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446126#comment-17446126
]
Ioan Eugen Stan commented on JAMES-3674:
My recommendation is to avoid rolling your own password hashing (and crypto in
general) and instead adopt an industry standard methodology.
There are a few standardized password hashing algorithms that are used by other
tools and if we adopt them, passwords could be checked by standard tools and
even copied to otehr systems that use the same hashing algorightms.
Modern current hashing algorithms:
PBKDF2
bcrypt
scrypt
Argon2
Apache licensed library that can hash using those algorithms:
[https://github.com/Password4j/password4j]
Other solutions might exist.
> Support password salting and hash scheme upgrading
> --
>
> Key: JAMES-3674
> URL: https://issues.apache.org/jira/browse/JAMES-3674
> Project: James Server
> Issue Type: Improvement
> Components: UsersStore UsersRepository
>Affects Versions: master
>Reporter: Karsten Otto
>Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Currently, James does not use salt during password hashing, so its password
> database is vulnerable to rainbow table cracking if someone ever manages to
> steal it. Furthermore, there is no mechanism to upgrade user passwords to
> stronger/different hashing once they are created (cf. legacy hashing mode).
> This is a problem for any installation that does not employ an external LDAP
> user database.
> A simple solution is to include the user name as salt in the password hash.
> For this purpose, the {{hashingMode}} choices in {{usersrepository.xml}}
> should include an new mode "salted" in addition to "legacy" and "default".
> Additionally, the database should include an explicit column in the user
> table, which specifies the {{hashingMode}} of the stored password, and is
> used during verification. However, when a user changes the password, the
> configured {{algorithm}} and {{hashingMode}} from {{usersrepository.xml}}
> will be used instead. This way, the database gradually upgrades over time to
> the preferred setting.
> T-Shirt size L.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3639) Allow to configure SSL from PEM keys (without a keystore)
[
https://issues.apache.org/jira/browse/JAMES-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412450#comment-17412450
]
Ioan Eugen Stan commented on JAMES-3639:
Does it work with letsencrypt certificates ?
Should we add an issue for that?
[https://letsencrypt.org/docs/faq/#does-let-s-encrypt-issue-certificates-for-anything-other-than-ssl-tls-for-websites]
NOTE: The certificates are renewed periodically we might need a solution to
reload them in James.
Restart is a valid solution but we might be able to do a reload as well.
> Allow to configure SSL from PEM keys (without a keystore)
> -
>
> Key: JAMES-3639
> URL: https://issues.apache.org/jira/browse/JAMES-3639
> Project: James Server
> Issue Type: Improvement
> Components: IMAPServer, JMAP, POP3Server, SMTPServer
>Reporter: Benoit Tellier
>Assignee: Antoine Duprat
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> This gives the opportunity to inter-operate directly with OpenSSL formats and
> avoids some potentially tricky configuration steps (importing the keys in a
> keystore).
> Read related thread on the mailing list:
> https://www.mail-archive.com/server-dev@james.apache.org/msg70772.html
> How this looks like:
> {code:java}
>
> file://conf/private.nopass.key
> file://conf/certs.self-signed.csr
>
> {code}
> Tested manually with self signed certificates:
> {code:java}
> # Generating your private key
> openssl genrsa -des3 -out private.key 2048
> # Creating your certificates
> openssl req -new -key private.key -out certs.csr
> # Signing the certificate yourself
> openssl x509 -req -days 365 -in certs.csr -signkey private.key -out
> certs.self-signed.csr
> # Removing the password from the private key
> # Not necessary if you supply the secret in the configuration
> openssl rsa -in private.key -out private.nopass.key
> {code}
--
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
[jira] [Closed] (JAMES-3209) Auth Module to make James usable with Nginx mail proxy for TLS termination
[ https://issues.apache.org/jira/browse/JAMES-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan closed JAMES-3209. -- Resolution: Later > Auth Module to make James usable with Nginx mail proxy for TLS termination > --- > > Key: JAMES-3209 > URL: https://issues.apache.org/jira/browse/JAMES-3209 > Project: James Server > Issue Type: New Feature > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Attachments: docker-compose.yaml, nginx.conf > > > Apache James needs to be deployed with TLS encryption to ensure security of > emails during transport. > We could use Nginx as a mail proxy and use it for TLS termination. > However we need to implement an HTTP auth service for that to work. > This issue should cover work on making Nginx a valid mail proxy in front of > Apache James. > References: > https://docs.nginx.com/nginx/admin-guide/mail-proxy/mail-proxy/ > https://nginx.org/en/docs/mail/ngx_mail_auth_http_module.html#protocol > == Context > Unfortunately, Java has only the keystore for managing TLS certificates. This > is makes deploying TLS certificates hard for Apache James since the internet > does not use. keystore format. > We could use Nginx as a amil proxy. Nginx supports the certificate format > that all other tools use. (add format here - PKCS #XXX ). People know how to > setup Nginx with LetsEncrypt and benefit from free TLS certificates with > automatic renewal. > However we need an integration piece: the nginx auth service. It's an http > service that works only with headers. It should be simple to write and work > integrate. -- 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
[jira] [Commented] (JAMES-3209) Auth Module to make James usable with Nginx mail proxy for TLS termination
[ https://issues.apache.org/jira/browse/JAMES-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412447#comment-17412447 ] Ioan Eugen Stan commented on JAMES-3209: I think we can close this one yes. Nginx might be a viable solution but I'm not working on it right now. Thanks for all the work [~btellier] ! > Auth Module to make James usable with Nginx mail proxy for TLS termination > --- > > Key: JAMES-3209 > URL: https://issues.apache.org/jira/browse/JAMES-3209 > Project: James Server > Issue Type: New Feature > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Attachments: docker-compose.yaml, nginx.conf > > > Apache James needs to be deployed with TLS encryption to ensure security of > emails during transport. > We could use Nginx as a mail proxy and use it for TLS termination. > However we need to implement an HTTP auth service for that to work. > This issue should cover work on making Nginx a valid mail proxy in front of > Apache James. > References: > https://docs.nginx.com/nginx/admin-guide/mail-proxy/mail-proxy/ > https://nginx.org/en/docs/mail/ngx_mail_auth_http_module.html#protocol > == Context > Unfortunately, Java has only the keystore for managing TLS certificates. This > is makes deploying TLS certificates hard for Apache James since the internet > does not use. keystore format. > We could use Nginx as a amil proxy. Nginx supports the certificate format > that all other tools use. (add format here - PKCS #XXX ). People know how to > setup Nginx with LetsEncrypt and benefit from free TLS certificates with > automatic renewal. > However we need an integration piece: the nginx auth service. It's an http > service that works only with headers. It should be simple to write and work > integrate. -- 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
[jira] [Commented] (JAMES-3360) Change "User Repository" to "User Directory"
[
https://issues.apache.org/jira/browse/JAMES-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180551#comment-17180551
]
Ioan Eugen Stan commented on JAMES-3360:
Hi,
To me user store , user repository, user directory are interchangeable in this
context.
However there are some details that might count against the name change.
Are you talking about renaming the documentation or also the Java code?
If it's just documentation rename we will have 2 names: Directory and
Repository.
If it's also Java code, then you will probably break some API.
UserRepository is an interface that other people implement when they store
users in other places.
To me the value the rename brings is not worth the trouble and time spent to
update the docs and the Java code and also break other people's implementations.
> Change "User Repository" to "User Directory"
>
>
> Key: JAMES-3360
> URL: https://issues.apache.org/jira/browse/JAMES-3360
> Project: James Server
> Issue Type: Improvement
>Reporter: David Leangen
>Priority: Major
>
> I wonder if there isn't a wording problem here.
> I understand that the idea is to have a place to store user data. However,
> the naming looks at the problem from a purely technical point of view. A
> "Repository" by definition is a place to "put" something. For example, in the
> real world, a document repository is an actual place to put documents.
> The wording suggests that we have some place where we put people, which seems
> very strange to me if we correspond the idea to the real world. It creates a
> very strange mental model for me.
> I think the concept that should be modeled here is more along the lines of a
> "Directory". We have a kind of index that gives useful information about how
> to locate users. It is not a place where we take people and lock them up.
> Rather, it is a list of information about people. Does that make sense?
> [Here is a
> definition|https://dictionary.cambridge.org/dictionary/english/directory] we
> could use:
> {quote}a list of telephone numbers, names, addresses, or other information
> {quote}
> Note that if the Repository is never exposed to anybody except implementors,
> and it really is just a place to put data, then this issue would not bother
> me. However, it is my understanding from writing the new documents that this
> concept is actually exposed, so I think the concept needs to be fixed.
--
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
[jira] [Commented] (JAMES-3360) Change "User Repository" to "User Directory"
[
https://issues.apache.org/jira/browse/JAMES-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180445#comment-17180445
]
Ioan Eugen Stan commented on JAMES-3360:
I'm not a native speaker so take this with a bit of salt :).
The change is mostly wording as you say and IMO not something to spend much
time on it .
As long as it's documented how it works we can name it however we want.
I think the name comes from the repository pattern which is not far from what
it does: [https://deviq.com/repository-pattern/]
Directory is more of a read-only thing (not necessarily) while repository is
read/write.
I think in James we can have both types, depending on who maintains the user
list: James (we have rw or another system - we will have just read access most
likely)
https://www.merriam-webster.com/dictionary/repository
> Change "User Repository" to "User Directory"
>
>
> Key: JAMES-3360
> URL: https://issues.apache.org/jira/browse/JAMES-3360
> Project: James Server
> Issue Type: Improvement
>Reporter: David Leangen
>Priority: Major
>
> I wonder if there isn't a wording problem here.
> I understand that the idea is to have a place to store user data. However,
> the naming looks at the problem from a purely technical point of view. A
> "Repository" by definition is a place to "put" something. For example, in the
> real world, a document repository is an actual place to put documents.
> The wording suggests that we have some place where we put people, which seems
> very strange to me if we correspond the idea to the real world. It creates a
> very strange mental model for me.
> I think the concept that should be modeled here is more along the lines of a
> "Directory". We have a kind of index that gives useful information about how
> to locate users. It is not a place where we take people and lock them up.
> Rather, it is a list of information about people. Does that make sense?
> [Here is a
> definition|https://dictionary.cambridge.org/dictionary/english/directory] we
> could use:
> {quote}a list of telephone numbers, names, addresses, or other information
> {quote}
> Note that if the Repository is never exposed to anybody except implementors,
> and it really is just a place to put data, then this issue would not bother
> me. However, it is my understanding from writing the new documents that this
> concept is actually exposed, so I think the concept needs to be fixed.
--
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
[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168308#comment-17168308 ] Ioan Eugen Stan commented on JAMES-3226: Thanks. Antora allows us to have an index page in the playbook, see https://docs.antora.org/antora/2.3/playbook/site-start-page/ We can put whatever content we want there, including this list. I think this should be kept in james-site . Also, I'm more focused on migrating (and verifing) the existing documentation to asciidoc/antora. Once we have that it's going to be much more clear how the structure is going to look. Some antora component renaming might be in order. The current name for james-project component is `main` which IMO should change to james-project (or even to james-server ?!). > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Attachments: Captură de ecran de la 2020-07-31 02-34-10.png > > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168300#comment-17168300 ] Ioan Eugen Stan commented on JAMES-3226: Added docs stubs to all repositories. !Captură de ecran de la 2020-07-31 02-34-10.png! > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Attachments: Captură de ecran de la 2020-07-31 02-34-10.png > > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Updated] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan updated JAMES-3226: --- Attachment: Captură de ecran de la 2020-07-31 02-34-10.png > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Attachments: Captură de ecran de la 2020-07-31 02-34-10.png > > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Commented] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168041#comment-17168041 ] Ioan Eugen Stan commented on JAMES-3225: Automated builds done with https://issues.apache.org/jira/browse/INFRA-20559 . > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Commented] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159663#comment-17159663 ] Ioan Eugen Stan commented on JAMES-3225: Goodbye builds.apache.org, hello [https://ci-builds.apache.org/job/james/] . Infra is working to replace builds.a.o with [https://ci-builds.apache.org/job/james/] . I've worked with Gavin and setup James project builds there. > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17157582#comment-17157582 ] Ioan Eugen Stan commented on JAMES-3226: [~dleangen]: I'll come back with something in the near future. I'm a bit busy myself. In the mean time I created https://issues.apache.org/jira/browse/INFRA-20518 > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156400#comment-17156400 ] Ioan Eugen Stan commented on JAMES-3226: [~dleangen]: I've added the ui-bundle as part of the `live` branch. In the next days I'll focus a bit on the website structure and the theme. > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156374#comment-17156374 ] Ioan Eugen Stan commented on JAMES-3226: Thanks David. I've read Antora's documentation and now I am going to start working on the site and improve the structure. My first goal is to replace james-site#master branch with a new one that will contain the build code. We will probably have a branch for live and one for staged environment. They will publish to asf-site that will update https://james.apache.org and asf-staged that will get to [https://james.staged.apache.org|https://james.staged.apache.org/] . > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Commented] (JAMES-3301) Create old site inventory
[
https://issues.apache.org/jira/browse/JAMES-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155270#comment-17155270
]
Ioan Eugen Stan commented on JAMES-3301:
I'm focusing on migrating them now and we can decide later how to structure and
what to keep.
My main concern right now is to make the list and not have documents slip
through the cracks.
All documentation should be under docs/ and we should reference it in other
places via link.
Even the README should be slimmed down and each section should be a link to the
relevant docs section.
> Create old site inventory
> --
>
> Key: JAMES-3301
> URL: https://issues.apache.org/jira/browse/JAMES-3301
> Project: James Server
> Issue Type: Sub-task
> Reporter: Ioan Eugen Stan
> Assignee: Ioan Eugen Stan
>Priority: Major
>
> Before we move forward with the site we need to build an inventory of what we
> have.
>
> We seem to have, in james-project the following:
>
> {noformat}
> tree -d src/
> src/
> ├── adr
> ├── homepage
> │ ├── assets
> │ │ ├── css
> │ │ │ └── images
> │ │ ├── fonts
> │ │ ├── images
> │ │ └── js
> │ │ └── ie
> │ ├── howTo
> │ ├── images
> │ ├── _includes
> │ ├── _layouts
> │ └── _posts
> ├── reporting-site
> └── site
> ├── apt
> │ ├── mailet
> │ │ └── examples
> │ └── mpt
> ├── custom
> ├── markdown
> │ ├── mailet
> │ └── server
> │ └── install
> ├── resources
> │ ├── css
> │ ├── downloads
> │ ├── images
> │ ├── js
> │ │ └── james
> │ ├── mailbox
> │ │ └── images
> │ │ └── uml
> │ ├── mailet
> │ │ └── css
> │ ├── model-eclipse-modeler
> │ ├── protocols
> │ │ └── images
> │ │ └── uml
> │ └── server
> │ ├── css
> │ ├── images
> │ │ ├── conf
> │ │ ├── database
> │ │ ├── dns-mx
> │ │ ├── eclipse
> │ │ ├── intellij-idea
> │ │ ├── jmx-management
> │ │ ├── jmx-monitoring
> │ │ ├── netbeans
> │ │ ├── performances
> │ │ └── uml
> │ ├── js
> │ └── rfclist
> │ ├── basic
> │ ├── imap4
> │ ├── ldap
> │ ├── lmtp
> │ ├── pop3
> │ └── smtp
> └── xdoc
> ├── mailbox
> ├── mailet
> │ ├── ai
> │ ├── api
> │ ├── base
> │ ├── crypto
> │ ├── mailetdocs-maven-plugin
> │ ├── standard
> │ └── stylesheets
> ├── mpt
> ├── protocols
> └── server
> └── archive75 directories
> {noformat}
>
>
> The content is in the following formats:
> * markdown
> * xdoc
> * apt ?!
> *We also have javadocs*
> Gradle has out of the box support for Javadoc.
> It's a matter of configuration and also aggregating them for publication.
>
>
>
--
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
[jira] [Commented] (JAMES-3302) Migrate old site pages to asciidoc
[ https://issues.apache.org/jira/browse/JAMES-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154989#comment-17154989 ] Ioan Eugen Stan commented on JAMES-3302: Fox xdoc and apt we can use Doxia Tools to convert to Dockbook and then from DocBook to Asciidoc with docbookrx . [https://maven.apache.org/doxia/doxia-tools/doxia-converter/index.html] [https://github.com/asciidoctor/docbookrx] If you know another way, let me lknow. > Migrate old site pages to asciidoc > -- > > Key: JAMES-3302 > URL: https://issues.apache.org/jira/browse/JAMES-3302 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > Once we have the inventory we should migrate the old content to Antora / > Asciidoc. > For most formats we could do an automated migration. > We might not migrate all components. > We will not migrate obsolete content. -- 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
[jira] [Commented] (JAMES-3302) Migrate old site pages to asciidoc
[ https://issues.apache.org/jira/browse/JAMES-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17154969#comment-17154969 ] Ioan Eugen Stan commented on JAMES-3302: We can migrate markdown with kramdoc [https://matthewsetter.com/technical-documentation/asciidoc/convert-markdown-to-asciidoc-with-kramdoc/] [https://github.com/asciidoctor/kramdown-asciidoc] . The results seem satisfactory for the adr documents. See [https://github.com/apache/james-project/pull/234] . > Migrate old site pages to asciidoc > -- > > Key: JAMES-3302 > URL: https://issues.apache.org/jira/browse/JAMES-3302 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > Once we have the inventory we should migrate the old content to Antora / > Asciidoc. > For most formats we could do an automated migration. > We might not migrate all components. > We will not migrate obsolete content. -- 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
[jira] [Assigned] (JAMES-3302) Migrate old site pages to asciidoc
[ https://issues.apache.org/jira/browse/JAMES-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan reassigned JAMES-3302: -- Assignee: Ioan Eugen Stan > Migrate old site pages to asciidoc > -- > > Key: JAMES-3302 > URL: https://issues.apache.org/jira/browse/JAMES-3302 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > Once we have the inventory we should migrate the old content to Antora / > Asciidoc. > For most formats we could do an automated migration. > We might not migrate all components. > We will not migrate obsolete content. -- 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
[jira] [Updated] (JAMES-3301) Create old site inventory
[
https://issues.apache.org/jira/browse/JAMES-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ioan Eugen Stan updated JAMES-3301:
---
Description:
Before we move forward with the site we need to build an inventory of what we
have.
We seem to have, in james-project the following:
{noformat}
tree -d src/
src/
├── adr
├── homepage
│ ├── assets
│ │ ├── css
│ │ │ └── images
│ │ ├── fonts
│ │ ├── images
│ │ └── js
│ │ └── ie
│ ├── howTo
│ ├── images
│ ├── _includes
│ ├── _layouts
│ └── _posts
├── reporting-site
└── site
├── apt
│ ├── mailet
│ │ └── examples
│ └── mpt
├── custom
├── markdown
│ ├── mailet
│ └── server
│ └── install
├── resources
│ ├── css
│ ├── downloads
│ ├── images
│ ├── js
│ │ └── james
│ ├── mailbox
│ │ └── images
│ │ └── uml
│ ├── mailet
│ │ └── css
│ ├── model-eclipse-modeler
│ ├── protocols
│ │ └── images
│ │ └── uml
│ └── server
│ ├── css
│ ├── images
│ │ ├── conf
│ │ ├── database
│ │ ├── dns-mx
│ │ ├── eclipse
│ │ ├── intellij-idea
│ │ ├── jmx-management
│ │ ├── jmx-monitoring
│ │ ├── netbeans
│ │ ├── performances
│ │ └── uml
│ ├── js
│ └── rfclist
│ ├── basic
│ ├── imap4
│ ├── ldap
│ ├── lmtp
│ ├── pop3
│ └── smtp
└── xdoc
├── mailbox
├── mailet
│ ├── ai
│ ├── api
│ ├── base
│ ├── crypto
│ ├── mailetdocs-maven-plugin
│ ├── standard
│ └── stylesheets
├── mpt
├── protocols
└── server
└── archive75 directories
{noformat}
The content is in the following formats:
* markdown
* xdoc
* apt ?!
*We also have javadocs*
Gradle has out of the box support for Javadoc.
It's a matter of configuration and also aggregating them for publication.
was:
Before we move forward with the site we need to build an inventory of what we
have.
> Create old site inventory
> --
>
> Key: JAMES-3301
> URL: https://issues.apache.org/jira/browse/JAMES-3301
> Project: James Server
> Issue Type: Sub-task
> Reporter: Ioan Eugen Stan
> Assignee: Ioan Eugen Stan
>Priority: Major
>
> Before we move forward with the site we need to build an inventory of what we
> have.
>
> We seem to have, in james-project the following:
>
> {noformat}
> tree -d src/
> src/
> ├── adr
> ├── homepage
> │ ├── assets
> │ │ ├── css
> │ │ │ └── images
> │ │ ├── fonts
> │ │ ├── images
> │ │ └── js
> │ │ └── ie
> │ ├── howTo
> │ ├── images
> │ ├── _includes
> │ ├── _layouts
> │ └── _posts
> ├── reporting-site
> └── site
> ├── apt
> │ ├── mailet
> │ │ └── examples
> │ └── mpt
> ├── custom
> ├── markdown
> │ ├── mailet
> │ └── server
> │ └── install
> ├── resources
> │ ├── css
> │ ├── downloads
> │ ├── images
> │ ├── js
> │ │ └── james
> │ ├── mailbox
> │ │ └── images
> │ │ └── uml
> │ ├── mailet
> │ │ └── css
> │ ├── model-eclipse-modeler
> │ ├── protocols
> │ │ └── images
> │ │ └── uml
> │ └── server
> │ ├── css
> │ ├── images
> │ │ ├── conf
> │ │ ├── database
> │ │ ├── dns-mx
> │ │ ├── eclipse
> │ │ ├── intellij-idea
> │ │ ├── jmx-management
> │ │ ├── jmx-monitoring
> │ │ ├── netbeans
> │ │ ├── performances
> │ │ └── uml
> │ ├── js
> │ └── rfclist
> │ ├── basic
> │ ├── imap4
> │ ├── ldap
> │ ├── lmtp
> │ ├── pop3
> │ └── smtp
> └── xdoc
> ├── mailbox
> ├── mailet
> │ ├── ai
> │ ├── api
> │ ├── base
> │ ├── crypto
> │ ├── mailetdocs-maven-plugin
> │ ├── standard
> │ └── stylesheets
> ├── mpt
> ├── protocols
> └── server
> └── archive75 directories
> {noformat}
>
>
> The co
[jira] [Created] (JAMES-3302) Migrate old site pages to asciidoc
Ioan Eugen Stan created JAMES-3302: -- Summary: Migrate old site pages to asciidoc Key: JAMES-3302 URL: https://issues.apache.org/jira/browse/JAMES-3302 Project: James Server Issue Type: Sub-task Reporter: Ioan Eugen Stan Once we have the inventory we should migrate the old content to Antora / Asciidoc. For most formats we could do an automated migration. We might not migrate all components. We will not migrate obsolete content. -- 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
[jira] [Created] (JAMES-3301) Create old site inventory
Ioan Eugen Stan created JAMES-3301: -- Summary: Create old site inventory Key: JAMES-3301 URL: https://issues.apache.org/jira/browse/JAMES-3301 Project: James Server Issue Type: Sub-task Reporter: Ioan Eugen Stan Assignee: Ioan Eugen Stan Before we move forward with the site we need to build an inventory of what we have. -- 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
[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152814#comment-17152814 ] Ioan Eugen Stan commented on JAMES-3226: We have automated build and publish via [https://builds.apache.org/view/J/view/ApacheJamesProjects/job/ApacheJames-Website/] . We have a staging website in [https://james.staged.apache.org/main/3.5/development/index.html] . > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Created] (JAMES-3298) Update information for
Ioan Eugen Stan created JAMES-3298: -- Summary: Update information for Key: JAMES-3298 URL: https://issues.apache.org/jira/browse/JAMES-3298 Project: James Server Issue Type: Sub-task Reporter: Ioan Eugen Stan The information here [https://projects.apache.org/project.html?james] ,is managed by the DOAP (Description of a project) file [https://github.com/apache/james-site/blob/master/doap_JAMES.rdf] . We should updated it to reflect current status (maybe generate it ?!) . -- 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
[jira] [Updated] (JAMES-3298) Update information for DOAP file - is outdated
[ https://issues.apache.org/jira/browse/JAMES-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan updated JAMES-3298: --- Summary: Update information for DOAP file - is outdated (was: Update information for ) > Update information for DOAP file - is outdated > -- > > Key: JAMES-3298 > URL: https://issues.apache.org/jira/browse/JAMES-3298 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan >Priority: Trivial > > The information here [https://projects.apache.org/project.html?james] ,is > managed by the DOAP (Description of a project) file > [https://github.com/apache/james-site/blob/master/doap_JAMES.rdf] . > > We should updated it to reflect current status (maybe generate it ?!) . -- 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
[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152158#comment-17152158 ] Ioan Eugen Stan commented on JAMES-3226: I thins we should use GitHub Pages for our staging website and use james.a.o (ASF Infra) for production [https://infra.apache.org/github-pages.html] . I'll setup a staging website for James so we can view it there. > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Resolved] (JAMES-3294) Incorporate Antora into the build process
[ https://issues.apache.org/jira/browse/JAMES-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan resolved JAMES-3294. Resolution: Fixed I believe with the work I did on [https://github.com/apache/james-site/pull/1] this is done. Right now we can run `./gradlew clean build` on james-site and we get: * gradle downloads and installs nodejs and antora * Gradle runs antora to build the website specified in doc-sites * doc-sites is a stub for now - but antora is integrated in the build process > Incorporate Antora into the build process > - > > Key: JAMES-3294 > URL: https://issues.apache.org/jira/browse/JAMES-3294 > Project: James Server > Issue Type: Sub-task >Reporter: David Leangen > Assignee: Ioan Eugen Stan >Priority: Major > Labels: Documentation > Attachments: ui-bundle.zip > > > It should be possible to include the Antora build for the documentation in > the build process, either (1) to be able to develop and view the documents > locally, or (2) to prepare for deployment. -- 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
[jira] [Assigned] (JAMES-3294) Incorporate Antora into the build process
[ https://issues.apache.org/jira/browse/JAMES-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan reassigned JAMES-3294: -- Assignee: Ioan Eugen Stan > Incorporate Antora into the build process > - > > Key: JAMES-3294 > URL: https://issues.apache.org/jira/browse/JAMES-3294 > Project: James Server > Issue Type: Sub-task >Reporter: David Leangen > Assignee: Ioan Eugen Stan >Priority: Major > Labels: Documentation > Attachments: ui-bundle.zip > > > It should be possible to include the Antora build for the documentation in > the build process, either (1) to be able to develop and view the documents > locally, or (2) to prepare for deployment. -- 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
[jira] [Commented] (JAMES-3294) Incorporate Antora into the build process
[ https://issues.apache.org/jira/browse/JAMES-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151788#comment-17151788 ] Ioan Eugen Stan commented on JAMES-3294: Sure, we can use also sub-task. Please add the files that you have available. I'll work on automating the site build process. I'll push a working draft version that we can then work on. > Incorporate Antora into the build process > - > > Key: JAMES-3294 > URL: https://issues.apache.org/jira/browse/JAMES-3294 > Project: James Server > Issue Type: Sub-task >Reporter: David Leangen >Priority: Major > Labels: Documentation > > It should be possible to include the Antora build for the documentation in > the build process, either (1) to be able to develop and view the documents > locally, or (2) to prepare for deployment. -- 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
[jira] [Commented] (JAMES-3294) Incorporate Antora into the build process
[ https://issues.apache.org/jira/browse/JAMES-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151762#comment-17151762 ] Ioan Eugen Stan commented on JAMES-3294: I've asked infra and they told me this is up to date: [https://infra.apache.org/project-site] . We have james-site where we can publish things: [https://github.com/apache/james-site/tree/asf-site] . I'll ask on ML for the current process. > Incorporate Antora into the build process > - > > Key: JAMES-3294 > URL: https://issues.apache.org/jira/browse/JAMES-3294 > Project: James Server > Issue Type: Sub-task >Reporter: David Leangen >Priority: Major > Labels: Documentation > > It should be possible to include the Antora build for the documentation in > the build process, either (1) to be able to develop and view the documents > locally, or (2) to prepare for deployment. -- 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
[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151317#comment-17151317 ] Ioan Eugen Stan commented on JAMES-3226: I believe we should re-use the old site project for deployment automation https://github.com/apache/james-site / https://gitbox.apache.org/repos/asf?p=james-site.git It seems that the asf-site branch is the one being published. I'll work on another branch and do some of the following: - Create a Jenkins multibranch pipeline - Add gradle for building - Figure out a process on how to link and publish all of this. - Write it down in asciidoc > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Commented] (JAMES-3258) Update Documentation for version <3.5.0
[ https://issues.apache.org/jira/browse/JAMES-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151313#comment-17151313 ] Ioan Eugen Stan commented on JAMES-3258: The old documentation is still valuable and we should try to migrate as much as possible. While it may not be as rewarding as writing from scratch, it can be faster then creating new docs. It's also something we can enhance. > Update Documentation for version <3.5.0 > --- > > Key: JAMES-3258 > URL: https://issues.apache.org/jira/browse/JAMES-3258 > Project: James Server > Issue Type: Improvement >Reporter: David Leangen >Priority: Major > > This is an umbrella issue that links to various documentation-related issues > that have been around for a while. Some may still be relevant, some may not. > There is an initiate to create a completely new documentation. It is a clean > break from all existing documentation. -- 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
[jira] [Comment Edited] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150956#comment-17150956 ] Ioan Eugen Stan edited comment on JAMES-3225 at 7/3/20, 12:01 PM: -- Removed old builds: https://builds.apache.org/view/J/view/James/job/james-skin/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3-m2/ Use the view to see all James projects: https://builds.apache.org/view/J/view/ApacheJamesProjects/ was (Author: ieugen): Removed old builds: https://builds.apache.org/view/J/view/James/job/james-skin/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3-m2/ Use the view to see all James projects: https://builds.apache.org/view/J/view/James/ > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Comment Edited] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150956#comment-17150956 ] Ioan Eugen Stan edited comment on JAMES-3225 at 7/3/20, 11:56 AM: -- Removed old builds: https://builds.apache.org/view/J/view/James/job/james-skin/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3-m2/ Use the view to see all James projects: https://builds.apache.org/view/J/view/James/ was (Author: ieugen): Removed old builds: https://builds.apache.org/view/J/view/James/job/james-skin/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3-m2/ > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Commented] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150956#comment-17150956 ] Ioan Eugen Stan commented on JAMES-3225: Removed old builds: https://builds.apache.org/view/J/view/James/job/james-skin/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3/ https://builds.apache.org/view/J/view/James/job/james-server-v2.3-m2/ > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Updated] (JAMES-2657) SSLEngine and SslHandler unaware of remote ip and port
[ https://issues.apache.org/jira/browse/JAMES-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan updated JAMES-2657: --- Attachment: 148.patch.txt > SSLEngine and SslHandler unaware of remote ip and port > -- > > Key: JAMES-2657 > URL: https://issues.apache.org/jira/browse/JAMES-2657 > Project: James Server > Issue Type: Bug >Reporter: Randymo >Priority: Minor > Attachments: 148.patch.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Our team uses the remote ip of the connect to determine the ssl cert we use > for the connection. We had to make changes on our end to make that accessible > to us at the level we needed it. It would be nice if James did this > automatically itself. -- 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
[jira] [Commented] (JAMES-2657) SSLEngine and SslHandler unaware of remote ip and port
[ https://issues.apache.org/jira/browse/JAMES-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150854#comment-17150854 ] Ioan Eugen Stan commented on JAMES-2657: Added the patch from PR https://github.com/apache/james-project/pull/148 [^148.patch.txt] Closing that since it has no source. > SSLEngine and SslHandler unaware of remote ip and port > -- > > Key: JAMES-2657 > URL: https://issues.apache.org/jira/browse/JAMES-2657 > Project: James Server > Issue Type: Bug >Reporter: Randymo >Priority: Minor > Attachments: 148.patch.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Our team uses the remote ip of the connect to determine the ssl cert we use > for the connection. We had to make changes on our end to make that accessible > to us at the level we needed it. It would be nice if James did this > automatically itself. -- 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
[jira] [Resolved] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan resolved JAMES-3225. Resolution: Fixed > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Commented] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150845#comment-17150845 ] Ioan Eugen Stan commented on JAMES-3225: This is done. I've created a personal github token for authenticated API requests and it works fast now. Proof: https://builds.apache.org/job/ApacheJames/view/change-requests/ https://builds.apache.org/job/ApacheJames/indexing/console References: https://cwiki.apache.org/confluence/display/INFRA/Kicking+off+a+build+in+Jenkins+with+a+GitHub+PR https://docs.cloudbees.com/docs/admin-resources/latest/plugins/pull-request-builder-for-github#pull-request-builder-for-github-sect-creating > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Comment Edited] (JAMES-3260) Explore building Apache James with Gradle
[ https://issues.apache.org/jira/browse/JAMES-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150616#comment-17150616 ] Ioan Eugen Stan edited comment on JAMES-3260 at 7/2/20, 10:50 PM: -- I've pushed some more code and things are moving slowly. There is a test that fails on Jenkins and not locally https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/7/console Workspace here : https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/7/execution/node/3/ws/server/blob/blob-objectstorage/build/reports/tests/test/ And the test report here: https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/7/execution/node/3/ws/server/blob/blob-objectstorage/build/reports/tests/test/index.html Build scan here: https://gradle.com/s/qfuk7bevti77o It would be great if someone can investigate that. Some more info: Running ./gradlew :james-server:james-server-guice:james-server-cassandra-guice:clean and then: ./gradlew build Continues the build without the bug so I guess there are some issues with the tests. was (Author: ieugen): I've pushed some more code and things are moving slowly. There is a test that fails on Jenkins and not locally https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/7/console Workspace here : https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/7/execution/node/3/ws/server/blob/blob-objectstorage/build/reports/tests/test/ And the test report here: https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/7/execution/node/3/ws/server/blob/blob-objectstorage/build/reports/tests/test/index.html Build scan here: https://gradle.com/s/qfuk7bevti77o It would be great if someone can investigate that. > Explore building Apache James with Gradle > - > > Key: JAMES-3260 > URL: https://issues.apache.org/jira/browse/JAMES-3260 > Project: James Server > Issue Type: Improvement > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 9h 10m > Remaining Estimate: 0h > > Creating an issue to track the process of using Gradle for building Apache > James. > There have been a few discussions on this topic from multiple parties. > The main benefit is having faster builds which Maven is unable to provide > because of it's limitations on how it approaches build life-cycle and > caching. > We should take care of: > * all that is related to release and deploy (but this can be taken from other > Apache projects already using Gradlle) > * the site building (but this should disappear with the migration to Antora) > * the mailets plugin > * checking Spring build > * adding partial tests on JMAP integration (allowing to run only some smoke > tests on some big integration tests suite) > * adding and configuration the checkstyle plugin > * updating the Jenkins build > * documenting the migration for all the users that are building James > themselves -- 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
[jira] [Commented] (JAMES-3260) Explore building Apache James with Gradle
[ https://issues.apache.org/jira/browse/JAMES-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150616#comment-17150616 ] Ioan Eugen Stan commented on JAMES-3260: I've pushed some more code and things are moving slowly. There is a test that fails on Jenkins and not locally https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/7/console Workspace here : https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/7/execution/node/3/ws/server/blob/blob-objectstorage/build/reports/tests/test/ And the test report here: https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/7/execution/node/3/ws/server/blob/blob-objectstorage/build/reports/tests/test/index.html Build scan here: https://gradle.com/s/qfuk7bevti77o It would be great if someone can investigate that. > Explore building Apache James with Gradle > - > > Key: JAMES-3260 > URL: https://issues.apache.org/jira/browse/JAMES-3260 > Project: James Server > Issue Type: Improvement > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 9h 10m > Remaining Estimate: 0h > > Creating an issue to track the process of using Gradle for building Apache > James. > There have been a few discussions on this topic from multiple parties. > The main benefit is having faster builds which Maven is unable to provide > because of it's limitations on how it approaches build life-cycle and > caching. > We should take care of: > * all that is related to release and deploy (but this can be taken from other > Apache projects already using Gradlle) > * the site building (but this should disappear with the migration to Antora) > * the mailets plugin > * checking Spring build > * adding partial tests on JMAP integration (allowing to run only some smoke > tests on some big integration tests suite) > * adding and configuration the checkstyle plugin > * updating the Jenkins build > * documenting the migration for all the users that are building James > themselves -- 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
[jira] [Commented] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[
https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150615#comment-17150615
]
Ioan Eugen Stan commented on JAMES-3225:
Ok, so I think I have found MultiBranch + Github combination that works.
Now I need to make it so that it can make authenticated requests so we get 5000
api calls per hour instead of 60 .
https://builds.apache.org/job/ApacheJames/indexing/console
{noformat}
Started by timer
[Thu Jul 02 21:42:00 UTC 2020] Starting branch indexing...
21:42:00 Connecting to https://api.github.com with no credentials, anonymous
access
{noformat}
https://developer.github.com/v3/#rate-limiting
I think this is the plugin:
https://docs.cloudbees.com/docs/admin-resources/latest/plugins/pull-request-builder-for-github
> Provide automated builds for Apache James - (restore builds.apache.org ?)
> --
>
> Key: JAMES-3225
> URL: https://issues.apache.org/jira/browse/JAMES-3225
> Project: James Server
> Issue Type: Task
> Reporter: Ioan Eugen Stan
> Assignee: Ioan Eugen Stan
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> For a long time we had builds that ran on the Apache Infrastructure
> https://builds.apache.org/view/All/job/james-mailet/ .
> The build infrastructure is not running for ~ 3 years now.
> I believe it is important for us to have automated builds.
> This ticket should gather the work needed to make this a reality.
> There are lots of things to take into consideration.
> My ( [~ieugen] ) opinions on how to handle this.
> * builds should run automatically
> * builds should run fast < 10 min
> * there are several things they should do (not exhaustive)
> ** verify the source code
> ** compile the source code
> ** run the unit tests
> ** run the integration tests
> ** publish SNAPSHOTS (only from master or develop ?!)
> ** run code analytics
> ** publish reports relating to build
> ** provide build status for other services
> For smaller projects this is a no-brainer.
> For the current state of Apache James this is a challange, especially in the
> context of
> - multiple git branches and PR's
> - the distributed integration tests which take a long time
> Given the limited resources available for us on the Apache infrastructure we
> will have to be selective of what we do.
> Personally I don't see how we can run the current (40mni +) integration suite
> on each push / build. I'm pretty sure we will get banned :) or throttled.
> So a discussion should be in order on how to solve these issues but some
> options regarding what we can do:
> - make integration tests OPT-IN
> - run (distributed) integration tests once a day or once every 6h / 12h
> - have build profiles that build a common subset all the time and run
> The nuclear option: prune some of the components we have in James and we
> don't want to support or move them out of the common project.
> This is something we should consider especially for buggy components or for
> components that don't have a maintainer.
> We have limited time and resources.
> We can't maintain everything for everybody.
> We should be mindful of this.
> We can take inspiration from the OFBiz project
> https://builds.apache.org/view/All/job/Apache%20OFBiz/ .
--
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
[jira] [Commented] (JAMES-3259) Reorganize source code
[
https://issues.apache.org/jira/browse/JAMES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150440#comment-17150440
]
Ioan Eugen Stan commented on JAMES-3259:
After working on the gradle migration and reading [~dleangen]'s email I belive
the structure should be driven by the business needs / end products and not the
technologies we use.
- imap server
- smpt server
- jmap server
- pop3 server
For each server there are of course multiple implementations: jdbc/jpa ,
cassandra, etc.
When the servers are composed and run in a single process, it makes sense to
use implementations that use the same technology (e.g. all server
implementations that use Cassandra) , to avoid operational overhead.
I believe that is important for us to have boundaries around the server
implementations so that:
* If I am only using SMPT in my application, I should be able to
** develop and work on the SMTP implementation
** run the integration tests only for SMPT implementations
** run only the SMTP server in production
** I should not have to care about the IMAP implementation since there is no
way I can break that.
Inside the SMTP project:
* There can be multiple implementation
* We should have a very good set of integration tests that focus on SMTP
regardless of implementation
* We can have a thin set of integration tests that focus on technology
specifics - cassandra, jpa, etc
Right now I can't easily work just on SMTP or just on IMAP since the code is
highly coupled.
I have to run ALL the integration tests, even if I care about SMTP and no the
others.
Also, for SMTP, if I care only about RabbitMQ implementation, it should be easy
for me to focus just on that.
Once I am done developing, I should be able to run just the suite of SMTP
integration tests for my changes.
The above suggestions are just that, suggestions.
They are by no means perfect and please share your constructive ideas.
The goal is to focus less on a a perfect, complete "James Server" and more on:
Hey we have a SMTP, IMAP, POP3 servers and you can build your own email server
with them.
We can and should provide a distribution with all of them in the same app, but
that should be a side-effect and a bonus of how we organize.
> Reorganize source code
> --
>
> Key: JAMES-3259
> URL: https://issues.apache.org/jira/browse/JAMES-3259
> Project: James Server
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Matthieu Baechler
>Priority: Major
>
> I want to suggest a new organization of the source-code (I won't handle every
> concerns but some important ones I have about the current state).
> I would like the first level to be:
> {code}
> core (domain code)
> data (that we should rename)
> docs
> extensions (containing mdn and third-party for example)
> infrastructure (containing backends-common, event-sourcing, json, metrics)
> mailbox
> mailet
> products (containing server/container/cli
> server/container/guice/cassandra-rabbitmq-guice)
> protocols
> server
> testing (containing mpt)
> {code}
> I'm not sure it's the best organization but:
> * it allows to see easily what james most important concepts are
> * put technical details into a common sub-tree
> * have products a top level thing instead of a hidden one
> * group what we think are extensions somewhere
> * put functional testing sources somewhere that is easy to find (because a
> lot of people starts by reading functional tests)
> What do you think?
--
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
[jira] [Comment Edited] (JAMES-2877) release process should deploy and generate more artifacts
[
https://issues.apache.org/jira/browse/JAMES-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (JAMES-2877) release process should deploy and generate more artifacts
[
https://issues.apache.org/jira/browse/JAMES-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150415#comment-17150415
]
Ioan Eugen Stan commented on JAMES-2877:
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
[jira] [Commented] (JAMES-3273) Acceptance criteria checklist
[
https://issues.apache.org/jira/browse/JAMES-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150381#comment-17150381
]
Ioan Eugen Stan commented on JAMES-3273:
[~btellier]: I had another look.
To create the structure you have with maven, all you have to do is add this to
build.gradle:
{noformat}
task copyDependencies(type: Copy) {
from configurations.default
into "${project.buildDir}/${project.name}.lib"
}
{noformat}
For the guice modules that are applications believe it's better to apply the
application plugin so I am going to do that.
To compare the jars prduced by maven and gradle in the lib directory you can:
{noformat}
ls -1 build/james-server-cassandra-guice.lib/ > gradle-lib-files.txt
ls -1 target/james-server-cassandra-guice.lib/ > maven-lib-files.txt
diff maven-lib-files.txt gradle-lib-files.txt
NOTE: I use meld as a (gui) diff tool and the param for `ls` is a one (1) .
{noformat}
Here are the files I got with the gradle task above, the application plugin and
using the maven copy-dependencies goal:
[^gradle-lib-files.txt] [^gradle-lib-files-application-plugin.txt]
[^maven-lib-files.txt]
I highly recommend we use the gradle application plugin for this.
You find the zip / tar file in build/distributions .
It has the libraries and scripts to start the application.
I'm working on that now and will push soon.
> Acceptance criteria checklist
> -
>
> Key: JAMES-3273
> URL: https://issues.apache.org/jira/browse/JAMES-3273
> Project: James Server
> Issue Type: Sub-task
>Reporter: Ioan Eugen Stan
>Assignee: Benoit Tellier
>Priority: Major
> Attachments: gradle-lib-files-application-plugin.txt,
> gradle-lib-files.txt, maven-lib-files.txt
>
>
> We need a list of acceptance criteria for making the gradle migration.
> We need a checklist so we know when we are ready for the merge.
> Please add this checklist here.
> Some items are sub-tasks of https://issues.apache.org/jira/browse/JAMES-3260
--
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
[jira] [Updated] (JAMES-3273) Acceptance criteria checklist
[ https://issues.apache.org/jira/browse/JAMES-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan updated JAMES-3273: --- Attachment: maven-lib-files.txt gradle-lib-files-application-plugin.txt gradle-lib-files.txt > Acceptance criteria checklist > - > > Key: JAMES-3273 > URL: https://issues.apache.org/jira/browse/JAMES-3273 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan >Assignee: Benoit Tellier >Priority: Major > Attachments: gradle-lib-files-application-plugin.txt, > gradle-lib-files.txt, maven-lib-files.txt > > > We need a list of acceptance criteria for making the gradle migration. > We need a checklist so we know when we are ready for the merge. > Please add this checklist here. > Some items are sub-tasks of https://issues.apache.org/jira/browse/JAMES-3260 -- 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
[jira] [Commented] (JAMES-3273) Acceptance criteria checklist
[ https://issues.apache.org/jira/browse/JAMES-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150301#comment-17150301 ] Ioan Eugen Stan commented on JAMES-3273: [~btellier]: I've configured a binary distribution for server/app that looks like the previous one. Code here https://github.com/apache/james-project/pull/217/commits/c30e31dc5b1b84e5b94704d41a1dbe74c84baf9d Regarding guice module - do you build "fat" jars ? server/container/guice/cassandra-guice server/container/guice/cassandra-ldap-guice server/container/guice/cassandra-rabbitmq-guice server/container/guice/cassandra-rabbitmq-ldap-guice server/container/guice/jpa-guice server/container/guice/jpa-smtp server/container/guice/memory-guice > Acceptance criteria checklist > - > > Key: JAMES-3273 > URL: https://issues.apache.org/jira/browse/JAMES-3273 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan >Assignee: Benoit Tellier >Priority: Major > > We need a list of acceptance criteria for making the gradle migration. > We need a checklist so we know when we are ready for the merge. > Please add this checklist here. > Some items are sub-tasks of https://issues.apache.org/jira/browse/JAMES-3260 -- 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
[jira] [Commented] (JAMES-3260) Explore building Apache James with Gradle
[
https://issues.apache.org/jira/browse/JAMES-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150179#comment-17150179
]
Ioan Eugen Stan commented on JAMES-3260:
The gradle build passes locally for me and other developers and I am working to
make it build on builds.apache.org.
Some integration tests are disabled because of dependency issues.
Some tests are disabled because they fail.
One (mpt test) is disabled because it is also disabled in maven.
{noformat}
git grep 'enabled = false'
mpt/impl/imap-mailbox/cyrus/build.gradle:enabled = false
mpt/impl/imap-mailbox/external-james/build.gradle:enabled = false
mpt/impl/smtp/cassandra-rabbitmq-object-storage/build.gradle:enabled = false
mpt/mavenplugin/build.gradle:enabled = false
server/container/core/build.gradle:enabled = false
server/container/guice/blob-objectstorage-guice/build.gradle:enabled = false
server/container/guice/cassandra-rabbitmq-guice/build.gradle:enabled = false
server/container/guice/cassandra-rabbitmq-ldap-guice/build.gradle:enabled =
false
server/data/data-jmap/build.gradle:enabled = false
server/mailet/integration-testing/build.gradle:enabled = false
server/protocols/jmap-draft-integration-testing/rabbitmq-jmap-draft-integration-testing/build.gradle:
enabled = false
server/protocols/jmap-rfc-8621-integration-tests/distributed-jmap-rfc-8621-integration-tests/build.gradle:
enabled = false
server/protocols/webadmin-integration-test/distributed-webadmin-integration-test/build.gradle:
enabled = false
{noformat}
The focus is to make the build work on builds.apache.org and then fix the
integration tests.
> Explore building Apache James with Gradle
> -
>
> Key: JAMES-3260
> URL: https://issues.apache.org/jira/browse/JAMES-3260
> Project: James Server
> Issue Type: Improvement
> Reporter: Ioan Eugen Stan
> Assignee: Ioan Eugen Stan
>Priority: Major
> Time Spent: 8.5h
> Remaining Estimate: 0h
>
> Creating an issue to track the process of using Gradle for building Apache
> James.
> There have been a few discussions on this topic from multiple parties.
> The main benefit is having faster builds which Maven is unable to provide
> because of it's limitations on how it approaches build life-cycle and
> caching.
> We should take care of:
> * all that is related to release and deploy (but this can be taken from other
> Apache projects already using Gradlle)
> * the site building (but this should disappear with the migration to Antora)
> * the mailets plugin
> * checking Spring build
> * adding partial tests on JMAP integration (allowing to run only some smoke
> tests on some big integration tests suite)
> * adding and configuration the checkstyle plugin
> * updating the Jenkins build
> * documenting the migration for all the users that are building James
> themselves
--
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
[jira] [Commented] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150165#comment-17150165 ] Ioan Eugen Stan commented on JAMES-3225: I've contacted [~christ] to help out with starting the builds on push / PR creation . I'm also fixing some environment specific build issues (default encoding on builds is ISO not UTF-8 , etc) . It's a matter of time, but this is going to be done. https://builds.apache.org/job/james-project/job/JAMES-3260-gradle-poc/ I've created two configurations: * one with github pluing https://builds.apache.org/job/ApacheJames/ (experimental) * one with multibanch plugin https://builds.apache.org/job/james-project/ (current) . We will see which one is going to be better. > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Commented] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147886#comment-17147886 ] Ioan Eugen Stan commented on JAMES-3225: We have a view for James projects: https://builds.apache.org/view/J/view/James/ . We have builds running (not yet automated) https://builds.apache.org/view/J/view/James/job/james-project/job/JAMES-3225-autobuild/ . > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Commented] (JAMES-2335) Modernize James configuration
[ https://issues.apache.org/jira/browse/JAMES-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146140#comment-17146140 ] Ioan Eugen Stan commented on JAMES-2335: [~dleangen] Apache Commons Configuration can read properties from all kinds of sources https://commons.apache.org/proper/commons-configuration/ and https://github.com/apache/commons-configuration/ https://github.com/apache/commons-configuration/blob/master/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java We just need to write configurations in those sources and use them. I tend to prefer YAML or TOML since they allow for comments and structure and are easier to read than XML or JSON. We can read configuration from the database as well - for the JPA implementation ( [~btellier] mentioned writing a Cassandra provider to store configs in Cassandra ). [~btellier]: Some remarks regarding configuration and how it's used. I believe parsing, loading and saving the configuration is the application's responsibility not the modules responsibility. I have seen a lot of modules depending on the commons-configuration jar and I think it should not be so. Modules that need configuration should define a POJO or a Map of properties they use as configuration. The POJO / Map is handed to them by the application on creation. The modules / components should not normally need to Set / Update their configuration. It's normally the application's concern. For services that have a dynamic configuration, they will need to use a configuration provider factory - a class that produces the latest configuration. That latest configuration can be read and cached by the application centrally and injected in the configuration provider factory. OSGi ConfigurationAdmin does this quite well actually. > Modernize James configuration > - > > Key: JAMES-2335 > URL: https://issues.apache.org/jira/browse/JAMES-2335 > Project: James Server > Issue Type: Improvement > Components: configuration >Reporter: Benoit Tellier >Priority: Major > Labels: feature, refactoring > > Apache James currently relies on commons-configuration, and thus on XML > configuration files. > As such the configuration process has several problems: > - Working with XML is boiler plate > - Working with file leads to a real lack of flexibility. > - For instance, in a cluster environment, we would like all the James > server to share the same configurations. > - Also, in tests, we need to test the different configuration values. > We can not do this without overwriting files, which is dangerous, and > boilerplate. > What we need is: > - To represent all possible configuration via java objects. > - Configuration providers should be able to convert the configuration stored > into the java configuration object. > - We should be able to inject different configuration providers from > guice/spring. > It would allow to specify alternative configuration backends (different > formats, different storage techniques) and allow direct injection (for tests > for instance). > Here would be the steps for this work: > - Add a *Initializable* class in *lifecycle-api*. This should be called by > Guice and Sprint at initialization > - *configure* in Configurable will save a Java object (parse the > HierachicalConfiguration into a java object representing it's content). > Initialization will then be done by *Initializable*. > - Then we can move away, object by object, from the *Configurable* > interface: We need to move the configuration parsing in a separated class > (behind an interface). We can register *ConfigurationProviders*, with an > XML/commons-configuration default implementation. > - Deprecate *Configurable*. > - Provide alternative configuration providers, for example, a Cassandra > stored configuration provider -- 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
[jira] [Commented] (JAMES-3281) Remove rogue log entries
[
https://issues.apache.org/jira/browse/JAMES-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144874#comment-17144874
]
Ioan Eugen Stan commented on JAMES-3281:
We need to check what OpenJPA is ussing for logging and provide a bridge from
that -> slf4j / logback .
> Remove rogue log entries
>
>
> Key: JAMES-3281
> URL: https://issues.apache.org/jira/browse/JAMES-3281
> Project: James Server
> Issue Type: Sub-task
>Reporter: David Leangen
>Priority: Major
>
> There are some log entires that are somehow out-of-scope of logback. It could
> just be my misunderstanding of logback configuration, but even setting all
> logging to NONE does not remove these entries:
> {noformat}
> james_1 | WARNING: An illegal reflective access operation has occurred
> james_1 | WARNING: Illegal reflective access by
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> (file:/opt/apache-james/james-basic-server/lib/guice-4.2.2.jar) to method
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> james_1 | WARNING: Please consider reporting this to the maintainers of
> com.google.inject.internal.cglib.core.$ReflectUtils$1
> james_1 | WARNING: Use --illegal-access=warn to enable warnings of further
> illegal reflective access operations
> james_1 | WARNING: All illegal access operations will be denied in a future
> release
> james_1 | 46 Global WARN [main] openjpa.Runtime - Could not create the
> optional validation provider. Reason returned: "A default ValidatorFactory
> could not be created."
> james_1 | 1054 Global INFO [main] openjpa.Runtime - Starting OpenJPA
> 3.1.0
> james_1 | 1134 Global INFO [main] openjpa.jdbc.JDBC - Using dictionary
> class "org.apache.openjpa.jdbc.sql.DerbyDictionary".
> james_1 | 2446 Global INFO [main] openjpa.jdbc.JDBC - Connected to
> Apache Derby version 10.10 using JDBC driver Apache Derby Embedded JDBC
> Driver version 10.14.2.0 - (1828579).
> {noformat}
--
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
[jira] [Created] (JAMES-3275) Apply Apache RAT - Release Auditing Tool
Ioan Eugen Stan created JAMES-3275: -- Summary: Apply Apache RAT - Release Auditing Tool Key: JAMES-3275 URL: https://issues.apache.org/jira/browse/JAMES-3275 Project: James Server Issue Type: Sub-task Reporter: Ioan Eugen Stan Assignee: Ioan Eugen Stan https://apache.org/legal/src-headers.html https://github.com/eskatos/creadur-rat-gradle -- 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
[jira] [Commented] (JAMES-3273) Acceptance criteria checklist
[
https://issues.apache.org/jira/browse/JAMES-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143685#comment-17143685
]
Ioan Eugen Stan commented on JAMES-3273:
Some tips in point 2 of this
https://docs.gradle.org/current/userguide/migrating_from_maven.html
{noformat}
Develop a mechanism to verify that the two builds produce the same artifacts
This is a vitally important step to ensure that your deployments and tests
don’t break. Even small changes, such as the contents of a manifest file in a
JAR, can cause problems. If your Gradle build produces the same output as the
Maven build, this will give you and others confidence in switching over and
make it easier to implement the big changes that will provide the greatest
benefits.
This doesn’t mean that you need to verify every artifact at every stage,
although doing so can help you quickly identify the source of a problem. You
can just focus on the critical output such as final reports and the artifacts
that are published or deployed.
You will need to factor in some inherent differences in the build output that
Gradle produces compared to Maven. Generated POMs will contain only the
information needed for consumption and they will use and
scopes correctly for that scenario. You might also see differences in the order
of files in archives and of files on classpaths. Most differences will be
benign, but it’s worth identifying them and verifying that they are OK.
{noformat}
> Acceptance criteria checklist
> -
>
> Key: JAMES-3273
> URL: https://issues.apache.org/jira/browse/JAMES-3273
> Project: James Server
> Issue Type: Sub-task
> Reporter: Ioan Eugen Stan
>Assignee: Benoit Tellier
>Priority: Major
>
> We need a list of acceptance criteria for making the gradle migration.
> We need a checklist so we know when we are ready for the merge.
> Please add this checklist here.
> Some items are sub-tasks of https://issues.apache.org/jira/browse/JAMES-3260
--
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
[jira] [Created] (JAMES-3274) Apache James release with gradle
Ioan Eugen Stan created JAMES-3274: -- Summary: Apache James release with gradle Key: JAMES-3274 URL: https://issues.apache.org/jira/browse/JAMES-3274 Project: James Server Issue Type: Sub-task Reporter: Ioan Eugen Stan -- 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
[jira] [Assigned] (JAMES-3272) Add apache license headers to build.gradle files
[ https://issues.apache.org/jira/browse/JAMES-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan reassigned JAMES-3272: -- Assignee: Ioan Eugen Stan > Add apache license headers to build.gradle files > - > > Key: JAMES-3272 > URL: https://issues.apache.org/jira/browse/JAMES-3272 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > See https://apache.org/legal/src-headers.html . -- 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
[jira] [Created] (JAMES-3273) Acceptance criteria checklist
Ioan Eugen Stan created JAMES-3273: -- Summary: Acceptance criteria checklist Key: JAMES-3273 URL: https://issues.apache.org/jira/browse/JAMES-3273 Project: James Server Issue Type: Sub-task Reporter: Ioan Eugen Stan Assignee: Benoit Tellier We need a list of acceptance criteria for making the gradle migration. We need a checklist so we know when we are ready for the merge. Please add this checklist here. Some items are sub-tasks of https://issues.apache.org/jira/browse/JAMES-3260 -- 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
[jira] [Created] (JAMES-3272) Add apache license headers to build.gradle files
Ioan Eugen Stan created JAMES-3272: -- Summary: Add apache license headers to build.gradle files Key: JAMES-3272 URL: https://issues.apache.org/jira/browse/JAMES-3272 Project: James Server Issue Type: Sub-task Reporter: Ioan Eugen Stan See https://apache.org/legal/src-headers.html . -- 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
[jira] [Created] (JAMES-3271) Implement checkstyle and code formatting for gradle
Ioan Eugen Stan created JAMES-3271: -- Summary: Implement checkstyle and code formatting for gradle Key: JAMES-3271 URL: https://issues.apache.org/jira/browse/JAMES-3271 Project: James Server Issue Type: Sub-task Reporter: Ioan Eugen Stan Gradle has nice support for this. See https://newsletter.gradle.com/2020/06 : Rewrite - a new plugin aiming to automatically refactor code by, for example, applying Checkstyle rules Spotless - the popular plugin published a new major release that supports local build cache https://github.com/apache/james-project/pull/217#issuecomment-648642120 -- 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
[jira] [Created] (JAMES-3270) Migrate James docker builds to use gradle
Ioan Eugen Stan created JAMES-3270: -- Summary: Migrate James docker builds to use gradle Key: JAMES-3270 URL: https://issues.apache.org/jira/browse/JAMES-3270 Project: James Server Issue Type: Sub-task Reporter: Ioan Eugen Stan https://github.com/apache/james-project/pull/217#issuecomment-648664678 -- 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
[jira] [Commented] (JAMES-1766) Design a IMAP search test with gatling
[ https://issues.apache.org/jira/browse/JAMES-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141958#comment-17141958 ] Ioan Eugen Stan commented on JAMES-1766: I think it makes sense to build a TCK https://en.wikipedia.org/wiki/Technology_Compatibility_Kit . We could use that to drive the integration tests for all the underlying implementations. This is different than a performance test - which can test the performance with just a few use cases. I wonder if there are any TCK's out there for email protocols. > Design a IMAP search test with gatling > -- > > Key: JAMES-1766 > URL: https://issues.apache.org/jira/browse/JAMES-1766 > Project: James Server > Issue Type: Sub-task > Components: IMAPServer >Reporter: btell...@apache.org >Priority: Major > Fix For: 3.0.0 > > > Run the tests for a constant number of users, with ~1000 mails in there inbox. > You will demonstrate the number of supported users (during 4 hours at > constant latency) between : > - the simpleMessageSearchIndex implementation > - the ElasticSearch implementation -- 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
[jira] [Commented] (JAMES-3259) Reorganize source code
[
https://issues.apache.org/jira/browse/JAMES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141775#comment-17141775
]
Ioan Eugen Stan commented on JAMES-3259:
I agree with [~dleangen]'s approach to using a common language.
Ideally people who host email with other tools (postfix, exim, dovecoat, etc)
can come to James and understand things very easily.
That means less Java/Scala and more email and email RFC's which use a more
common technical jargon.
If we manage that, then we will make James easier to adopt since they will know
the terminology and be able to get around much faster.
I also agree with [~matthieu] and this is why I'm lobbying for a component
approach that focuses on the end uses cases and less on maven project structure
derived from the technologies we use (jpa, cassandra, etc) .
> Reorganize source code
> --
>
> Key: JAMES-3259
> URL: https://issues.apache.org/jira/browse/JAMES-3259
> Project: James Server
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Matthieu Baechler
>Priority: Major
>
> I want to suggest a new organization of the source-code (I won't handle every
> concerns but some important ones I have about the current state).
> I would like the first level to be:
> {code}
> core (domain code)
> data (that we should rename)
> docs
> extensions (containing mdn and third-party for example)
> infrastructure (containing backends-common, event-sourcing, json, metrics)
> mailbox
> mailet
> products (containing server/container/cli
> server/container/guice/cassandra-rabbitmq-guice)
> protocols
> server
> testing (containing mpt)
> {code}
> I'm not sure it's the best organization but:
> * it allows to see easily what james most important concepts are
> * put technical details into a common sub-tree
> * have products a top level thing instead of a hidden one
> * group what we think are extensions somewhere
> * put functional testing sources somewhere that is easy to find (because a
> lot of people starts by reading functional tests)
> What do you think?
--
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
[jira] [Commented] (JAMES-3261) Provide ZIP distribution for Guice servers application
[ https://issues.apache.org/jira/browse/JAMES-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141551#comment-17141551 ] Ioan Eugen Stan commented on JAMES-3261: Gradle makes these distributions quite easy to build. If you are not in a hurry, could we defer this for a couple of days / weeks? I would like to avoid too many changes to the pom structure / dependencies - it will make an eventual migration to gradle a bit tedious. > Provide ZIP distribution for Guice servers application > -- > > Key: JAMES-3261 > URL: https://issues.apache.org/jira/browse/JAMES-3261 > Project: James Server > Issue Type: Task > Components: guice >Affects Versions: master >Reporter: Benoit Tellier >Assignee: Benoit Tellier >Priority: Major > Fix For: 3.6.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Today, a user wishing to run a Guice server needs either to compile it > himself, or run it via docker. > Given that (1) we do not expect operators to compile James source code and > given (2) the docker images are so far only built and distributed by some > external suppliers, the operators cannot run the guice servers in a vendor > indepandant way. > As such, in order to promote guice servers adoption, we need to build a ZIP > distribution for them. This ZIP distribution would then be built upon the > release and easily uploaded on the website. > The maven-assembly-plugin can be leveraged to reach that goal. > Docker distributions would then reuse this ZIP in order to build the > resulting image. Note that sample configuration will then be centralized to > the APP maven project. -- 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
[jira] [Commented] (JAMES-3260) Explore building Apache James with Gradle
[ https://issues.apache.org/jira/browse/JAMES-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141358#comment-17141358 ] Ioan Eugen Stan commented on JAMES-3260: I made some progress. Right now gradle builds the tasks up to 571 from a total of 3110 tasks . Still some work to do but I don't think it will be linear, I hope it will get faster. You can print the line of the task that failed with ` ./gradlew clean build --dry-run | grep -n -C 2 ":apache-james-mailbox:backup:compileJava" ` , where ` :apache-james-mailbox:backup:compileJava ` is the task that failed . > Explore building Apache James with Gradle > - > > Key: JAMES-3260 > URL: https://issues.apache.org/jira/browse/JAMES-3260 > Project: James Server > Issue Type: Improvement > Reporter: Ioan Eugen Stan >Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Creating an issue to track the process of using Gradle for building Apache > James. > There have been a few discussions on this topic from multiple parties. > The main benefit is having faster builds which Maven is unable to provide > because of it's limitations on how it approaches build life-cycle and > caching. -- 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
[jira] [Commented] (JAMES-2510) use a consistent artifact naming scheme
[ https://issues.apache.org/jira/browse/JAMES-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141349#comment-17141349 ] Ioan Eugen Stan commented on JAMES-2510: I believe we can safely do renaming once we we have documentation for developers up. That way we have a place where to put the upgrade guide. > use a consistent artifact naming scheme > --- > > Key: JAMES-2510 > URL: https://issues.apache.org/jira/browse/JAMES-2510 > Project: James Server > Issue Type: Task > Components: Build System >Affects Versions: 3.1.0 >Reporter: Matthieu Baechler >Priority: Major > > Maven modules have different naming scheme, for example : > * apache-james-* > * james-server-* > * protocols-* > it makes everything hard to read and to find and it's redundant because > groupId already gives context about an artifact. > I'll make a proposal to reduce the noise in our maven files. -- 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
[jira] [Commented] (JAMES-3260) Explore building Apache James with Gradle
[ https://issues.apache.org/jira/browse/JAMES-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140907#comment-17140907 ] Ioan Eugen Stan commented on JAMES-3260: I am working to activate the builds scans, see https://scans.gradle.com/s/vmmyekhurnmme . I pushed some code here https://github.com/apache/james-project/pull/217 , let's continue there with review. > Explore building Apache James with Gradle > - > > Key: JAMES-3260 > URL: https://issues.apache.org/jira/browse/JAMES-3260 > Project: James Server > Issue Type: Improvement > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Creating an issue to track the process of using Gradle for building Apache > James. > There have been a few discussions on this topic from multiple parties. > The main benefit is having faster builds which Maven is unable to provide > because of it's limitations on how it approaches build life-cycle and > caching. -- 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
[jira] [Assigned] (JAMES-3260) Explore building Apache James with Gradle
[ https://issues.apache.org/jira/browse/JAMES-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan reassigned JAMES-3260: -- Assignee: Ioan Eugen Stan > Explore building Apache James with Gradle > - > > Key: JAMES-3260 > URL: https://issues.apache.org/jira/browse/JAMES-3260 > Project: James Server > Issue Type: Improvement > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > Creating an issue to track the process of using Gradle for building Apache > James. > There have been a few discussions on this topic from multiple parties. > The main benefit is having faster builds which Maven is unable to provide > because of it's limitations on how it approaches build life-cycle and > caching. -- 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
[jira] [Commented] (JAMES-2335) Modernize James configuration
[ https://issues.apache.org/jira/browse/JAMES-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140497#comment-17140497 ] Ioan Eugen Stan commented on JAMES-2335: I had my OSGi period and I think the technology has it's merits. It really depends on your deployment scenario. For me, working via docker and kubernetes - it currently does not make sens since the images should be immutable. I do see it as a way to dynamically load / unload extensions like mailets and change the processing pipeline at runtime. It could also be a nice addition to help with loading/unloading mailets / extensions during development. However, overall, in my use case of using docker and relying on the immutability of the image to avoid operational issues, there is not much value. In my particular use case, Java 9 modules are higher on the priority and complementary to OSGi. [~dleangen]: If you know something that I am missing, please let me know. > Modernize James configuration > - > > Key: JAMES-2335 > URL: https://issues.apache.org/jira/browse/JAMES-2335 > Project: James Server > Issue Type: Improvement > Components: configuration >Reporter: Benoit Tellier >Priority: Major > Labels: feature, refactoring > > Apache James currently relies on commons-configuration, and thus on XML > configuration files. > As such the configuration process has several problems: > - Working with XML is boiler plate > - Working with file leads to a real lack of flexibility. > - For instance, in a cluster environment, we would like all the James > server to share the same configurations. > - Also, in tests, we need to test the different configuration values. > We can not do this without overwriting files, which is dangerous, and > boilerplate. > What we need is: > - To represent all possible configuration via java objects. > - Configuration providers should be able to convert the configuration stored > into the java configuration object. > - We should be able to inject different configuration providers from > guice/spring. > It would allow to specify alternative configuration backends (different > formats, different storage techniques) and allow direct injection (for tests > for instance). > Here would be the steps for this work: > - Add a *Initializable* class in *lifecycle-api*. This should be called by > Guice and Sprint at initialization > - *configure* in Configurable will save a Java object (parse the > HierachicalConfiguration into a java object representing it's content). > Initialization will then be done by *Initializable*. > - Then we can move away, object by object, from the *Configurable* > interface: We need to move the configuration parsing in a separated class > (behind an interface). We can register *ConfigurationProviders*, with an > XML/commons-configuration default implementation. > - Deprecate *Configurable*. > - Provide alternative configuration providers, for example, a Cassandra > stored configuration provider -- 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
[jira] [Comment Edited] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140488#comment-17140488 ] Ioan Eugen Stan edited comment on JAMES-3225 at 6/19/20, 12:15 PM: --- I agree with meeting notes. Mailing list is fine but sometimes we need voice/video calls or live meetings and for those we should provide notes. Add feedback when you know about it on this issue. @gmcdonald Replied on Slack ASF #infra and offered to help. He asked "Do you know how many donated agents we could be looking at?" . [~matthieu]: I've created a special issue for exploring Gradle https://issues.apache.org/jira/browse/JAMES-3260 . Let's move the related discussion there. And thanks for your and [~btellier]'s efforts. We all spent time and energy on James. was (Author: ieugen): I agree with meeting notes. Mailing list is fine but sometimes we need voice/video calls or live meetings and for those we should provide notes. Add feedback when you know about it on this issue. @gmcdonald Replied on Slack ASF #infra and offered to help. He asked "Do you know how many donated agents we could be looking at?" . [~matthieu]: I've created a special issue for exploring Gradle https://issues.apache.org/jira/browse/JAMES-3260 . Let's move the related discussion there. > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task >Reporter: Ioan Eugen Stan >Assignee: Ioan Eugen Stan >Priority: Major > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Commented] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140488#comment-17140488 ] Ioan Eugen Stan commented on JAMES-3225: I agree with meeting notes. Mailing list is fine but sometimes we need voice/video calls or live meetings and for those we should provide notes. Add feedback when you know about it on this issue. @gmcdonald Replied on Slack ASF #infra and offered to help. He asked "Do you know how many donated agents we could be looking at?" . [~matthieu]: I've created a special issue for exploring Gradle https://issues.apache.org/jira/browse/JAMES-3260 . Let's move the related discussion there. > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan >Assignee: Ioan Eugen Stan >Priority: Major > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Commented] (JAMES-3260) Explore building Apache James with Gradle
[ https://issues.apache.org/jira/browse/JAMES-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140485#comment-17140485 ] Ioan Eugen Stan commented on JAMES-3260: Replying to [~matthieu] from https://issues.apache.org/jira/browse/JAMES-3225 . Regarding the gradle POC you did. Is that something we can use - can you rebase it on current master? I know gradle has some migration functionality build in so it might be the same effort to start from scratch. I would like to contribute to this, so we can sync + work together on a branch once we decide how we create that branch. I would create it on apache and sync via personal PR's from each of our git repos to this feature branch. Once we are satisfied we can merge it in master and have both working side until we are confident we can drop the maven build. The final check would be: we are able to release Apache James with Gradle instead of Maven. > Explore building Apache James with Gradle > - > > Key: JAMES-3260 > URL: https://issues.apache.org/jira/browse/JAMES-3260 > Project: James Server > Issue Type: Improvement > Reporter: Ioan Eugen Stan >Priority: Major > > Creating an issue to track the process of using Gradle for building Apache > James. > There have been a few discussions on this topic from multiple parties. > The main benefit is having faster builds which Maven is unable to provide > because of it's limitations on how it approaches build life-cycle and > caching. -- 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
[jira] [Created] (JAMES-3260) Explore building Apache James with Gradle
Ioan Eugen Stan created JAMES-3260: -- Summary: Explore building Apache James with Gradle Key: JAMES-3260 URL: https://issues.apache.org/jira/browse/JAMES-3260 Project: James Server Issue Type: Improvement Reporter: Ioan Eugen Stan Creating an issue to track the process of using Gradle for building Apache James. There have been a few discussions on this topic from multiple parties. The main benefit is having faster builds which Maven is unable to provide because of it's limitations on how it approaches build life-cycle and caching. -- 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
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140474#comment-17140474 ] Ioan Eugen Stan commented on JAMES-2586: We can decide how we use the tools and *document* those decisions. We can do that as part of a future community effort (via a community call). That way we as a community decide and we enforce them by pointing things out. It should be more of a soft enforcement than a hard one: please do that instead of this, because it's more useful for us to maintain the project. What I would like to get out of is a clear process for how we encourage contributions. This is intended to make our lives simpler when we manage the future of Apache James: we have a simple process, we expect people to behave and we have some expectations of how things will unfold. > Implement a Postgres-specific backend > - > > Key: JAMES-2586 > URL: https://issues.apache.org/jira/browse/JAMES-2586 > Project: James Server > Issue Type: New Feature >Reporter: Matthieu Baechler >Priority: Major > > James has a JPA implementation of most interfaces that allows to deploy it on > top of some popular RDBMS. > However, while useful for some kind of applications, ORM are usually a bad > fit for applications requiring high performance like a mail server. > As an abstraction, it also prevents from using advanced features of a given > RDBMS. > For most usages, James would probably run great on top of Postgres, given > that we use advanced features to implement search, for example. > A good strategy would be to implement all interfaces implemented by JPA with > a modern Postgres driver. -- 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
[jira] [Commented] (JAMES-3245) Clarify Sieve Configuration (managesieveserver.xml)
[ https://issues.apache.org/jira/browse/JAMES-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140464#comment-17140464 ] Ioan Eugen Stan commented on JAMES-3245: I don't think either. As I read through the issues and replies it looks to me the Baisc Server is more of a Demo Server and for anything useful you should use the Advanced Server. > Clarify Sieve Configuration (managesieveserver.xml) > --- > > Key: JAMES-3245 > URL: https://issues.apache.org/jira/browse/JAMES-3245 > Project: James Server > Issue Type: Sub-task >Reporter: David Leangen >Priority: Major > > In the context of the *Basic Server*, determine if (1) this configuration is > necessary, and if so (2) how can we minimize it and (3) document it better. -- 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
[jira] [Commented] (JAMES-3239) Clarify Logging Configuration (logback.xml & log4j.properties)
[ https://issues.apache.org/jira/browse/JAMES-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140449#comment-17140449 ] Ioan Eugen Stan commented on JAMES-3239: I think if we document this, it is enough: - what framework we are using for logging - slf4j - what is our default logging implementation - link to file - where is the default logging configuration - path in binary distribution - how people can supply their own login configuration - link to slf4j docs - [Advanced] how they can change the logging provider - change the logback-classic jar with a compatible version > Clarify Logging Configuration (logback.xml & log4j.properties) > -- > > Key: JAMES-3239 > URL: https://issues.apache.org/jira/browse/JAMES-3239 > Project: James Server > Issue Type: Sub-task >Reporter: David Leangen >Priority: Major > > In the context of the *Basic Server*, determine if (1) this configuration is > necessary, and if so (2) how can we minimize it and (3) document it better. -- 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
[jira] [Commented] (JAMES-3214) Remove test only libraries from being pulled as transitive dependencies of production artifacts
[
https://issues.apache.org/jira/browse/JAMES-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140444#comment-17140444
]
Ioan Eugen Stan commented on JAMES-3214:
It's marked as resolved.
Am I missing something?
> Remove test only libraries from being pulled as transitive dependencies of
> production artifacts
> ---
>
> Key: JAMES-3214
> URL: https://issues.apache.org/jira/browse/JAMES-3214
> Project: James Server
> Issue Type: Improvement
> Reporter: Ioan Eugen Stan
> Assignee: Ioan Eugen Stan
>Priority: Major
> Attachments: runtimeClasspath.txt
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> assertj-core , equalsverifier, rest-assured (and maybe other libraries)
> belong to testing (probably more). And they leaked to our "production" builds
> which depends on just 2 jars from James:
> implementation "org.apache.james:james-server-jpa-guice:${jamesVersion}"
> implementation "org.apache.james:james-server-cli:${jamesVersion}"
> == Context
> I'm working with David @dleangen on the self hosting with Apache James. We
> built a sandbox to play around and experiment:
> https://github.com/ieugen/james-self-hosting-sandbox .
> Current setup is to use gradle + application plugin to build a custom
> distribution.
> We build a zip distribution that pulls in all the dependencies including the
> offending ones used in testing.
> The distribution has 137MB unpacked. files just James, without the JRE.
> On initial inspection it seems there are test only dependencies that are
> being pulled as transitive dependencies of the 2 dependencies:
> Bellow is a list of top most large dependencies with ls -lSh
> james-self-hosting-sandbox/lib | head -n 40
> total 132M
> -rw-r--r-- 1 ieugen ieugen 13M iun 12 13:19 icu4j-64.2.jar
> -rw-r--r-- 1 ieugen ieugen 12M iun 12 13:19 testcontainers-1.12.0.jar
> -rw-r--r-- 1 ieugen ieugen 5,5M iun 12 13:19 scala-library-2.13.1.jar
> -rw-r--r-- 1 ieugen ieugen 5,3M iun 12 13:19 groovy-2.5.6.jar
> -rw-r--r-- 1 ieugen ieugen 5,0M iun 12 13:19 camel-core-2.24.1.jar
> -rw-r--r-- 1 ieugen ieugen 4,4M iun 12 13:19 openjpa-3.1.0.jar
> -rw-r--r-- 1 ieugen ieugen 4,4M iun 12 13:19 bcprov-jdk15on-1.62.jar
> -rw-r--r-- 1 ieugen ieugen 4,2M iun 12 13:19 assertj-core-3.12.2.jar
> -rw-r--r-- 1 ieugen ieugen 3,7M iun 12 13:19 jaxb-osgi-2.2.10.jar
> -rw-r--r-- 1 ieugen ieugen 3,5M iun 12 13:19 scala-reflect-2.13.1.jar
> -rw-r--r-- 1 ieugen ieugen 3,5M iun 12 13:19 lucene-smartcn-3.6.2.jar
> -rw-r--r-- 1 ieugen ieugen 3,2M iun 12 13:19 shapeless_2.13-2.3.3.jar
> -rw-r--r-- 1 ieugen ieugen 3,1M mai 3 05:45 derby-10.14.2.0.jar
> -rw-r--r-- 1 ieugen ieugen 2,8M iun 12 13:19 equalsverifier-3.1.9.jar
> -rw-r--r-- 1 ieugen ieugen 2,7M iun 12 13:19 guava-28.1-jre.jar
> -rw-r--r-- 1 ieugen ieugen 2,6M iun 12 13:19 jna-platform-5.3.1.jar
> -rw-r--r-- 1 ieugen ieugen 2,4M iun 12 13:19 jgroups-3.6.13.Final.jar
> -rw-r--r-- 1 ieugen ieugen 2,2M feb 17 21:24 commons-math3-3.6.1.jar
> -rw-r--r-- 1 ieugen ieugen 1,5M iun 12 13:19 lucene-core-3.6.2.jar
> -rw-r--r-- 1 ieugen ieugen 1,5M iun 12 13:19 reactor-core-3.3.0.RELEASE.jar
> -rw-r--r-- 1 ieugen ieugen 1,5M iun 12 13:19 jna-5.3.1.jar
> -rw-r--r-- 1 ieugen ieugen 1,4M iun 12 13:19 activemq-client-5.15.9.jar
> -rw-r--r-- 1 ieugen ieugen 1,4M iun 12 13:19 jackson-databind-2.10.1.jar
> -rw-r--r-- 1 ieugen ieugen 1,4M iun 12 13:19 httpclient-osgi-4.5.9.jar
> -rw-r--r-- 1 ieugen ieugen 1,3M iun 12 13:19 netty-3.10.6.Final.jar
> -rw-r--r-- 1 ieugen ieugen 1,2M iun 12 13:19 activemq-broker-5.15.9.jar
> -rw-r--r-- 1 ieugen ieugen 1,2M iun 12 13:19 lucene-analyzers-3.6.2.jar
> -rw-r--r-- 1 ieugen ieugen 1,1M iun 12 13:19 jaxb-impl-2.3.1.jar
> -rw-r--r-- 1 ieugen ieugen 851K iun 12 13:19 bcpkix-jdk15on-1.62.jar
> -rw-r--r-- 1 ieugen ieugen 827K iun 12 13:19 guice-4.2.2.jar
> -rw-r--r-- 1 ieugen ieugen 757K iun 12 13:19 httpclient-4.5.10.jar
> -rw-r--r-- 1 ieugen ieugen 737K iun 12 13:19 commons-collections4-4.3.jar
> -rw-r--r-- 1 ieugen ieugen 732K iun 12 13:19 play-json_2.13-2.8.1.jar
> -rw-r--r-- 1 ieugen ieugen 718K iun 12 13:19 javassist-3.21.0-GA.jar
> -rw-r--r-- 1 ieugen ieugen 715K iun 12 13:19 artemis-core-client-2.9.0.jar
> -rw-r--r-- 1 ieugen ieugen 687K iun 12 13:19 rest-assured-4.0.0.jar
> -rw-r--r-- 1 ieugen ieugen 670K iun 12 13:19
> activemq-openwire-legacy-5.15.9.jar
> -rw-r--r-- 1 ieugen ieugen 663K iun 12 13:19 activemq-kahadb-store-5.15.9.jar
> -rw-r--r-- 1 ieugen ieugen 644K mai 3 05:45 javax.mail-1.6.2.jar
>
[jira] [Resolved] (JAMES-3213) Enrich contact auto completion mailet pipeline with replyTo field
[ https://issues.apache.org/jira/browse/JAMES-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan resolved JAMES-3213. Resolution: Fixed Closing as it is marked as merged. Please reopen if you believe it is not done. > Enrich contact auto completion mailet pipeline with replyTo field > - > > Key: JAMES-3213 > URL: https://issues.apache.org/jira/browse/JAMES-3213 > Project: James Server > Issue Type: Improvement >Reporter: Gautier DI FOLCO >Priority: Minor > > When an attendee changes his participant status, there is a notification > email is sent to the event organizer from the attendee. > Then a third party sends an ITIP request to the CardAV server to handle > realtime update. > To achieve that, the third party send a message to James which output > received events to an AMQP channel that could be consumed by a CardAV server. > In the mean time James enrich the event sent to this server. > If the sender email does not exist in the list attendee, the CardAV ITIP > broker will add him to the attendee list. > This is not correct in cases: > * When an external attendee accept the event, the notification email should > send from the third party system > ([no-re...@example.org|mailto:no-re...@open-paas.org]) > * When the attendee forwards the invitation email to an external user, then > the external user (is not included in attendee list) accepts. > Both cases above should not lead to the behavior that adding the sender to > the attendee list. -- 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
[jira] [Commented] (JAMES-3250) Reduce log output
[ https://issues.apache.org/jira/browse/JAMES-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140438#comment-17140438 ] Ioan Eugen Stan commented on JAMES-3250: Looging is to help troubleshoot. You can configure multiple appenders and you can redirect loggers to them. You can stream loggers to a null appender also. Please use this option first and then propose changing the log level. Some log levels should be changed but please propose that once you have experience runing James in production and troubleshooted issues and realized: "This log information is not relevant and does not help at all." > Reduce log output > - > > Key: JAMES-3250 > URL: https://issues.apache.org/jira/browse/JAMES-3250 > Project: James Server > Issue Type: Improvement >Reporter: David Leangen >Priority: Major > > This issue is inspired from the Basic Server. While attempting to make this > server easier to use, we noticed many areas that could be improved that would > reduce the log output. > This issue is intended to capture those various related issues. -- 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
[jira] [Commented] (JAMES-3251) Reduce INFO chatter
[ https://issues.apache.org/jira/browse/JAMES-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140435#comment-17140435 ] Ioan Eugen Stan commented on JAMES-3251: Logging can be reduced by using more appenders and streaming loggers to different appenders. Please use this configuration opion first before proposing the change in the java source code of logging statements. You can use a console and multiple file appenders. You can log "org.apache.james.logger-that-you-deem-unworthy-of-basic-server" to one of the more verbose file appenders or to dev null if you like. This is documented on the slf4j website. We should add this information to the docs under operations - how to manage logging. I've created a logging documentation for the developers. They can be linked. > Reduce INFO chatter > --- > > Key: JAMES-3251 > URL: https://issues.apache.org/jira/browse/JAMES-3251 > Project: James Server > Issue Type: Sub-task >Reporter: David Leangen >Priority: Major > > > To start, there is lots of "INFO" chatter that is not necessary. > Maybe the "Basic Server operator" just needs to be aware of warnings & error, > we can increase the logging level. > We will need to better refine the "Basic server" application and split it > from the advanced server one. Once we do it, we should be able to address all > warnings & errors related to configuration. > We "may" put to the INFO level like org.apache.james.GuiceJamesServer > I believe a couples of annoying logs you mentioned should be addressed for > all James server distributions. -- 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
[jira] [Commented] (JAMES-2510) use a consistent artifact naming scheme
[ https://issues.apache.org/jira/browse/JAMES-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140426#comment-17140426 ] Ioan Eugen Stan commented on JAMES-2510: I've linked the Reorganize issue as I think as you [~matthieu] they are related. The group ID's will come after we decide the structure and what we deliver which we might have a clear view once we do the gradle migration (or not) It's a bit of a tangle but we'll pull through it. We should avoid taking too much on our plate at once to avid chaos. Let's discuss what we commit and in what order during the community call [~btellier] proposed. > use a consistent artifact naming scheme > --- > > Key: JAMES-2510 > URL: https://issues.apache.org/jira/browse/JAMES-2510 > Project: James Server > Issue Type: Task > Components: Build System >Affects Versions: 3.1.0 >Reporter: Matthieu Baechler >Priority: Major > > Maven modules have different naming scheme, for example : > * apache-james-* > * james-server-* > * protocols-* > it makes everything hard to read and to find and it's redundant because > groupId already gives context about an artifact. > I'll make a proposal to reduce the noise in our maven files. -- 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
[jira] [Commented] (JAMES-3259) Reorganize source code
[
https://issues.apache.org/jira/browse/JAMES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140416#comment-17140416
]
Ioan Eugen Stan commented on JAMES-3259:
Hi [~matthieu],
Thank you for opening this issue.
I'm also for re-organizing the code so you have my support.
Since we are considering a lot of changes, can we defer this re-organization
after we know about the gradle migration - to avoid havok ?
Until then we can talk and discuss about the merits of each solution.
I propose we organize the code more around products / business features /
functionality (the agents described in
https://en.wikipedia.org/wiki/Email_agent_(infrastructure) ).
We can probably find better names, but these are the generic names for the
final "products" that we can build from James components.
Gradle with composite builds can take care of shared projects.
```
Mail user agent (MUA)[4][5][6]
Mail submission agent (MSA)[7]
Mail transfer agent (MTA)[8][9][10][11]
Mail delivery agent (MDA)[8][12][13][14]
Mail retrieval agent (MRA)[15][16]
```
> Reorganize source code
> --
>
> Key: JAMES-3259
> URL: https://issues.apache.org/jira/browse/JAMES-3259
> Project: James Server
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Matthieu Baechler
>Priority: Major
>
> I want to suggest a new organization of the source-code (I won't handle every
> concerns but some important ones I have about the current state).
> I would like the first level to be:
> {code}
> core (domain code)
> data (that we should rename)
> docs
> extensions (containing mdn and third-party for example)
> infrastructure (containing backends-common, event-sourcing, json, metrics)
> mailbox
> mailet
> products (containing server/container/cli
> server/container/guice/cassandra-rabbitmq-guice)
> protocols
> server
> testing (containing mpt)
> {code}
> I'm not sure it's the best organization but:
> * it allows to see easily what james most important concepts are
> * put technical details into a common sub-tree
> * have products a top level thing instead of a hidden one
> * group what we think are extensions somewhere
> * put functional testing sources somewhere that is easy to find (because a
> lot of people starts by reading functional tests)
> What do you think?
--
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
[jira] [Commented] (JAMES-3226) Provide a process around documentation publishing and deployment
[ https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140412#comment-17140412 ] Ioan Eugen Stan commented on JAMES-3226: Great. We already have the branches: ``` remotes/apache/3.1.x remotes/apache/3.2.0 remotes/apache/3.2.x remotes/apache/3.3.x remotes/apache/3.5.x ``` > Provide a process around documentation publishing and deployment > > > Key: JAMES-3226 > URL: https://issues.apache.org/jira/browse/JAMES-3226 > Project: James Server > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > We have started working on the documentation and it's great. > We should also document the processes around documentation: > - when we publish the docs > - how to publish the docs > - where to publish the docs > - when we retire old docs ?! > This task should aggregate discussion and decisions. > The process should be written as asciidoc. > We decided to use antora as a documentation system so the features are going > to depend on that technology. > We should have documentation for every release we make. > This is important since people don't upgrade immediately after release and > might use an older release for some time. > I'm not sure if the documentation for all versions should be online. > We can build zip archives of each documentation release and include it in the > binary release or publish them for download next to it. > This way we can keep only the latest 1-3 versions online. -- 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
[jira] [Commented] (JAMES-2535) Add declaration order checks to checkstyle
[ https://issues.apache.org/jira/browse/JAMES-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140406#comment-17140406 ] Ioan Eugen Stan commented on JAMES-2535: I just read some gradle newsletter about some gradle plugins to help with these: https://github.com/openrewrite/rewrite-gradle-plugin https://github.com/diffplug/spotless Let's re-evaluate again when we know about the gradle decision. > Add declaration order checks to checkstyle > -- > > Key: JAMES-2535 > URL: https://issues.apache.org/jira/browse/JAMES-2535 > Project: James Server > Issue Type: Task >Reporter: Jean Helou >Priority: Minor > > Currently checkstyle doesn't check the declaration order of various class > components. This was made quite clear by > [https://github.com/linagora/james-project/pull/1681#discussion_r212547046] > The default checkstyle rules do not include a rule which would make such a > check possible but the incubator project for checkstyle > ([http://sevntu-checkstyle.github.io/sevntu.checkstyle/)] > I tried to add it but finding the correct order is not trivial and is quickly > escaping the scope of my current goal hence the issue. > Note that configuring this checkstyle for > [intellij|https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/How-to-use-SevNTU-Checkstyle-in-Intellij-IDEA] > and > [netbeans|https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/How-to-use-SevNTU-Checkstyle-in-NetBeans] > requires some additional efforts. Eclipse can be made to use a specfic > checkstyle plugin > Note that configuring this checkstyle for > [sonar|[https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/How-to-integrate-sevntu-checks-into-SonarQubeTM-(user's-guide)]] > requires some additional efforts > -- 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
[jira] [Commented] (MAILBOX-196) Add code example and quick start guide on how to consume a mailbox artifact
[ https://issues.apache.org/jira/browse/MAILBOX-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140389#comment-17140389 ] Ioan Eugen Stan commented on MAILBOX-196: - It's developer related guides on how to work with mailbox implementations from code. I will probably add more info when I get to ti. Right now it tracks the need for it. We (I) will re-evaluate this and make a decision when I get to it / or someone else gets to it before me. > Add code example and quick start guide on how to consume a mailbox artifact > --- > > Key: MAILBOX-196 > URL: https://issues.apache.org/jira/browse/MAILBOX-196 > Project: James Mailbox > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > -- 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
[jira] [Resolved] (JDKIM-45) Mime4j-core dependency is outdated
[ https://issues.apache.org/jira/browse/JDKIM-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan resolved JDKIM-45. -- Assignee: Ioan Eugen Stan Resolution: Fixed Glad it works. I'm closing this. > Mime4j-core dependency is outdated > -- > > Key: JDKIM-45 > URL: https://issues.apache.org/jira/browse/JDKIM-45 > Project: James jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2 >Reporter: Darren Bishop >Assignee: Ioan Eugen Stan >Priority: Major > > Dependency incompatibility issues when using JDKIM 0.2 with James 3.4.0. Both > have dependencies on the mime4j-core lib. JDKIM is using an older version of > the lib and one class in particular, MimeConfig, has been reimplemented in > the newer version that James uses. MimeConfig in the newer version of core > (James uses 0.8.2, JDKIM uses 0.7) has constants to define MimeConfig, ie: > PERMISSIVE - this doesn't exist in the older version. In addition, the older > version call's MimeConfig's default constructor which has been removed in the > newer version. -- 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
[jira] [Commented] (JAMES-3225) Provide automated builds for Apache James - (restore builds.apache.org ?)
[ https://issues.apache.org/jira/browse/JAMES-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139176#comment-17139176 ] Ioan Eugen Stan commented on JAMES-3225: Aaa, love the feedback so far :). [~btellier]: I don't know if Apache will manage the server. I think you will be able to do that. We can always ask on Slack #infra channel for this (I will post this issue there and hope to get some replies). Please ask internally what Linagora is willing to offer. We can both continue on Apache side. [~rcordier] and [~aduprat] :D . I'm up for the challenge. I have some time, I have experience with Gradle. Worked with it exclusively for the past 5 years. Please share your work. It is going to be a challenge, but I believe the results are going to be worth it. I would love for us to have a community call and discuss what we want out of this and setup how we are going to approach the move. This is to align our objectives and get to a common ground on this important issue. > Provide automated builds for Apache James - (restore builds.apache.org ?) > -- > > Key: JAMES-3225 > URL: https://issues.apache.org/jira/browse/JAMES-3225 > Project: James Server > Issue Type: Task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > > For a long time we had builds that ran on the Apache Infrastructure > https://builds.apache.org/view/All/job/james-mailet/ . > The build infrastructure is not running for ~ 3 years now. > I believe it is important for us to have automated builds. > This ticket should gather the work needed to make this a reality. > There are lots of things to take into consideration. > My ( [~ieugen] ) opinions on how to handle this. > * builds should run automatically > * builds should run fast < 10 min > * there are several things they should do (not exhaustive) > ** verify the source code > ** compile the source code > ** run the unit tests > ** run the integration tests > ** publish SNAPSHOTS (only from master or develop ?!) > ** run code analytics > ** publish reports relating to build > ** provide build status for other services > For smaller projects this is a no-brainer. > For the current state of Apache James this is a challange, especially in the > context of > - multiple git branches and PR's > - the distributed integration tests which take a long time > Given the limited resources available for us on the Apache infrastructure we > will have to be selective of what we do. > Personally I don't see how we can run the current (40mni +) integration suite > on each push / build. I'm pretty sure we will get banned :) or throttled. > So a discussion should be in order on how to solve these issues but some > options regarding what we can do: > - make integration tests OPT-IN > - run (distributed) integration tests once a day or once every 6h / 12h > - have build profiles that build a common subset all the time and run > The nuclear option: prune some of the components we have in James and we > don't want to support or move them out of the common project. > This is something we should consider especially for buggy components or for > components that don't have a maintainer. > We have limited time and resources. > We can't maintain everything for everybody. > We should be mindful of this. > We can take inspiration from the OFBiz project > https://builds.apache.org/view/All/job/Apache%20OFBiz/ . -- 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
[jira] [Commented] (JAMES-1065) Documentation on using sendmail with James is woefully out of date
[ https://issues.apache.org/jira/browse/JAMES-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139171#comment-17139171 ] Ioan Eugen Stan commented on JAMES-1065: [~dleangen] Please keep the links. They are valuable. They point to related things (in this case, both links relate to documentation and documenting James). I would also not close some issues if I believe they have value or it's something that we should at least consider doing. That is one of the reasons I skipped this issue in my "war on old issues" :D. > Documentation on using sendmail with James is woefully out of date > -- > > Key: JAMES-1065 > URL: https://issues.apache.org/jira/browse/JAMES-1065 > Project: James Server > Issue Type: Bug > Components: Documentation > Environment: All operating systems, platforms. >Reporter: Marc Chamberlin >Priority: Major > > Current documentation on using Sendmail with James, for all versions of > James, as seen on the website, is out of date and does not correspond to how > Sendmail is configured today. -- 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
[jira] [Commented] (JAMES-3217) Describe how to include dependencies for the James Basic Server
[ https://issues.apache.org/jira/browse/JAMES-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139168#comment-17139168 ] Ioan Eugen Stan commented on JAMES-3217: You have full write access. Be bold, be wild, work on a branch :). > Describe how to include dependencies for the James Basic Server > --- > > Key: JAMES-3217 > URL: https://issues.apache.org/jira/browse/JAMES-3217 > Project: James Server > Issue Type: Sub-task >Reporter: David Leangen >Priority: Major > > A working server requires the correct dependencies. > It should be easy for users to gather the right dependencies to set up the > James Local Server. -- 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
[jira] [Commented] (JAMES-3227) Can't assign JIRA issues to myself
[ https://issues.apache.org/jira/browse/JAMES-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139167#comment-17139167 ] Ioan Eugen Stan commented on JAMES-3227: You need to be a committer. And on that note, please be a little patient :) . > Can't assign JIRA issues to myself > -- > > Key: JAMES-3227 > URL: https://issues.apache.org/jira/browse/JAMES-3227 > Project: James Server > Issue Type: Bug >Reporter: David Leangen >Priority: Minor > Attachments: PastedGraphic-1.png > > > I am not able to assign JIRA issues to myself. -- 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
[jira] [Commented] (JAMES-3217) Describe how to include dependencies for the James Basic Server
[ https://issues.apache.org/jira/browse/JAMES-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139163#comment-17139163 ] Ioan Eugen Stan commented on JAMES-3217: The project there is a sandbox. I've set it up privately because I want to go full speed and I don't have to care about all the Apache requirements for it. It is meant as an exploration platform and I believe it has a lot of value to offer. It is my intention to take pieces of code and documentation from there and contribute them back to James. So see it as that - a place to experiment and try out things, a place to be bold and fast. In that sense the project will have an nginx email proxy long before it reaches Apache James. Once that is in place, we can find how we can contribute it back to James: as docs, as docs + code? > Describe how to include dependencies for the James Basic Server > --- > > Key: JAMES-3217 > URL: https://issues.apache.org/jira/browse/JAMES-3217 > Project: James Server > Issue Type: Sub-task >Reporter: David Leangen >Priority: Major > > A working server requires the correct dependencies. > It should be easy for users to gather the right dependencies to set up the > James Local Server. -- 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
[jira] [Commented] (MAILBOX-196) Add code example and quick start guide on how to consume a mailbox artifact
[ https://issues.apache.org/jira/browse/MAILBOX-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139154#comment-17139154 ] Ioan Eugen Stan commented on MAILBOX-196: - It's related to documentation. I don't expect you to be the only one working on that. Having links to things that is related is important IMO. If it does not bother you, and it's not wrong please don't change it. > Add code example and quick start guide on how to consume a mailbox artifact > --- > > Key: MAILBOX-196 > URL: https://issues.apache.org/jira/browse/MAILBOX-196 > Project: James Mailbox > Issue Type: Sub-task > Reporter: Ioan Eugen Stan > Assignee: Ioan Eugen Stan >Priority: Major > -- 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
[jira] [Resolved] (JAMES-1835) James Beta 5 Unable to parse message error when sending emails
[
https://issues.apache.org/jira/browse/JAMES-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ioan Eugen Stan resolved JAMES-1835.
Assignee: Ioan Eugen Stan
Resolution: Workaround
We have a workaround with Docker.
> James Beta 5 Unable to parse message error when sending emails
> --
>
> Key: JAMES-1835
> URL: https://issues.apache.org/jira/browse/JAMES-1835
> Project: James Server
> Issue Type: Bug
> Components: James Core
>Affects Versions: 3.0.0-beta5
> Environment: Windows 7
>Reporter: Dan Huru
> Assignee: Ioan Eugen Stan
>Priority: Blocker
>
> 1) Build 3.0.0-beta5
> 2) Run James server.
> 3) When sending an email to James I get the following:
> {noformat}
> INFO 15:03:03,073 | james.imapserver | ID=-449807885 Connection established
> from fe80:0:0:0:4507:61af:cf94:17c%20
> INFO 15:03:04,910 | james.imapserver | ID=-806960204 Connection established
> from fe80:0:0:0:4507:61af:cf94:17c%20
> INFO 15:03:28,036 | james.imapserver | ID=-806960204 Unable to append
> message to mailbox #private:t...@ro00040402.ericsson.se:Sent
> org.apache.james.mailbox.exception.MailboxException: Unable to parse message
> at
> org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:402)
> at
> org.apache.james.imap.processor.AppendProcessor.appendToMailbox(AppendProcessor.java:136)
> at
> org.apache.james.imap.processor.AppendProcessor.doProcess(AppendProcessor.java:73)
> at
> org.apache.james.imap.processor.AppendProcessor.doProcess(AppendProcessor.java:49)
> at
> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:98)
> at
> org.apache.james.imap.processor.AbstractMailboxProcessor.process(AbstractMailboxProcessor.java:87)
> at
> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:81)
> at
> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:69)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:52)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:54)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProc
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138745#comment-17138745 ] Ioan Eugen Stan commented on JAMES-2586: Thanks. It's a bit clear for me from where the difference in perspective comes from. For managing the project we have a few tools at our disposal: JIRA for issue tracking, mailing list and gitter for discussion, the documentation files, the James website. Each tool has a purpose and sure there is overlap between them. I don't believe I hold the absolute truth about how tools should be used and which tool is used for what. I would like to reach a common understanding so we can all work together to produce good software and enjoy life. Please keep this in mind while you read the next pieces of text. As you correctly pointed out, I do consider JIRA for issue tracking and doing the project management part. We also have github and this creates duplication and we should discuss this in another thread. I think ideas should be discussed on the mailing list. The mailing list is indexed and appears in google results. Mailing list serve this purpose - discuss ideas, offer support: https://www.apache.org/foundation/mailinglists.html . If the idea has merit and people are willing to work on it, we can use JIRA to track and coordinate. I don't think JIRA is a good place for ideas since it interferes with the project management part. For example in kubernetes they have thousands of issues. They mark them stale and rotten because otherwise they would be overwhelmed. We don't have thousands of open issues and I don't want to reach that number. Low number of issues means it's easy for us to focus on those things and get them done. It's easy for someone who joins the community to identity the current issues and work on them. > Implement a Postgres-specific backend > - > > Key: JAMES-2586 > URL: https://issues.apache.org/jira/browse/JAMES-2586 > Project: James Server > Issue Type: New Feature >Reporter: Matthieu Baechler >Priority: Major > > James has a JPA implementation of most interfaces that allows to deploy it on > top of some popular RDBMS. > However, while useful for some kind of applications, ORM are usually a bad > fit for applications requiring high performance like a mail server. > As an abstraction, it also prevents from using advanced features of a given > RDBMS. > For most usages, James would probably run great on top of Postgres, given > that we use advanced features to implement search, for example. > A good strategy would be to implement all interfaces implemented by JPA with > a modern Postgres driver. -- 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
[jira] [Resolved] (IMAP-273) Document imap web site for 0.2-M2 release
[ https://issues.apache.org/jira/browse/IMAP-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan resolved IMAP-273. -- Resolution: Abandoned I'm doing an issue cleanup. I'm closing this since it seems it is not relevant. Please reopen if you think it is. > Document imap web site for 0.2-M2 release > - > > Key: IMAP-273 > URL: https://issues.apache.org/jira/browse/IMAP-273 > Project: James Imap > Issue Type: Improvement > Components: Documentation >Reporter: Eric Charles >Assignee: Eric Charles >Priority: Major > > Document imap web site for 0.2-M2 release -- 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
[jira] [Resolved] (IMAP-369) NPE when connecting to apache-james-3.0-beta4 using incorrect user
[
https://issues.apache.org/jira/browse/IMAP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ioan Eugen Stan resolved IMAP-369.
--
Resolution: Abandoned
I'm doing an issue cleanup.
I'm closing this since it is for an old, beta version.
Please reopen if you think this applies to latest releases.
> NPE when connecting to apache-james-3.0-beta4 using incorrect user
> --
>
> Key: IMAP-369
> URL: https://issues.apache.org/jira/browse/IMAP-369
> Project: James Imap
> Issue Type: Bug
> Components: Protocol
>Reporter: Michael Saladin
>Priority: Major
> Attachments: adnjames_conf_folder.tar
>
>
> {code:title=Bar.java|borderStyle=solid}
> Affects version (I could not choose this version in the Affects version
> dropdown):
> ./lib/james-server-protocols-imap4-3.0-beta4.jar
> When I connect to the James server using Thunderbird 11.0.1 as client with a
> wrong username, and set the logging level of the James server to TRACE, I get
> the following:
> {code}
> INFO 09:49:53,815 | james.imapserver | ID=553374 Connection established from
> 127.0.0.1
> DEBUG 09:49:53,816 | james.imapserver | ID=553374 Got : 1
> DEBUG 09:49:53,816 | james.imapserver | ID=553374 Got : capability
> DEBUG 09:49:53,817 | james.imapserver | ID=553374 No mailbox selected
> DEBUG 09:49:56,901 | james.imapserver | ID=553374 Got : 2
> DEBUG 09:49:56,901 | james.imapserver | ID=553374 Got : authenticate
> DEBUG 09:49:56,931 | james.imapserver | ID=553374 Got : 4
> DEBUG 09:49:56,932 | james.imapserver | ID=553374 Got : login
> DEBUG 09:49:59,847 | james.imapserver | ID=553374 Got : 6
> DEBUG 09:49:59,847 | james.imapserver | ID=553374 Got : authenticate
> INFO 09:49:59,849 | james.imapserver | ID=553374 Too many authentication
> failures. Closing connection.
> DEBUG 09:49:59,853 | james.imapserver | ID=553374 Error while processing imap
> request
> java.lang.NullPointerException
> at
> org.apache.james.imapserver.netty.ImapRequestFrameDecoder.createCumulationDynamicBuffer(ImapRequestFrameDecoder.java:211)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.cumulation(FrameDecoder.java:367)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:210)
> at
> org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.run(ChannelUpstreamEventRunnable.java:44)
> at
> org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor$ChildExecutor.run(OrderedMemoryAwareThreadPoolExecutor.java:312)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> INFO 09:49:59,855 | james.imapserver | ID=553374 Connection closed for
> 127.0.0.1
> INFO 09:49:59,887 | james.imapserver | ID=12914246 Connection established
> from 127.0.0.1
> DEBUG 09:49:59,888 | james.imapserver | ID=12914246 Got : 1
> DEBUG 09:49:59,888 | james.imapserver | ID=12914246 Got : capability
> DEBUG 09:49:59,889 | james.imapserver | ID=12914246 No mailbox selected
> DEBUG 09:49:59,889 | james.imapserver | ID=12914246 Got : 2
> DEBUG 09:49:59,890 | james.imapserver | ID=12914246 Got :
> authenticate
> DEBUG 09:49:59,892 | james.imapserver | ID=12914246 Got : 4
> DEBUG 09:49:59,892 | james.imapserver | ID=12914246 Got : login
> INFO 09:50:03,090 | james.imapserver | ID=12914246 Connection closed for
> 127.0.0.1
> INFO 09:53:26,765 | james.imapserver | Dispose IMAP Service
> INFO 09:53:26,769 | james.imapserver | Dispose IMAP Service done
> {code}
> This happens with a very easy default configuration:
> Correct username: bob@localhost
> Wrong username: bob
> It happens when connecting to the IMAP server using the wrong username (bob).
> See attached TAR for whole configuration.
--
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
[jira] [Resolved] (IMAP-381) Required Apache James version 3.0 beta 3 or version after 2.3 and before 3.0 beta 4
[ https://issues.apache.org/jira/browse/IMAP-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan resolved IMAP-381. -- Resolution: Abandoned I'm doing an issue cleanup. I'm closing this since it is for an old, beta version. > Required Apache James version 3.0 beta 3 or version after 2.3 and before 3.0 > beta 4 > --- > > Key: IMAP-381 > URL: https://issues.apache.org/jira/browse/IMAP-381 > Project: James Imap > Issue Type: Wish >Reporter: Shivang Goel >Assignee: Eric Charles >Priority: Major > > Dear sir, > I need Apache James version 3.0 beta 3 or version after 2.3 and before 3.0 > beta 4, From where i can download required version. Apache james site > providing only 2.3 and 3.0 beta 4 version. -- 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
[jira] [Resolved] (IMAP-382) IMAP Read Timeout Error- james imap stops responding after sometime when accessed continuously.
[ https://issues.apache.org/jira/browse/IMAP-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan resolved IMAP-382. -- Resolution: Abandoned I'm doing an issue cleanup. I'm closing this as it is for an old, beta version. Please reopen if it still an issue with latest code. > IMAP Read Timeout Error- james imap stops responding after sometime when > accessed continuously. > --- > > Key: IMAP-382 > URL: https://issues.apache.org/jira/browse/IMAP-382 > Project: James Imap > Issue Type: Bug > Environment: James mail server 3.0 beta 5 (build from trunk of date > 01/10/2014) >Reporter: ajay kumar >Assignee: Eric Charles >Priority: Critical > > When we use the james mail server for sending & receiving mail. then after > some time IMAP of james stop responding. > Then we have to restart the james to make it working again > When we use POP3 Instead of IMAP. Then james work fine. > In comparison of beta 4 version, the frequency of this issue reduced in beta > 5 trunk build (01/10/2014). But still we are facing this issue -- 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
[jira] [Resolved] (JAMES-1537) IMAP in James mail server 3.0 beta 4 stops responding after some time .
[ https://issues.apache.org/jira/browse/JAMES-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ioan Eugen Stan resolved JAMES-1537. Assignee: Ioan Eugen Stan Resolution: Abandoned I'm doing an issue cleanup. I'm closing this as it is for an old, beta version. Please reopen if this is still an issue. > IMAP in James mail server 3.0 beta 4 stops responding after some time . > - > > Key: JAMES-1537 > URL: https://issues.apache.org/jira/browse/JAMES-1537 > Project: James Server > Issue Type: Bug > Components: IMAPServer, James Core >Affects Versions: 3.0-beta4 > Environment: window 7 >Reporter: ajay > Assignee: Ioan Eugen Stan >Priority: Blocker > Attachments: TestJames.java > > > When we use the james mail server for sending & receiving mail. then after > some time IMAP of james stop responding. > It do not give any exception in james log. From mail client i get socket > read timeout error. > Then we have to restart the james to make it working again > When we use POP3 Instead of IMAP. Then james works fine. > To reproduce this quickly. > I created a sample mail client which do repeatedly - login, load inbox , > send mail, logout . And this issue occurs in max 15 min. > I have attached sample test program. -- 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
