Profiles to groups specs (individual, full, web-profile)

[arjantijms]

By putting modules in a profile we can easily run the samples per spec, for the full profile or the web profile.

E.g.

        <profile>
            <id>jaspic</id>
            <modules>
                <module>jaspic</module>
            </modules>
        </profile>

        <profile>
            <id>full-profile</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <modules>
                <module>batch</module>
                <module>cdi</module>
                <module>concurrency</module>
                <module>ejb</module>
                <module>el</module>
                <module>interceptor</module>
                <module>javamail</module>
                <module>jaspic</module>
                <module>jacc</module>
                <module>jaxrs</module>
                <module>jaxws</module>
                <module>jca</module>
                <module>jms</module>
                <module>jpa</module>
                <module>jta</module>
                <module>jsf</module>
                <module>json</module>
                <module>servlet</module>
                <module>validation</module>
                <module>websocket</module>
            </modules>
        </profile>

After this you can do e.g.

mvn -Pwildfly-managed-arquillian,jaspic test

or

mvn -Pwildfly-managed-arquillian,jpa test

etc

I can do a PR for this.

[aheusingfeld]

I might be missing something but given your example, what's the difference to
"mvn -pl jaspic -P wildfly-managed-arquillian", meaning explicitly name the project/ submodule to be build? Maven already provides the option to build all dependent modules (see http://books.sonatype.com/mvnref-book/reference/_using_advanced_reactor_options.html).

[arjantijms]

Maybe I'm just not smart enough to fully understand how Maven works, but for some reason -pl has just never worked for me. It certainly doesn't seem to work when using Eclipse. With the -pl jaspic option it just does the following and nothing more:

[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building Java EE 7 Sample: jaspic 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (default) @ jaspic ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.534 s
[INFO] Finished at: 2015-11-08T09:37:22+01:00
[INFO] Final Memory: 52M/375M
[INFO] ------------------------------------------------------------------------

E.g. it builds, but never starts the tests despite using the "test" goal. I'm aware I may be doing something wrong as I'm not the biggest Maven expert in the world.

The profile has the additional advantage though that we can use "web-profile" to test TomEE and "full-profile" to test the other servers.

[johnament]

if you do -pl jaspic it only runs that one project, it doesn't run child modules. if you do mvn -f jaspic/ you'll run jaspic and children.

[arjantijms]

Hmmm

-f, --file <file>
Forces the use of an alternate POM file

Who would have guessed, but I'll give it a go. Thanks!

[johnament]

Why's that? You're basically looking for a shortcut for cd jaspic && mvn clean install

[arjantijms]

Why's that? You're basically looking for a shortcut for cd jaspic && mvn clean install

I tried that a long time ago, but it doesn't work out of the box.

For the Java EE samples project doing just that results in this:

[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.732 s
[INFO] Finished at: 2015-11-08T23:50:11+01:00
[INFO] Final Memory: 19M/226M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project jaspic-common: Could not resolve dependencies for project org.javaee7:jaspic-common:jar:1.0-SNAPSHOT: Could not find artifact org.javaee7:test-utils:jar:1.0-SNAPSHOT -> [Help 1]

And after cd test-utils && mvn install:

[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.938 s
[INFO] Finished at: 2015-11-08T23:56:13+01:00
[INFO] Final Memory: 19M/220M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project jaspic-common: Could not resolve dependencies for project org.javaee7:jaspic-common:jar:1.0-SNAPSHOT: Failed to collect dependencies at org.javaee7:test-utils:jar:1.0-SNAPSHOT: Failed to read artifact descriptor for org.javaee7:test-utils:jar:1.0-SNAPSHOT: Could not find artifact org.javaee7:samples-parent:pom:1.0-SNAPSHOT -> [Help 1]

So then I need to install the parent pom, and with it all child modules? It will then start to run all tests as well, so I'd need to find the command to not run (skip) the tests.

Plus that I need to monitor carefully when doing pulls if any of the dependent installed modules have changed.

All of this is not really user friendly, unless there's a better way that I don't know of (as said, I'm not the biggest Maven expert), the profile option may be easier to explain as it does run out of the box.

[radcortez]

This takes me to another thing that was discussed some time ago, but without any conclusion:

Split the projects so they can be cloned per spec.

[arjantijms]

Indeed, that's a bit similar. I thought the profiles would be a simpler thing though. Unless the project gets overwhelmingly huge, I'm not entirely sure cloning is the real issue. I don't have the fastest Internet connection in the world and the entire repo clones relatively fast.

What I think you almost always want is restrict the test run to a single module.

In theory when reading the documentation it looks like Maven claims to be able to build dependent modules when giving it a module to build, but in practice it just always bails out with supposedly not able to find something that logically you'd say it should be able to build.

If someone knows a better way I'm all for it, but the profiles thingie just seems like a very simple solution that actually works. Only small downside is that when specifying a profile for another server than the default you also have to specify the profile for the tests (at least, as far as I can tell).

[radcortez]

Is not only a matter of being faster to clone. It's because sometimes developers are only interested in a single spec and they have to mount the entire project in their IDE.

Also, it allows you to branch and implements tests for new standalone versions of the specs.

[arjantijms]

It's because sometimes developers are only interested in a single spec

That's utterly clear. I hear this all the time.

they have to mount the entire project in their IDE.

At least in Eclipse when you clone the entire project it's just a folder initially. After that you can import all projects or just individual projects (right click on module -> import -> maven -> existing maven project). But if this is different in other IDEs I can see how this can be a problem indeed.

Then only one question remains: Shall I do the PR as indicated in the beginning of this issue for the short term, while we look how to do the splitting up to individual projects? The latter may a bit more work, and I suppose we have to publish the parent dependencies in a Maven repo then? Or shall I close this issue, and wait, how long it may take, for that splitting up to happen?

[radcortez]

I guess we can work with the profiles for the moment, until we figure out what is the best approach to split the project.

Also, I feel that we need more contributors involved to make a final decision on that particular item.

[arjantijms]

Okay, sounds like a plan.

One additional thing to do is adjusting the CI jobs then. I'm not sure how much love these get at the moment. They seem to have defaulted to GlassFish now, meaning it's not the pom.xml default profile, so the module set to test would have to be specified then.

[radcortez]

I'm not even sure what CI are we using atm. For some time, we were using Cloudbees, but I guess it was abandoned.

[arjantijms]

The link on the main project page still points to Cloudbees: https://javaee-support.ci.cloudbees.com but it hasn't worked for some time.

A PR kicks of a CI build using travis-ci.org, see e.g. https://travis-ci.org/javaee-samples/javaee7-samples/builds/89004029

[radcortez]

Ok, we also need to make sure that this is set up properly. I don't have much experience with Travis.