[
https://issues.apache.org/jira/browse/OPENJPA-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711390#action_12711390
]
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' 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.
+1
>> 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.
>+1
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: https://issues.apache.org/jira/browse/OPENJPA-1062
> 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, OPENJPA-1062.patch
>
>
> Use the maven-bundle-plugin to generate the OSGi bundle metadata in the
> manifest.mf.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
