>>>>> On Thu, 29 Oct 2009 12:09:03 -0400, Roger Kitain <Roger.Kitain_at_Sun.COM> said:
RK> However, it looks like weld will be using the following related artifacts:
RK>
http://repository.jboss.org/maven2//org/slf4j/slf4j-ext/1.5.9.RC1/
RK>
http://repository.jboss.org/maven2//org/slf4j/slf4j-api/1.5.9.RC1/
RK>
http://repository.jboss.org/maven2//org/slf4j/slf4j-jdk14/1.5.9.RC1/
RK>
http://repository.jboss.org/maven2//ch/qos/cal10n/cal10n-api/0.7.2/
Here is what I suggest we do.
Currently in the SVN repo at [1] we have directories for slf4j-api and
slf4j-jdk14. Within each of these directories is the "source build"
code for those modules. My build system for the bean-validator module,
also at [1], traverses into those slf4j directories, builds their jars,
and includes them in the final bean-validator.jar OSGi module. This was
done to reduce the number of jars we have in the modules directory.
Now that Weld also depends on slf4j, it makes sense to have a separate
top-level OSGi module for slf4j. Here is my proposal to make this
happen.
* make a new directory at [1]/slf4j.
* Move the existing slf4j-api and slf4j-jdk14 directories under there
* make a new directory [1]/slf4j/slf4j-ext
* Use an approach similar to what I do with bean-validator that bundles
slf4j-api, slf4j-jdk14 and slf4j-ext into a single glassfish OSGi
module slf4j.jar.
* Once this slf4j.jar module is working and published to the java.net
maven2 repo, we can make bean-validator and Weld depend on it.
ACTION: Jerome, Jane, Roger
please give you opinion on this plan. Is there a better way?
Thanks,
Ed
[1]
https://svn.dev.java.net/glassfish-svn/trunk/external/modules
--
| ed.burns_at_sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/