[tomeicher]

Ok... but ... there will be open source AS 7.1 and 7.2 binary releases in the future ?

Or is it: use EAP binary for development and build open source from source if you want to use in a product ?

[brian.stansberry]

There will not be any further binary releases from the AS7 project's 7.x series. As Mark Little noted in his blog, there will be no other community releases for a community AS major version once we start to productise the community project. For AS 7.x that has already been done with EAP 6.

The next binary releases will be for the 8.x series.

See also the FAQ about this.

[tomeicher]

Thanks for the clarification.

Well, I find it quite hard to realize this as a "great step in the evolution of JBoss/Red Hat and enterprise open source in general" (Mark Little).

More like 2 steps backwards, if you ask me (what no one does ;-)

[jrantav]

Thank you! I think this is definitely good news if you compare it to the knowledge we have had for last couple of weeks or months. What'll happen in the long run remains to be seen, but at least I understand now what is happening.

[morphy]

I must say I was suspicious... but after reading the FAQs (http://www.jboss.org/jbossas/faq) I must admit I like the model (if I properly understand)

community final (no more) -> eap alpha (from now on)

eap beta -> eap -> commercial

easier model, same outcome: community reelases in production envs are a standard (de facto) but... deprecable...

hence, from now on, the community can refer to the eap alpha...

thank you, I say again, thank you because it seems to me that's an excellent balance between business needs and community needs

[jason.greene]

Riccardo Pasquini wrote:

I must say I was suspicious... but after reading the FAQs (http://www.jboss.org/jbossas/faq) I must admit I like the model (if I properly understand)

community final (no more) -> eap alpha (from now on)

eap beta -> eap -> commercial

It's a little different than that. The big difference is we are going to be speeding up the release speeds soon-to-be-renamed community project (I will just call it "community" for now) which will look a lot more like the way RHEL and Fedora work. You are right though in that Alphas allow the community to get free access to a less hardend version on our enterprise branches. The zero-dollar developer subscription expands access into all of our enterprise releases.

So it will look like (note this is just a hypothetical because schedules are still in planning phases)

Community Parallel: 7.0.x -> 7.1.x -> (7.2)   ->   Community 8 releases -> Community 9 releases  -> Community 10 releases -> Community 11 releases

JBoss EAP6 Parallel:                          ^ EAP 6.1 Alpha  -> 6.1.x releases -> EAP 6.2 Alpha ->  EAP 6.x release stream continues (up to 10 years depending on contract etc)

JBoss EAP7 Parallel                                                                                                              ^ EAP 7.0 Alpha (Perhaps based from 9 Final) -> EAP 7.x release stream (up to 10 yrs)      

thank you, I say again, thank you because it seems to me that's an excellent balance between business needs and community needs

Glad you like it!

[henk53]

First of all, I'm happy to see the EAP builds being brought into the light for the community. There appeared to be quite some amount of developers who had been using JBoss AS for quite some time, and really had no idea there were "better" builds available with EAP. Hopefully they will be more aware of what EAP is now

Jason Greene wrote:

It's a little different than that. The big difference is we are going to be speeding up the release speeds soon-to-be-renamed community project (I will just call it "community" for now)

I posted this on Mark's blog, but I'll repeat it here:

Maybe a bit of a radical idea, but why not throw away all those new names AND the "AS" name, and ONLY have "JBoss EAP" with a major version number that's aligned to the Java EE spec?

So

JBoss EAP 6.0 - Java EE 6

JBoss EAP 6.0.1 - Java EE 6, with bug fixes

JBoss EAP 6.1.Alpha - Java EE 6, with new proprietary features, for the community

JBoss EAP 6.1.Final - Java EE 6, with new proprietary features, for the subscribers and developers

...

JBoss EAP 7.0 - Java EE 7

...

What do you think?

[b.eckenfels]

I have BTW compared 7.2.0.Final with EAP 6.1.0.Alpha and produced a series of commits on GitHub which group differences between the two. I did not add all changes (because I did not want to commit the EAP welcome content artifacts), but beside that all of the Alpha Changes are in there.

And I must say, the changes are quite ugly (removing build profiles, removing community content, shipping new content which could be in the community source) but besides that no code changes (besides removing openjpa and some config) is in the Alpha:

https://github.com/ecki/jboss-as/compare/7.2.0.Final...eap-6.1

Keep in mind the Commits are created by me interpreting the actual changes, they are by no means from the actual RedHat work (especially the commit messages are mine). It is unfortunate that RedHat is not releasing at least those commits which lead to the published source. Not to mention that the Version number from 7.2.0.Final to 7.2.0.Alpha-redhat-4 is totally confusing.

[tomeicher]

Bernd, this is very interesting.

There was some talk about EAP being a "higher quality version" - I really saw nothing like that in your changeset.

So this is just a marketing stunt after all ?

(and definetly a step backwards, providing a "free as in beer commercial product" rather than a "free as in freedom OSS product")

Will downloading the 7.2.0.Final from github and calling build.sh give me the same thing that was a binary release in former times ?

Or is there more magic involved ?

[ctomc]

Tom Eicher wrote:

Bernd, this is very interesting.

There was some talk about EAP being a "higher quality version" - I really saw nothing like that in your changeset.

So this is just a marketing stunt after all ?

(and definetly a step backwards, providing a "free as in beer commercial product" rather than a "free as in freedom OSS product")

Will downloading the 7.2.0.Final from github and calling build.sh give me the same thing that was a binary release in former times ?

Or is there more magic involved ?

EAP 6.1.0.Alpha == 7.2.0.Final that was and is the "marketing statement" as you call it all along.

But after alpha there are lots of fixes,changes and certifications done before it reaches .GA state.

This is the something that was same also before(EAP5 vs AS5.1, EAP6 vs as7.1), only difference is that now binaries for inital alpha build are avalible to community without any limitations.

And yes, if you build your code from tag 7.2.0.Final on github you will get basicly the same binary (minus the branding aka what Bernd pointed out)

--

tomaz

[tomeicher]

except that 7.2.0.Final from github does not build out-of-the-box :-(

java.lang.RuntimeException: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact org.jboss.as:jboss-as-core-model-test-framework:jar:7.2.0.Alpha1-SNAPSHOT in jboss-developer (http://repository.jboss.org/nexus/content/groups/developer/)

        at org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:112)

        at org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:79)

        at org.jboss.as.core.model.test.CoreModelTestDelegate$LegacyKernelServicesInitializerImpl.install(CoreModelTestDelegate.java:553)

        at org.jboss.as.core.model.test.CoreModelTestDelegate$LegacyKernelServicesInitializerImpl.access$300(CoreModelTestDelegate.java:526)

        at org.jboss.as.core.model.test.CoreModelTestDelegate$KernelServicesBuilderImpl.build(CoreModelTestDelegate.java:493)

        at org.jboss.as.core.model.test.deploymentoverlay.DomainDeploymentOverlayTransformersTestCase.testDeploymentOverlaysTransformer_7_1_x(DomainDeploymentOverlayTransformersTestCase.java:220)

        at org.jboss.as.core.model.test.deploymentoverlay.DomainDeploymentOverlayTransformersTestCase.testDeploymentOverlaysTransformer(DomainDeploymentOverlayTransformersTestCase.java:82)

Despite many statements from many people, I still wonder what is the reason for not prodiving a 7.2.0.Final binary for download ? (Other than annoy non-EAP users?)

Surely somebody at JBoss must have successfully build the 7.2.0.Final - adding it to the download page can not be that big an effort !?  ;-)

[ctomc]

Tom Eicher wrote:

except that 7.2.0.Final from github does not build out-of-the-box :-(

java.lang.RuntimeException: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact org.jboss.as:jboss-as-core-model-test-framework:jar:7.2.0.Alpha1-SNAPSHOT in jboss-developer (http://repository.jboss.org/nexus/content/groups/developer/)

This was bug in tagging process that we didn't notice soon enough, as it would only show if you have empty local maven repo (aka you never bould 7.2.0.alpha1-snapshot)...

you can build it by running mvn clean install -DskipTests

that will just skip testsuite which is where the problem occurs. you will still end up with working binary that would be the same.

you can also fix it yourself by changing one line in testsuite, this was proper fix https://github.com/jbossas/jboss-as/commit/23237531bf850c44ecba5cb50151e73a4654a175 (there was one better commited bit later)

--

tomaz

[b.eckenfels]

This was bug in tagging process that we didn't notice soon enough, as it would only show if you have empty local maven repo (aka you never bould 7.2.0.alpha1-snapshot)...

you can build it by running mvn clean install -DskipTests

that will just skip testsuite which is where the problem occurs. you will still end up with working binary that would be the same.

It would be good to have a 7.2.1 which actually build. And I would add the third party licensing files which are part of the EAP source. This would reduce the number of differences, it would make the source distribution legally compliant with the licenses of thirdparty and of course it would fix the broken build.

I would use this also to re-introduce proper maven profiles so the EAP source does not have to modify the POMs like it does currently.

(And I think it would be a political sign that you maintain community releases in some way).

I would prepare some pull requests if wou want to, to prepare this 7.2.1 (Licenses, buildfix) but I dont feel qualified to setup the right POM profiles.

Greetings

Bernd

[ctomc]

Bernd Eckenfels wrote:

This was bug in tagging process that we didn't notice soon enough, as it would only show if you have empty local maven repo (aka you never bould 7.2.0.alpha1-snapshot)...

you can build it by running mvn clean install -DskipTests

that will just skip testsuite which is where the problem occurs. you will still end up with working binary that would be the same.

It would be good to have a 7.2.1 which actually build. And I would add the third party licensing files which are part of the EAP source. This would reduce the number of differences, it would make the source distribution legally compliant with the licenses of thirdparty and of course it would fix the broken build.

I would use this also to re-introduce proper maven profiles so the EAP source does not have to modify the POMs like it does currently.

(And I think it would be a political sign that you maintain community releases in some way).

I would prepare some pull requests if wou want to, to prepare this 7.2.1 (Licenses, buildfix) but I dont feel qualified to setup the right POM profiles.

Greetings

Bernd

I think if you prepare PR for licences for current master (upcoming as8) that should be fine. But I cannot comment on 7.2.1 or anything similar as this is out of my hands... But I do agree that tag should build from clean repo.

I will ask guys from product team (the ones that do the changes for eap releases) to include build profiles to community upstream if possible, tbh i have not looked into what profiles they add...

--

tomaz

[b.eckenfels]

Tomaz Cerar wrote:

I think if you prepare PR for licences for current master (upcoming as8) that should be fine. But I cannot comment on 7.2.1 or anything similar as this is out of my hands... But I do agree that tag should build from clean repo.

I will ask guys from product team (the ones that do the changes for eap releases) to include build profiles to community upstream if possible, tbh i have not looked into what profiles they add...

The following change seems to be enough to build the Community Version, however there are some more SNAPSHOT dependencies (in the area of JSF) left in the source tree. I created a branch in my repository with the intention of producing a 7.2.1, but for now it has still 7.2.0.Final identifier (sorry for that).

https://github.com/ecki/jboss-as/compare/7.2.0.Final...ecki:7.2

There are some more -SNAPSHOT mentioned (in assembly plugin xml namespace and readme), I will prepare a pull request for AS 8 for that.

Does anybody know where I can find the documentation on how to bump the version numbers in an automated way? (And does that documentation include the missed places?)