Fwd: [fedora-java] Chosing implementations for EE APIs and finalizing guidelines
by Dan Allen
I want to give all the "BOM heads" an FYI that the Fedora Java SIG is
currently selecting artifacts to use to create the RPMs that correspond
to the "official implementation" of each Java EE API [1]. Much like the
JBoss specs, these RPM packages will become the official "headers" for
any Java packages that rely on Java EE APIs. Here's an example:
https://apps.fedoraproject.org/packages/cdi-api
The JBoss community, several members in particular (Shelly, Pete, Karel,
etc), have put in a lot of effort to groom and curate a set of Java EE
API JARs. I'd hate to see that effort passed up in Fedora. Take note of
the criteria that Stanislav mentions below to determine which artifact
to use to create the API package for each spec (# of dependencies is a
primary concern). If you'd like to participate in this decision, feel
free to submit feedback in the #fedora-java IRC channel or the
fedora-devel(a)lists.fedoraproject.org list (or contact your local
representative, i.e., Marek or Carlo, hehehe).
If you need some motivation as to why you want to get involved, here's a
preview of some of the artifacts that have been selected. Note that few
are from the JBoss specs:
* ...
* javax.el - tomcat-el-2.2-api
* javax.enterprise.inject - cdi-api
* javax.inject - atinject
* ..
* javax.persistence - geronimo-jpa
* javax.security.auth.message - geronimo-jaspic-spec
* javax.servlet - tomcat-servlet-3.0-api
* javax.servlet.jsp - glassfish-jsp/glassfish-jsp-api
* javax.servlet.jsp.jstl - jakarta-taglibs-standard
Now is the time to have this conversation. It's a "speak now or hold
your peace" sort of thing.
-Dan
[1]
https://admin.fedoraproject.org/mailman/private/java-devel/2012-June/0044...
-------- Original Message --------
Subject: [fedora-java] Chosing implementations for EE APIs and
finalizing guidelines
Date: Thu, 28 Jun 2012 15:16:57 +0200
From: Stanislav Ochotnicky <sochotnicky(a)redhat.com>
To: Fedora Java Development <java-devel(a)lists.fedoraproject.org>
With new additions to packaging guidelines for EE APIs, we have to pick
1 implementation for each API.
I have made initial proposal for these APIs into the draft[1]. My
criterias:
1. if JDK provides it, we are done. Packages should remove this
dependency from pom.xml files
2. Prefer packages with smaller and simpler BR/R chains. Good example
being javax.servlet.jsp where I preferred glassfish-jsp over tomcat
or other implementations.
3. Exception for 2nd point: if the project is proven to be difficult in
the past, override. Example being geronimo projects which were
overriden few times.
Even when we finalize this list, I don't expect it to be set in stone. I
want it in the guidelines, but if situation arises where quick change is
needed we can still do it. Longer-term, I'd like to package more simple
independent implementations such as glassfish-jsp so we don't have
dependency for example on tomcat in very basic dependency chain.
Now, I'd like to give everyone time to look at my picks and poke holes
in them. If you don't like them...speak up. If you don't, you will not
have my sympathies later. So I'll wait a week for comments. I plan to
finalize new guidelines by the end of next week. Then call SIG meeting
(finally) and vote on it before presenting it to the FPC.
[1] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#EE...
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
13 years, 6 months
Rebuilt roadmap
by Pete Muir
All,
As your probably aware, one of our goals with jdf is to help people understand both the JBoss upstream projects (such as JBoss AS) and the Red Hat products (such as JBoss Enterprise Application Platform), as they are extremely similar :-)
With this in mind, we've got a fairly strict rule, that we can't add something to the jdf roadmap, unless it's also available in a product "soon after" the jdf release (i.e. we can develop stuff in parallel in jdf, but we shouldn't leap ahead).
As we risk heading into a timing nightmare with this, I feel it is simplest that we align the jdf release timeline to the Red Hat product which we most closely track (in terms of underlying features). This is, obviously, is WFK, where Errai and RichFaces are packaged, and DeltaSpike probably will be.
With this in mind, here is the new proposal for the roadmap:
http://www.jboss.org/jdf/stage/about/roadmap/
Note that this covers headline features, and there may well be other stuff that makes it in as well, if there is time.
We'll also aim to do some milestone releases:
10th August: M1
17th August: M2
24th August: M3
31st August: M4
7th Sept: M5
14th Sept: M6
with a release candidate on 21st Sept.
Marius is working on the Ticket Monster use cases for this release, and should have those ready today or early next week.
Please review the above info and let me know what you think,
Pete
13 years, 6 months
Re: [jdf-dev] Revised versions
by Pete Muir
Jim has done some very nice work improving our Fork Me ribbons - they are now much smaller, and have a nice hover effect to show people they are clickable.
Please review at http://www.jboss.org/jdf/stage/
I'll push live in 24h.
Pete
On 18 Jun 2012, at 19:36, James Parenti wrote:
> Hi again Pete,
>
> Okay, here are a set of graphics, along with a sample HTML file, just in case. It occurred to me that the ribbon link, being half-transparent but square-shaped, might be confused for the regular general image link due to the overlap, so I made a rollover version along with a basic image map version. The CSS is included in the test.html file. Also, I swapped the blue ribbon in one image for the green in another. I'll be available today to make additional changes as needed.
>
> Jim
>
>
>
>
> ----------------------------------
> James Parenti
> Visuale
> 1800 W. Cornelia Avenue
> Chicago, IL 60657
> P: 773.230.6544
> C: 773.469.8843
> http://www.visuale.net
> james(a)visuale.net
>
13 years, 6 months
Migration: when and what
by Pete Muir
One thing I picked up at Summit was that whilst people really appreciate the migration guides, they also want more advice on when (/whether) they should migrate, and what they should migrate too. We have the story pretty much sorted:
* if you have an app that works, and you want to keep running it on Seam 2.2, then great. We'll support that for X more years on EAP. Stay where you are.
* if you want to stay on Seam 2, but want to take advantage of the new features of Java EE 6, then you can take a look at Seam 2.3, which is currently beta quality. We haven't decided yet whether this will enter the supported product arena.
* if you want to take advantage of Java EE, you need to do a bit of analysis of your app:
** if you have all the features you need in Java EE 6 (and look at TicketMonster, you can achieve a lot!) then migrate to Java EE 6
** if you don't, but you can find them in DeltaSpike, and like living on the edge, then you can take the path of adding DeltaSpike to Java EE 6. But we don't have a well trodden path here, with guides for you to follow
** otherwise, take a look at the jdf roadmap to see when the features you need will enter jdf, will all the goodness of the stack and guides
Comments? I'll get this written up for http://www.jboss.org/jdf/migrations/get-started/ next week.
13 years, 6 months
