there are currently three main branches for Weld Core:
- 1.1 - the Weld 1.1 branch used in JBoss AS 7, JBoss EAP and other EE6
- master - Weld 1.2 - basically the 1.1 branch with weld-osgi on top
- 2.0 - Weld 2.0 (CDI 1.1 implementation)
This is confusing as git users usually expect to find the latest and
greatest in the master branch which is not the case for Weld. Therefore,
I am going to rename the master branch to a more appropriate name -
"1.2". If you do any work on the current master branch make sure to
apply your changes to "1.2" from now on.
A new master branch will be added eventually when we start working on
Weld 2.1. In the meantime there will be no branch named "master".
I'd like to get your thoughts on the possibility of removing JSF
dependencies from Weld Core and putting them in their own artifact. The
reason I want to do this is so that in WildFly we can more easily allow
Weld JSF classes to work with multiple JSF versions.
As it is now, Weld Core has a hard-coded dependency on the single JSF
version that ships with WildFly. So whether someone uses the Multi-JSF
feature or uses WAR_BUNDLES_JSF_IMPL, you can get Linkage errors when
trying to use Weld Core.
>From what I see, the JSF classes in Weld Core aren't really used by the
rest of Weld Core. Instead they are instantiated via the Weld
subsystem's inclusion of the ConversationAwareViewHandler in its
The only part of Weld Core that "sort of" uses a JSF dependency is
BeanDeployment. This instantiates an instance of JsfApiAbstraction and
registers it the Weld ServiceRegistry. JsfApiAbstraction is only there
to determine the JSF spec version. But I haven't been able to find
anywhere it is actually used in the wild.
Specifically, I would like to move the org.jboss.weld.jsf package into
its own jar artifact.
org.jboss.weld.servlet.ConversationPropagationFilter would go in there
too. Weld Core would then list the new artifact as a dependency so as
not to break backward compatibility.
If you think it's a good idea I'll be glad to do the work to make it
happen. Please let me know.
Brad Davis has created a great tool called Windup. Windup can create a migration report, which highlights items which will need changing, provides suggested changes, and estimates the effort involved. It uses rulesets to do this, and the set of rules is extensible e.g. https://github.com/windup/windup/blob/master/windup-rules/src/main/resour...
It would be great to start building a Seam 2 -> Java EE 6 migration ruleset.