Cleanup module structure

[bartoszmajsak]

As we are growing in size having everything under one big module bag is not really the best idea. It's very unfriendly for IDEs (not only for Eclipse to be honest). Therefore I would like to open the discussion on how we should slice the repo. We already have main modules covering different aspects of JavaEE platform in the dedicated sub-folders so those would be good candidates for me. What are your thoughts?

[arun-gupta]

AFAIK the repo is structured by technology only. Do you have alternative cleaner proposals ?

[bartoszmajsak]

I was thinking about changing the project structure, so that it won't be one big bag of everything taking ages and tons of disk space to build, but rather parent-pom and submodules being a projects on their own and just referring to it.

On the other hand we might think about putting wildfly container when executed in the managed mode in a single location instead of spawning it for each and every module build and putting it to all the **/target folders.

[radcortez]

I understand your points, but I think that if we split by the submodules, its going to explode too many projects. Maybe aggregate them by layers? Web (Servlet, JSF, etc), Server (JPA, EJB, etc) and so on? Probably not the best solution.

Agree on the Wildfly container single location. Don't know if you can do that, but worth investigating. Feel free to create an issue and assign it to me :)

[arun-gupta]

IIRC single container installation need to be implemented in Arquillian. @aslakknutsen ?

[aslakknutsen]

The single install is just a Maven setting. The problem was I couldn't find any option in Maven that defined parent-root. It was always relative to target module.

e.g.

mvn clean install <-- could get all to target a single root
mvn clean install -F jaxrs/pom.xml <-- this would create a new install under jaxrs

Unless we make it some 'external file ref', e.g. java.io.tmpdir

[bartoszmajsak]

I was thinking about "external file ref" actually. This adds minimal setup effort (IDE mainly), but should give us a bit more resource-friendly approach. I think DeltaSpike folks did that @LightGuard?

[bartoszmajsak]

Any thoughts on that? Stuff is growing.... and failing constantly. We don't see any problems with it?

Do we actually know which modules are healthy?

[arjantijms]

and failing constantly. We don't see any problems with it?

No, I don't think so. It's the intention of tests to fail, since they are pointing out bugs in the servers. For instance I just added a JASPIC test that fails on GlassFish but succeeds on JBoss. The fact that the tests fails on GlassFish is not a problem with the test or an indicator of the health of a module, but it points out GlassFish doesn't implement the JASPIC spec correctly here.

Of course sometimes failing tests ARE an issue, since for some tests JBoss needs to configured in standalone.xml, and when a new JBoss server is installer or migrated that configuration is now always done again and the tests depending on it fail.

However, that too is not really an issue with the tests themselves, but an issue for the environment configuration.

It's very unfriendly for IDEs (not only for Eclipse to be honest).

In Eclipse Mars you can now have hierarchical projects. See e.g. http://tools.jboss.org/blog/2015-02-23-alpha1-for-mars.html

This makes working with the modules much friendlier. We could additionally go for @radcortez suggestion of organizing per layer.

[radcortez]

I think it would be cool if we set up the sample in a way that people just need to checkout the sample that they need. I already have a few persons asking me for help because they were only interested in one particular sample and needed to checkout and mount in the IDE the full project.

[arjantijms]

. I already have a few persons asking me for help because they were only interested in one particular sample and needed to checkout and mount in the IDE the full project.

I have somewhat of the same issue. I work with several vendors to help improve their JASPIC implementation based on the test results, and often tell them to just comment out all modules except for jaspic and the common one.

For that particular situation the checkout itself isn't the real problem, but waiting for all tests to have run before it finally starts doing the tests you're interested in is problematic. Maven has some provisions for running specific tests but they are not it either.

You'd want to say: build just the jaspic module run its tests.

[bartoszmajsak]

No, I don't think so. It's the intention of tests to fail, since they are pointing out bugs in the servers. For instance I just added a JASPIC test that fails on GlassFish but succeeds on JBoss. The fact that the tests fails on GlassFish is not a problem with the test or an indicator of the health of a module, but it points out GlassFish doesn't implement the JASPIC spec correctly here.

I do see several problems with such an approach. First of all with having unstable builds we do not really know what is working where exactly. The structure is far from what I would personally consider fast feedback loop. This can easily lead to sneaking in regressions or simply bad code (I would also strongly advise some informal code reviews for any PR). At the end of the day build is simply useless.

Another problem is how we should actually treat these "samples" - as a TCK or a library of simple, yet useful examples which can be used as a foundation in Java EE project. If we consider former we should think about having test categories as well as several builds running our "TCK" against different servers. If we think about latter having a project in such a condition does not advertise Java EE as a solid technology choice to build your app on. Just my personal feeling.

In Eclipse Mars you can now have hierarchical projects. See e.g. http://tools.jboss.org/blog/2015-02-23-alpha1-for-mars.html

How well does it work? Any experience with "building workspace" issue?

You'd want to say: build just the jaspic module run its tests.

How about mvn clean verify -pl jaspic-module?

[johnament]

I think the key thing is the sheer quantity of modules in the project. To me, there are too many and even someone just looking at it, way too many. I feel bad because last year at JavaOne I volunteered to fix the build issues for Arun, but can't due to how its structured.

I would prefer a module per technology, and tests representing the functionality needed.