java-devel July 2012

java-devel@lists.fedoraproject.org

8 participants
4 discussions

classpathx-mail has been deprecated
by Mikolaj Izdebski 02 Aug '12

02 Aug '12

Hi all, classpathx-mail has recently been deprecated. Please build your packages against javamail package, which should be compatible with classpathx-mail. classpathx-mail used to have javamail virtual provide, so unless your packages referenced classpathx-mail directly there should be no need to change them (but in this case release tag bump and rebuild may still be needed). The following packages were using classpathx-mail: * ant, * apache-commons-email, * apache-commons-vfs, * axis, * axis2, * bouncycastle-mail, * cxf, * dumbster, * ironjacamar, * jboss-as, * jtnef, * maven-doxia, * mx4j, * ooo2gd, * ovirt-engine, * quartz, * resteasy. Thanks, Mikolaj Izdebski

2 2

Can we go to Groovy 2.0?
by Dan Allen 05 Jul '12

05 Jul '12

Can we shoot for Groovy 2.0 in Fedora 18? What about Fedora 17 updates? Groovy 2.0 is a crucial evolution in this widely used language and, being all about features first, we want Fedora to be the place to run it. The 2.0 update is significant because it introduces a static typing mode, allowing it to cater to both the dynamic language crowd as well as the traditional Java crowd. Of course, the big question for Fedora is backwards compatibility. Groovy 2.0 claims to be backwards compatible with 1.8. Hamlet D'Arcy had this to say on the topic in an abstract for an article on Groovy 2.0 in NFJS, The Magazine [1]: "Don’t worry, the major release is backwards compatible with previous Groovies. The 2.0 increment is earned because of the size and scope of its biggest features: modularization, invoke dynamic support, and most importantly an upgrade to the static type system. Groovy 2.0 will contain a static type checker which validates your code as part of the compiler, similar to what you’re familiar with from Java. The final class files and bytecode produced is still the same as before, but with this feature you have the safety you expect from Java with the conciseness and expressiveness of Groovy." Here's a detailed article published on InfoQ about what's new in Groovy 2.0. [2] -Dan [1] http://www.nofluffjuststuff.com/home/magazine_subscribe?id=31 [2] http://www.infoq.com/articles/new-groovy-20 -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction

7 15

Chosing implementations for EE APIs and finalizing guidelines
by Stanislav Ochotnicky 05 Jul '12

05 Jul '12

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_A… -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

4 3

JBoss AS 7 packaging effort update
by Marek Goldmann 04 Jul '12

04 Jul '12

Hi all, If you're interested in JBoss Application Server I'm forwarding the current status of the packaging effort. --Marek -------- Original Message -------- Subject: [jboss-rpm] jboss-as is alive and on the road to next update Date: Wed, 27 Jun 2012 10:23:01 +0200 From: Marek Goldmann <mgoldman(a)redhat.com> To: jboss-rpm(a)lists.jboss.org <jboss-rpm(a)lists.jboss.org> Hi, You may be wondering what's happening in the jboss-as package world :) I know I haven't updated you since some time, but finally there is a bunch of news! I'm working on jboss-as-7.1.1-4. This will be a pretty big update, a lot of new subsystems will be enabled and the way I work on the spec will be changed. 1. New subsystems. Compared to 7.1.1-3, following new subsystems will be enabled: - org.jboss.as.arquillian - org.jboss.as.osgi - org.jboss.as.configadmin - org.jboss.as.spec-api As you can see, 7.1.1-4 is focusing on OSGi stuff. This involved packaging a lot of new JBoss OSGi dependencies (12 packages). As usual, you can watch the table for latest packaging info: https://fedoraproject.org/wiki/JBossAS7#Current_progress 2. New way of working with AS7 patches With 7.1.1-3 we reached more than 80 patches to the AS7 codebase to compile it and make it run on Fedora. The amount of patches was pretty close to what RHEL5 had :) It wasn't fun to manage it. So far I moved new subsystems to minimalistic profile and afterwards I build it. Over the time, when I added more and more subsystems - the patch set was growing. Since we have only a few modules not available in Fedora, starting from now - I'm building default profile and commenting out modules which are still not available. This simple step will save me a lot of work and make the development more stable. I think 7.1.1-4 is going to have about 25 patches. Once we'll have all AS7 deps available, the goal is to rebase one more time and leave only patches that are necessary and remove everything else. This will decrease the patch amount one more time. 3. New linked modules The new way of building mentioned in #3 showed me that I forgot to link some modules. This will be fixed and about 35 additional modules (/usr/share/jboss-as/modules/...) will be added. 4. ExampleDS available There was one issue hanging since some time in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=812522 In 7.1.1-4 we'll have the ExampleDS finally available! That's all! If you want to help me pushing 7.1.1-4 out, please take some packages for review: - https://bugzilla.redhat.com/show_bug.cgi?id=830763 (free to review) - https://bugzilla.redhat.com/show_bug.cgi?id=832446 - https://bugzilla.redhat.com/show_bug.cgi?id=832443 High priority is #830763, since it blocks everything else... If you have questions or need help, please join #fedora-java IRC channel on freenode. Thanks! P.S. If you have time, please consider also commenting on this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=827584 --Marek _______________________________________________ jboss-rpm mailing list jboss-rpm(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-rpm

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel July 2012