openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick (JIRA)" <>
Subject [jira] Commented: (OPENJPA-1062) Include OSGi bundle metadata
Date Wed, 20 May 2009 22:08:45 GMT


Michael Dick commented on OPENJPA-1062:

>> By marking <scope>compile</scope>, then those dependencies are only used
at compile time and are not included as maven >>transitive dependencies, which helps
maven-bundle-plugin create more accurate bundle metadata.

>My understanding is different. I understand that if you have a compile-time dependency,
then it's a permanent dependency that carries >through test, integration, and runtime.
But I'm not a maven expert.

That's my understanding as well. 

Compile is the heaviest dependency type and will carry through all phases. 

Provided is similar to compile but the jar won't included in any artifacts downstream. It
will be passed along as a transitive 'provided' dependency though. This scope used for things
that you compile against but don't want to redistribute (ie something that is part of the
JDK, or the WebSphere UOW API - which is only used with WebSphere). 

I'm not a OSGi bundling expert, but I'd expect the maven-bundle-plugin to ignore 'provided'

>> openjpa-lib - Log4J is optional, as there are LogFactoryAdapter impls for Log4J,
Commons-logging and No logging.

> So if you have a requirement that might be needed at runtime (e.g. log4j) and you can
compile without it, it should be marked as >provided.

If we don't need a component at compile time but is required at runtime then the scope should
be runtime. If it's optional at runtime then it should be test (if tests need it) or not included
at all. I think log4j fits the latter category, I'd have to check though. 

>> Ant is only needed when calling the enhancer or reverse mapping tool from Ant.

>So ant should be a test dependency or a provided dependency.


>> openjpa-jdbc - Postgresql and Hsqldb are only compile time depends for the PostgresqlDictionary
and HSQLDictionary classes

>This is interesting. These are open source libraries so there's no harm in including them.
It just struck me as odd that we would have a >hard dependency on these database-specific
libraries, but upon reflection, I think you're right to include them as compile dependencies.

I think these are really 'provided' dependencies we *should* only instantiate the dictionaries
if we're going to connect to PostgreSQL or HSQL and I'd rather not redistribute them. 

>> I still want a couple more eyes to look at this (like maybe Mike) and I want to run
some more tests before committing.


The patch you committed looks good, but the scoping looks mostly correct as is (exception
for log4j). 

What sort of tests are you running to verify the resultant bundle (forgive me if this is in
another JIRA - haven't checked as close as I should)? Are there any problems that occur with
'provided' dependencies, but don't with 'compile' ones? 

> Include OSGi bundle metadata
> ----------------------------
>                 Key: OPENJPA-1062
>                 URL:
>             Project: OpenJPA
>          Issue Type: Sub-task
>          Components: build / infrastructure
>    Affects Versions: 1.2.1, 1.3.0, 2.0.0
>            Reporter: Donald Woods
>            Assignee: Donald Woods
>             Fix For: 2.0.0
>         Attachments: OPENJPA-1062-bundle_only.patch, OPENJPA-1062-bundle_only.patch,
> Use the maven-bundle-plugin to generate the OSGi bundle metadata in the

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message