dev@glassfish.java.net

Re: slf4j as Glassfish OSGi module

From: Snjezana Sevo-Zenzerovic <Snjezana.Sevo-Zenzerovic_at_Sun.COM>
Date: Fri, 30 Oct 2009 11:24:55 -0700

FWIW, step 7 is rather trivial so I would appreciate if it can be done
at the same time as step 6. All that needs to be done is to also add
slf4-all dependency to the dependency section of
packager/glassfish-jcdi/pom.xml....

Thanks,

Snjezana

Jane Young wrote:
> Hi Sahoo,
>
> Thank you for responding. I see your point and agree that we move
> slf4j-all outside of sl4j/1.5.9.RC1.
>
> So the complete steps are as follow:
> 1. Mirror slf4j sources version 1.5.9.RC1 in our SCM
> (https://glassfish-svn.dev.java.net/svn/glassfish-svn/trunk/external/modules)
>
> 2. Use the same steps from JBoss' in building the artifacts producing
> the same maven coordinates
> 3. 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.
> 4. Publish these artifacts in the GlassFish Maven repository (let's
> publish this in http://download.java.net/maven/glassfish - Please let
> me know when you get to this step)
> 5. In v3/packager/external, create a submodule slf4-all referencing
> the dependencies of slf4j and bundling the artifacts in one jar. Note
> that slf4j-all will have the groupId of "org.glassfish" and with the
> version "3.0-b##".
> 6. In Roger's weld-integration, he will need to define the dependency
> on slf4-all. Note since this artifact is built in the same project
> so no need add in dependencyManagment. However, the slf4j artifacts
> built in step2 will need be defined since it is needed in building
> slf4j-all.
> 7. Snjezana will include slf4j-all in packager.
>
> Jane
>
>
>
> Sahoo wrote:
>> Jane,
>>
>> I agree with those steps except #3. Can we have this *slf4j-all*
>> module outside of slf4j/1.5.9.RC1. e.g.,
>> v3/glassfish/packager/external or something like that, so that
>> a) We don't have to create it every time we add new version of slf4j
>> in our scm.
>> b) We don't mix an artifact with groupId org.glassfish with that of
>> the external project.
>>
>> I also think org.glassfish.external is *not* an appropriate groupId.
>> org.glassfish is more appropriate. Any additional qualifier should be
>> part of artifactId; the group name should remain same for all
>> artifacts produced by this team.
>>
>> Thanks,
>> Sahoo
>>
>> Jane Young wrote:
>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>