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
The following packages were using classpathx-mail:
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
"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
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
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. My
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.
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Red Hat Inc. http://cz.redhat.com
If you're interested in JBoss Application Server I'm forwarding the
current status of the packaging effort.
-------- 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>
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
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
1. New subsystems.
Compared to 7.1.1-3, following new subsystems will be enabled:
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:
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:
In 7.1.1-4 we'll have the ExampleDS finally available!
If you want to help me pushing 7.1.1-4 out, please take some packages
- https://bugzilla.redhat.com/show_bug.cgi?id=830763 (free to review)
High priority is #830763, since it blocks everything else... If you have
questions or need help, please join #fedora-java IRC channel on freenode.
P.S. If you have time, please consider also commenting on this bug report:
jboss-rpm mailing list