Hi Stuart,

your change to allow transient dependencies works like a charm for me,
and library definitions are added to deploy-pom.xml. You beat me to it
:-) ,my patch at http://issues.ops4j.org/browse/PAXCONSTRUCT-123 can
be safely ignored.

Thanks a lot,
Leen

On Wed, Sep 16, 2009 at 10:04 AM, Stuart McCulloch <[email protected]> wrote:
> 2009/9/16 Leen Toelen <[email protected]>
>>
>> Hi Stuart,
>>
>> I am looking into the library definition support for pax construct. In
>> PomUtils, i have added
>>
>>    /**
>>     *
>>     * @param artifact Maven artifact
>>     * @param resolver artifact resolver
>>     * @param remoteRepos sequence of remote repositories
>>     * @param localRepo local Maven repository
>>     * @param testMetadata check jar manifest for OSGi attributes if true
>>     * @return true if this is a library definition artifact, otherwise
>> false
>>     */
>>    public static boolean isLibraryDefinitionArtifact( Artifact
>> artifact, ArtifactResolver resolver, List remoteRepos,
>>            ArtifactRepository localRepo, boolean testMetadata )
>>    {
>>        if( null == artifact )
>>        {
>>            return false;
>>        }
>>
>>        String type = artifact.getType();
>>        if( null != type && type.indexOf( "libd" ) >= 0 )
>>        {
>>            return true;
>>        }
>>        else
>>        {
>>            return false;
>>        }
>>    }
>>
>> And in ProvisionMojo
>>
>>    /**
>>     * @param bundle potential bundle artifact
>>     */
>>    private void provisionBundle( Artifact bundle )
>>    {
>>        if( "pom".equals( bundle.getType() ) )
>>        {
>>            return;
>>        }
>>
>>        // force download here, as next check tries to avoid
>> downloading where possible
>>        if( !PomUtils.downloadFile( bundle, m_resolver, m_remoteRepos,
>> m_localRepo ) )
>>        {
>>            getLog().warn( "Skipping missing artifact " + bundle );
>>            return;
>>        }
>>
>>        if( PomUtils.isBundleArtifact( bundle, m_resolver,
>> m_remoteRepos, m_localRepo, true ) )
>>        {
>>            String version = PomUtils.getMetaVersion( bundle );
>>            String id = bundle.getGroupId() + ':' +
>> bundle.getArtifactId() + ':' + version + ':' + bundle.getType();
>>            if( !m_bundleIds.contains( id ) )
>>            {
>>                m_bundleIds.add( id );
>>            }
>>        }
>>        else if( PomUtils.isLibraryDefinitionArtifact( bundle,
>> m_resolver, m_remoteRepos, m_localRepo, true ) )
>>        {
>>            String version = PomUtils.getMetaVersion( bundle );
>>            String id = bundle.getGroupId() + ':' +
>> bundle.getArtifactId() + ':' + version + ':' + bundle.getType();
>>            if( !m_bundleIds.contains( id ) )
>>            {
>>                m_bundleIds.add( id );
>>            }
>>        }
>>        else
>>        {
>>            getLog().warn( "Skipping non-bundle artifact " + bundle );
>>        }
>>    }
>>
>> Is this the correct way forward? Are there any unit tests I can use to
>> test the behaviour?
>
> Hi Leen,
>
> while this works, it's not ideal because it is just adding special case
> code to the generic support for Maven POMs - the correct solution is
> to ask Maven for the transitive dependencies in the ProvisionMojo.
>
> the transitive dependencies of the libd artifact include the bundles,
> so you'd get support for this (and any other similar artifact) without
> adding any special case code.
>
> currently we just process the direct dependencies for each project,
> because this was a bit more controllable (you don't end up pulling
> in half the internet!) but it looks like we do need to scan the entire
> transitive tree for potential bundles.
>
> I've committed an initial change in r16201 - will probably also add
> a filter so people can remove any unwanted bundles from the final
> list (but need to get the OSGi in Action book out of the way first)
>
> give the current trunk a try and see if it works for your scenario
>
>> Regards,
>> Leen
>
> --
> Cheers, Stuart
>

_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general

Reply via email to