Thanks all for your answers. I retried to import in Eclipse using M2E.
Discover m2e connectors - Those that cannot be resolved:
- openjpa-maven-plugin:3.0.0:enhance
- swagger-maven-plugin:3.1.7:generate
That is showing 191 errors with the following projects in red:
- apache-james-mailbox-jpa
- james-server-data-jpa
- james-server-webadmin-data
- james-server-webadmin-mailbox
- james-server-webadmin-mailqueue
- james-server-webadmin-mailrepository
- james-server-webadmin-swagger
I guess I could ignore them if I were not trying to debug the JPA
implementation :)
I recall having to do these class enhancements for JPA a long time ago, but
not in recent projects (that is why with that need + the old Spring
library, I felt like that James project was using old tech, but actually,
you are on the edge on most sub-projects and have some legacy that you do
not maintain). So maybe switching from OpenJpa to Hibernate would remove
that enhancement need and make it debuggable. (I could take a look if that
is something that might be of interest)
My other issues were about the documentation:
- In the Wiki, I turn in round and cannot find any real dev doc.
- This morning, I just saw that the project itself had a very big
README file, so I will read that and that would be very helpful :)
- On the download page (
https://james.apache.org/download.cgi#Apache_James_3.2.0_is_the_stable_version
), as a user
- I saw the main application is apache-james-3.2.0-app.zip and is
using Spring
- Then, there are 2 other flavors using Guice
- What I understood from that is that we should be using the Spring
one ; not that Spring was in decay :)
- Now looking at the readme, the Spring example is in minority and is
the last one. That shows what you guys are saying: that Guice is
the way to
go
With all that, is there any place were the roadmap shows:
- Current suggested tech to use (Guice + Cassandra + ...)
- Which parts are in decay (Maybe JDBC (since I remember reading that
JPA was recommended over JDBC), JPA, Spring, ...)
- Which parts are do much in decay that they should be deprecated and
removed later on
thanks
On Tue, 19 Mar 2019 at 04:48, Matthieu Baechler <matth...@apache.org> wrote:
> Hi Simon,
>
> On Mon, 2019-03-18 at 13:31 -0400, Simon Levesque wrote:
> > Hi Raphael,
> >
> > I am using Eclipse IDE 2018‑12 .
> >
> > > Once installed the Maven Eclipse plugin, you can safely ignore
> > > these
> > Maven features.
> > I was ignoring them, but the code won't compile, so I cannot run it.
>
> Are you sure the warnings are related to your compilation problem?
>
> > > About old libraries, can you be more precise?
> > I am mostly talking about the core platform: Spring 3. Spring 4 is
> > available since December 2013 and Spring 5 since September 2017 .
> > Also using mostly the Spring XML configuration instead of the
> > Java @Configuration annotations.
>
> About Spring, most of us prefer Guice DSL over Spring XML or Spring
> annotations, it's why we invested so much on Guice "products" and we
> only maintain Spring in its current state.
>
> Given the number of technologies used in James, it's almost impossible
> to have a Spring project where all implementations are available
> without conflicts between libraries, so the XML strategy used in the
> past won't scale.
>
> > This project is the first one I saw using OpenJPA and I saw that
> > Spring 4
> > and 5 dropped its support since the industry leaders are Hibernate
> > and
> > EclipseLink, so the upgrade might be chaotic, but if JPA was used
> > correctly, it should be easy to switch to Hibername or EclipseLink.
> > Are you
> > planning on changing the JPA provider?
>
> Last years we worked on the distributed James implementation
> (Cassandra, Elasticsearch, RabbitMQ). We didn't worked much on RDBMS
> implementation.
> There are better JPA implementation, of course, and if you want to work
> on this, you are welcome. For now, we don't really have customers that
> requires RDBMS deployments so we probably won't invest on that in the
> near future.
> By the way, I personally think that if we were to use a RDBMS, we would
> implement a Postgresql specific backend instead of using an
> abstraction. It would allo to implement all required storage backends
> (including complex search), use a reactive driver with great
> performance while targeting a very good RDBMS system.
>
> If someone feels brave enough to give it a try, I would do the
> mentorship with great pleasure.
>
> Cheers,
>
> --
> Matthieu Baechler
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>
