We are ready to start testing on EAP 6.1 but it isn't as easy as with AS 7.1.1 because EAP's binaries aren't in Maven repository.

What is suggested workaround?

The download-plugin could be used:

https://github.com/maven-download-plugin/maven-download-plugin

However when you do "clean" step, the downloaded distribution will be deleted.

The solution would be using "download -> install to Maven repository -> unpack" procedure.

I belive there is a plugin which can do so.

We used to use download plugin for Tomcat distributions but it showed to be quite unreliable. Now we just have Tomcat downloaded on the disk and provide Maven a path to Tomcat zip.

Installing zip to local Maven repository would solve it, however you still need to download it somehow so it's basically the same as what we do for Tomcat.

However this setup needs to be reproducible by anyone, without any assumptions about target environment.

It means the ZIP distribution needs to be:

• downloaded
• cached
• unpacked

independently on the user.

In case of AS 7.1.1.Final, it is all achieved using Maven.

Question is whether we are able to achieve that with EAP 6.1.0.Alpha1.

Since EAP 6.1.0.Alpha1 is in Maven repository now, I updated Arquillian profile jbosseap-managed-6-1 and also created Jenkins job for Metamer. Now it works in the same way as job for JBoss AS 7.1.1.Final.

Pavol, could you please go ahead and define this profile in richfaces5 as well?

Hi,

sure, I can prepare a new profile. However, a new Maven repository is needed [1]. What is our strategy about Maven repositories? Do we want to put it in pom.xml or in custom settings.xml?

[1] http://maven.repository.redhat.com/techpreview/all

I hesitate to add repositories directly to pom.xml, it's good practice to let user decide from which repository/mirror to obtain artifacts from.

We can always provide this settings.xml - there is buildhive-settings.xml which can be renamed and used as the reference for what repositories need people active in order to get RF built successfully.

Note that not all of our dependencies are in Maven central

• in a development time - we depend on snapshots, which are just in JBoss snapshots repo
• in a release - e.g. jsf-test is build dependency which is not propagated to Central

therefore people who wants to build RichFaces needs to have recommended JBoss repository settings anyway.

Brian Leathem wrote:

 

SNAPSHOT dependencies can be built locally.  We should included instructions on building all SNAPSHOT dependencies.

I would really avoid this - these dependencies are build regularly with Jenkins and pushed to the JBoss snapshots repo - no need to document that.

\

In the release, we need to turn those into released artifacts anyway otherwise we won't meet release staging criteria, so released artifacts doesn't depend on snapshots at all.

Brian Leathem wrote:

 

Performing a release is not a typical use case for building RichFaces.  We need to make sure that it is easy to build the RichFaces project after a git clone without a lot of client side steps for the most basic use cases.  Releases and CI can be considered advanced use cases of the build, and are complexity is more tolerable (although still not ideal!).

I rather meant "building a release version" - we need to depend on released versions of build dependencies, jsf-test is one of these basic dependencies.

Additionally we can't simply get rif od many dependencies, even though they might not be directly required in basic profile - since they are referenced in build module (various BOMs) or build-resources module (e.g. Arquillian deps), the Maven will need to download them anyway.

Brian Leathem wrote:

 

If we truly need the JBoss SNAPSHOTS repository to be able to do this build, let's consider putting the repository definition in a profile in the pom.  In this way we can tell people to build the profile with the SNAPSHOT repository active.

 

Brian

We can put them into own profile, but it's strongly discouraged to place repositories settings into pom.xml directly - it will break our staging and productization process (both use restricted repository list).

Brian Leathem wrote:

 

As we make these decisions, let's keep in mind the perspective of those not familiar with the project:

 

"As a potential RichFaces contributor I want to be able to checkout and build the project as easily as possible so I can focus on fixing my issue."

 

 

Brian

I can't see anything simpler then:

$ cd richfaces5/
$ mvn clean install -s settings.xml

It's imho better than referencing to JBoss Maven Getting Started.