>> 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' dependencies.
>> 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?