Re: [equinox-dev] dependency on org.osgi.annotation?

[Thomas Watson <tjwatson@xxxxxxxxxx>]

Regardless of anyone's intentions I don't think it is going to be productive to discuss which is the 'right' way to to develop bundles in this thread.  Not because I think PDE is right, rather, at this point it is not likely PDE is going to all of a sudden change coarse and do code first instead of manifest first.  So don't look towards me to guide PDE out of its current workflow.  It clearly works for a large number of developers and changing that workflow will not be useful to that set of developers.  If developers want or need some other workflow then bnd is clearly a great option.  I use both so I know they both can be useful tools.

In this thread, pretend for a moment that the PDE workflow actually works for a large number of developers.  How would we solve this problem?  Do we just ignore it and say it is foolish to use manifest first to configure the classpath?  The fact of the matter is that in bnd the annotation classes ARE on the classpath when compiling because they ARE included in the API jars typically used to compile against.  It is just that the manifests produced do NOT import the annotation packages because they are not runtime annotations.  If a solution is desired for PDE I think it must be one that does not advocate a bundle that uses Export-Package for the non-runtime annotation packages AND it must not advocate bundles putting runtime dependencies (Import-Package etc.) on such non-runtime annotation packages.

I don't mind having this discussion here, but to be honest it seems more appropriate to have the discussion in a PDE forum or bug report where a PDE committer or contributer is monitoring and may be able to do the PDE work necessary.  If such a bug is opened can you please post it here?

Tom

-----equinox-dev-bounces@xxxxxxxxxxx wrote: -----

To: equinox-dev@xxxxxxxxxxx
From: Stephan Herrmann
Sent by: equinox-dev-bounces@xxxxxxxxxxx
Date: 05/09/2015 03:59PM
Subject: Re: [equinox-dev] dependency on org.osgi.annotation?

On 05/09/2015 08:50 AM, Tom Schindl wrote:
> PDE can have compile time dependencies in its build.properties but naturally build.properties is not part of the final jar

I see. So o.e.osgi has this in its build.properties:

jars.extra.classpath = osgi/osgi.annotation.jar

Brainstorming:
- would it make sense to include build.properties at least in the source bundle?
- how can s.o. consuming org.eclipse.osgi.source_XY.jar use this to find "osgi/osgi.annotation.jar"?
- would it be (legally?) possible to include the files from the annotation jar in the source bundle?

On 05/09/2015 07:15 PM, Thomas Watson wrote:
> I think there likely would need to be some way for a jar to indicate the package is compile time only API, perhaps with a separate header in the manifest.

Sounds great.
If I understand correctly, o.e.osgi would, e.g., contain types
like org.osgi.annotation.versioning.ProviderType and mark
the package as "compile time only"?

BTW, how would this transfer to the case of null annotations?
I wouldn't suggest that all bundles using null annotations
at compile time should *include* these in their bundle.
In that case marking a *dependency* (full-blown with version range
and all that) as "compile time only" seems more natural, no?

I guess the difference is: o.e.jdt.annotation is available
as a bundle from p2 repositories, whereas osgi.annotation.jar
seems not, right?

Stephan
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev