Repo1 CDI API pom
by Aslak Knutsen
I just noticed that the cdi-api 1.0 pom on repo1 has dependencies/references
to non standard projects:
..
<parent>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-api-parent</artifactId>
<version>1.0</version>
<relativePath>../parent/pom.xml</relativePath>
</parent>
..
<dependency>
<groupId>org.jboss.ejb3</groupId>
<artifactId>jboss-ejb3-api</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.jboss.interceptor</groupId>
<artifactId>jboss-interceptor-api</artifactId>
</dependency>
..
Is this correct ?
-aslak-
16 years
Reorg of SVN
by Pete Muir
All,
I am working through Weld SVN right now, and will then move onto Seam SVN, reorganizing SVN to better fit the module structure we have been discussing here recently. I'll post some links to wiki pages describing the structure once I am done.
Pete
16 years
Next steps
by Gavin King
So, folks, I want us to get a plan together for the first raft of CDI
extensions. I think there's three kinds of "things" we will be working
on:
* Unportable extensions (UEs), that integrate with proprietary SPIs in Weld
* Portable extensions (PEs) with the Weld brand
* Portable extensions (PEs) with the Seam brand
I imagine that we will distribute UEs along with Weld and cover them
in the Weld documentation. Hopefully there will not be too many of
these.
Weld PEs are going to be things that:
* are general purpose,
* are simple, and
* don't pull in extra dependencies.
Things which don't fit this description get the Seam brand.
We already have:
(1) weld-se
(2) weld-servlet and weld-tomcat
(3) weld-wicket
These are all UEs, I suppose. Or are some of them PEs?
So here's the things that I would like to see us release soon:
(1) A weld-ext module with:
* logger injection,
* @Exact,
* @Introduces,
* abstract producer methods,
* beans declared at constructor level, and
* @Named packages.
These are all very easy to implement except @Introduces, which
requires a little javassist magic.
(I would just package weld-logger in here, I don't see why it needs to
be in its own module.)
(2) A seam2-int module with:
* use of @Inject to inject of Seam2 beans into CDI beans (i.e. Weld
delegates bean instantiation to Seam when there is a @Name)
* (hopefully) support for @Inject in Seam2 beans, if this is not
too hard to implement
I have already done a rough impl of the first part.
(3) A spring-int module.
(4) a seam-transactions module with:
* support for declarative JPA EntityTransaction management
* support for injection of the EntityTransaction
* (hopefully) support for the same things with a UserTransaction
provided by JBoss Transactions
* support for the same things with a Hibernate Transaction
I have already done a rough impl of the first part.
(5) a seam-persistence module with:
* support for injection of JPA EntityManagers with various scopes
* (hopefully) support for injection of Hibernate Sessions with various scopes
I have already done a rough impl of the first part.
(6) a seam-web module with:
* injection of FacesContext
* injection of servlet contexts
These are both easy.
(7) a seam-jms module with:
* injection of all the various JMS objects for a resource of type
Topic or Queue
Is there anything I'm missing?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
