[henk53]

Justin Bertram wrote:

Keep in mind that JBoss EAP != JBoss AS.  As the name suggests, EAP (i.e. Enterprise Application Platform) is more than just JBoss AS.

Okay, you are right about that. Good point!

To clarify what I meant, there is something that can be downloaded at https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=12673&product=appplatform&version=6.0.0&downloadType=distributions

This will result in a downloaded file currently called jboss-eap-6.0.0.zip

The size of this file is tiny bit less than JBoss AS 7.1.1 as-in the archive jboss-as-7.1.1.Final.zip (114.9MB vs 133.3MB), but it's roughly the same. When I unzip the EAP archive, I get something that looks surprisingly close to what I see when I unzip the AS archive. When I start this EAP up, I get something that looks surprisingly similar to what I see when I start AS up. E.g. the last line:

[org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.0.0.GA (AS 7.1.2.Final-redhat-1) started in 1301ms - Started 134 of 214 services (79 services are passive or on-demand)

I can deploy an war, ear etc to this thing at exactly the same way as I do to the AS release.

So, by all accounts this looks and acts just like the "plain" application server that can be downloaded from http://www.jboss.org/jbossas/downloads. There is one tiny difference, and that's that this one is newer (AS 7.1.2.Final-redhat-1)

What I was thus asking, is whether this particular artifact can be put on the above mentioned download page? I think it would naturally fit in there right after 7.1.1 and before the hypothetical 7.2 beta 1 release. It's not as-if something would -really- change, as the jboss-eap-6.0.0.zip artifact can already be downloaded from the Red Hat portal.

I'm thus definitely not asking to put up potentially gigabytes of enterprise middleware on the jbossas/downloads page. That would indeed not make any sense. But I think this particular artifact would fit in quite nicely, wouldn't it?

[wdfink]

Hi Henk,

your right, EAP6.x and AS7.1.x are only a couple of bits different. But are managed in two different branches of the same codebase.

The EAP release is more restrict and you won't have this in the community because here all previews and instable features might be removed.

Also the EAP version will be feature freezed and after that approved, meanwhile the development continue for the community version.

As Justin mentioned before, there are merge points where bugfixes and features get merged.

So it is a decision that there are two different versions that get not mixed. Otherwise the professional support will be a mess.

From my experience the version is used for test that will be later the productive instance, developers might be use a different one.

Also it is easy to change if you use related community and EAP versions.

So for me it is clarity to have different downloads for community and EAP, you are free to decide what you use.

[badr]

So as a wrap up, can we get AS 7.1.2 alone ?

Thanks

[jbertram]

I believe that question was already answered.

[henk53]

badr elhouari wrote:

So as a wrap up, can we get AS 7.1.2 alone ?

Thanks

I think the answer is clearly a big "NO!", but the counter question maybe is: do 'we' really want an AS 7.1.2 when we can just download EAP 6 with those last amount of bug fixes that were done in that other repo?

The way I see it, we have:

JBoss AS 7.1.1.Final - Latest release on community download page. Contains a few serious bugs, but otherwise quite okay if you happen not to hit those.

JBoss AS 7.1.2.Final - Latest stable tag in community repository. Supposedly never meant as a release, but can be build from source relatively easily.

JBoss AS 7.1.2.Final-redhat-1 (JBoss EAP 6.0.0.GA) - Latest release on Red Hat download page. Branched from JBoss AS 7.1.2.Final.

To me it seems the simplest way to get the latest and greatest is to just download jboss-eap-6.0.0.zip from the Red Hat site, isn't it?

[jbertram]

To me it seems the simplest way to get the latest and greatest is to just download jboss-eap-6.0.0.zip from the Red Hat site, isn't it?

It's worth noting that the EAP download from the Red Hat Customer Portal is reserved for Red Hat customers who either have an active subscription or wish to evaluate EAP with an eye to eventually purchasing a subscription.

[jason.greene]

You can download EAP 6 GA instantly by registering for a subscription evaluation here:

https://www.redhat.com/wapps/sso/login.html?redirect=%2Fwapps%2Feval%2Findex.html%3Fevaluation_id%3D1002

It's located via the download link on the redhat product downloads.

You can also download EAP GA source either on the CSP account above or on ftp.redhat.com without an account. It's still open source so you can build it for yourself if you like, but you need to remove all of our trademarks if you want to distribute it (make your bits available to others for download)

Another thing worth mentioning is that JBoss Developer Studio subscriptions, which are only 99 USD a year include access to the EAP6 binaries (for development purposes).

[htfv]

Sure, we can download EAP 6 for evaluation, but we cannot install it on production servers. We are thinking to buy EAP, but only for customers, who are willing to pay more, others get AS as usually. Now we have a problem, because EAP has no corresponding AS version. 7.1.3.Final we also be EAP only, and we will probably have to switch to AS 7.2.x version of AS. This makes quite some trouble, because we have to support different versions of servers.

[henk53]

Aliaksei Lahachou wrote:

Sure, we can download EAP 6 for evaluation, but we cannot install it on production servers.

I'm a little rusty in my legalize, but I guess that the evaluation license explicitely forbids that, or doesn't it? What about your own production servers (i.e. not shipping to a customer)?

Can't the EAP binary you download using the evaluation subscription be used on production servers?

[henk53]

Justin Bertram wrote:

To me it seems the simplest way to get the latest and greatest is to just download jboss-eap-6.0.0.zip from the Red Hat site, isn't it?

It's worth noting that the EAP download from the Red Hat Customer Portal is reserved for Red Hat customers who either have an active subscription or wish to evaluate EAP with an eye to eventually purchasing a subscription.

Sure, that's the idea. But then again, the entire line of AS releases is of course also intended to make developers aware of JBoss AS with the idea that a percentage of them will eventually buy the support contract. So the difference doesn't seem to be that big.

[jbertram]

It's certainly assumed that a percentage of users who currently leverage the community version will migrate to EAP at some point.  However, whereas the community version is essentially open to any use not prohibited by the open-source license, the EAP version is also governed by the terms of the contract which requires proper entitlements for particular uses (e.g. "production").

[jbertram]

Now we have a problem, because EAP has no corresponding AS version.

To be clear, this is the way things have worked since Red Hat first introduced EAP in July 2007 (nearly 5 years ago).  This isn't new with EAP 6.

[henk53]

Justin Bertram wrote:

It's certainly assumed that a percentage of users who currently leverage the community version will migrate to EAP at some point.  However, whereas the community version is essentially open to any use not prohibited by the open-source license, the EAP version is also governed by the terms of the contract which requires proper entitlements for particular uses (e.g. "production").

I see, but if you build EAP from source and end up with exactly the same bits, then it is allowed to be used in production? And if you build from source and strip out the trademarks, then you are even allowed to distribute the resulting binary, aren't you?

To be clear, this is the way things have worked since Red Hat first introduced EAP in July 2007 (nearly 5 years ago).  This isn't new with EAP 6.

I know, but the discussion naturally comes up again with every EAP release I guess. To me after all those years it still doesn't really seem to make any sense. Either you're selling a support contract, or you are selling the binary bits (with or without a support contract). In the case of JBoss, and even EAP, the code is already fully open source (LGPL) and no restrictions on the use can be applied, right?

So what's exactly the use of shielding the binary bits that make up the AS component of EAP (the jboss-eap-6.0.0.zip that was identified above) behind a field of use restriction, while anyone can just build the thing from source and end up with exactly the same bits? Is it even technically possible to proof without any reasonable doubt that a given binary was build by Red Hat and not by an individual?

[jbertram]

I see, but if you build EAP from source and end up with exactly the same bits, then it is allowed to be used in production?

As I indicated before, EAP != AS.  Conceptually speaking, there is no community build for EAP.  You can build the source for the version of JBoss AS that is in EAP as well as the other components (if any) which are bundled with EAP, but you cannot build EAP itself as such.  Right now EAP 6 does not include any additional components so it looks strikingly similar to AS 7.1.x.  This, of course, can (and probably will) change over time as the code-base matures and additional projects evolve in the ecosystem.  To be clear, the latest version of JBoss EAP 5 adds Seam, Picketlink, RESTeasy, and mod_cluster.

And if you build from source and strip out the trademarks, then you are even allowed to distribute the resulting binary, aren't you?

IANAL, but I believe so.  As I understand it, CentOS does that with RHEL.

To me after all those years it still doesn't really seem to make any sense.

It doesn't make sense that the community moves quickly - fixing bugs, incorporating new features, and pushing new releases often - and that the enterprise version has a more deliberate and predictable pace - pulling back fixes from the community, fixing bugs which customers report, implementing features which customers request, incorporating community features as appropriate, and pushing updates at regular intervals?  It doesn't make sense that Red Hat carefully controls the related source code so that it can support it appropriately and certify it with a number of different operating systems, JVMs, databases, etc., and that producing EAP is fundamentally not a community process?

Either you're selling a support contract, or you are selling the binary bits (with or without a support contract).

That's a false dichotomy. 

When we discused this earlier on this thread I said, "Bits are valuable as well, but as it relates to EAP that's not mainly what Red Hat sells" (emphasis mine).  I didn't say that Red Hat only sells support for EAP, but that support is mainly what Red Hat sells for EAP.  As we discussed previously, EAP != AS.  There is a value add with EAP bits which includes component bundling, configuration tweaks, etc. which are not part of the community release process.  This video does a fair job of explaining the difference.  It summarizes a lot of the ground we've already covered here.

So what's exactly the use of shielding the binary bits that make up the AS component of EAP (the jboss-eap-6.0.0.zip that was identified above) behind a field of use restriction, while anyone can just build the thing from source and end up with exactly the same bits?

Simply put, EAP is not the result of a community process.  The community has no say in what ultimately goes into or what is left out of EAP (including within the underlying application server).  EAP is all about what Red Hat's enterprise customers want/need and what Red Hat can test, certify, and support.  EAP therefore services that audience.

Is it even technically possible to proof without any reasonable doubt that a given binary was build by Red Hat and not by an individual?

The hashes (i.e. MD5 and SHA-256) provided on the Red Hat Customer Portal for each download should suffice for that.

[henk53]

Justin Bertram wrote:

To me after all those years it still doesn't really seem to make any sense.

It doesn't make sense that the community moves quickly - fixing bugs, incorporating new features, and pushing new releases often - and that the enterprise version has a more deliberate and predictable pace - pulling back fixes from the community, fixing bugs which customers report, implementing features which customers request, incorporating community features as appropriate, and pushing updates at regular intervals?  It doesn't make sense that Red Hat carefully controls the related source code so that it can support it appropriately and certify it with a number of different operating systems, JVMs, databases, etc., and that producing EAP is fundamentally not a community process?

That wasn't exactly what I meant with "doesn't seem to make any sense". Of course the process you outlined is a perfectly sensible approach and offers the best of both worlds to different communities: a fast moving release schedule for those willing (or needing) to experiment with the latest and greatest, and a more conservative schedule for those who are in need of stability and support.

What I was referring to is the concept that JBoss AS is fully opensource, yet the JBoss AS that's part of JBoss EAP seems to have a field of use restriction. Why bother with this?

I agree with all your statements, about Red Hat carefully controlling the source code and no community influence for EAP, but why guard the resulting binary with said field of use restriction? Why not put the bits on the community download page, clearly state that it's completely unsupported (the current download page already does that), and let the community do with it as they please? Isn't that the spirit of true opensource?

The hashes (i.e. MD5 and SHA-256) provided on the Red Hat Customer Portal for each download should suffice for that.

If I build from the exact same tag, make no modifications whatsoever and use the exact same tools in the exact same version Red Hat used, would the hash really be any different?