Hi Ed,
I'm fine with this approach in creating one bundle containing all the
slf4j artifacts.
So, this is what's going to happen:
1. Mirror slf4j sources version 1.5.9.RC1 in our SCM [1]
2. Use the same steps from JBoss' in building the artifacts producing
the same maven coordinates in the local Maven repository
3. Create a pom.xml in [1]/slf4j/1.5.9.RC1/slf4j-all that references
the artifacts from step 2 to create one slf4j-all bundle. Name this
artifact slf4j-all with the version 1.5.9.RC1 and the groupId:
org.glassfish.external
4. We will publish the one slf4j bundle to our maven repository
5. Provide a README describing the build. This should include steps
like checking out a particular version from external repo, setting env
and then issuing some commands.
Jerome/Sahoo, let us know if you're okay with this approach.
Ed, so BV will have a dependency on slf4j artifact and downloaded to
v3 workspace from hk2? Does Snjezana need to add this artifact in the
packager module or will this be added via transitive dependency?
Thanks,
Jane
Ed Burns wrote:
>>>>>> 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
>
>
>