On 10/27/2008 8:11 AM, Igor Fedorenko wrote:
> [EMAIL PROTECTED] wrote:
>> On 10/22/2008 10:26 PM, Igor Fedorenko wrote:
...
>>>> So, if there's a way to automatically derive the Maven coordinate
>>>> from a
>>>> plugin
>>>> reference, that would solve the problem :-)
>>>>
>>> Very good question! I've been struggling with this problem for some time
>>> but could not come up with a good generic solution. In my opinion, usable
>>> solution would have to deal with at least this problems/usage scenarios.
>>>
>>> 1. There are many more ways to express dependencies in OSGi compared to
>>> maven, Import-Package, DynamicImport-Package, Import-Service and
>>> Eclipse-GenericRequire cannot be expressed in maven terms, afaict.
>>
>> When mapping the referenced plugin name onto artifactId, the plugin
version
>> onto the Maven version, the missing piece is the groupId. I'd enhance the
>> dependency element (in a dependencyManagement section) to allow for
>> wildcards, then one could say something like
>>
>> <dependency>
>> <groupId>org.myorg</groupId>
>> <artifactId>*</artifactId>
>> <version>*</version>
>> <type>eclipse-plugin</type>
>> </dependency>
>>
>> Which would say that each actual, matching dependency would use
"org.myorg"
>> as groupId.
>>
>> Maybe to not go into full regexps, one could use a slightly simpler
>> approach, allowing to omit certain elements from a dependency, having the
>> same semantics as above:
>>
>> <dependency>
>> <groupId>org.myorg</groupId>
>> <type>eclipse-plugin</type>
>> </dependency>
>>
>> I could image that such a generalization of the dependencyManagement
section
>> can be useful even outside of Tycho, whereever one wants to define
>> dependency details for many more concrete dependencies.
>>
>>> 2. Even for Require-Bundle, it is common to either not specify version
>>> at all or specify open version range which makes it impossible to map
>>> such dependencies to maven, or in fact resolve them without context of
>>> specific target platform.
>>
>> The suggested approach could also here be used to give the missing
>> information.
>>
>>> 3. I am not sure how common this is, but at least for m2e, we want to be
>>> able to build/test with several eclipse versions (i.e., e32, e33,
>>> e34...). Again, this can only be achieved when target platform is
>>> defined separately.
>>
>> Could this be achieved by having different POMs and the right one gets
>> selected through a property?
>>
>>> So I see only three possible solutions that address all three scenarios.
>>> One is to specify build target platform explicitly. Another one is to
>>> only support Require-Bundle with specific version. And the last one is
>>> to push target platform management from the build to some external
>>> entity, like repository manager (imagine if you could point your build
>>> to a virtual repository that only contains needed artifacts and nothing
>>> else, for example).
>>>
>>> Do you see any other options?
>>
>> I still think being able to map OSGi references onto Maven coordinates
would
>> be a powerful feature.
>>
>
> To make sure I understand your suggestions.
>
> Currently, there are two resolution phases during tycho build. First,
> tycho resolves build target platform using maven coordinates from maven
> artifact repositories (feature dependnecies are transitive, bundle
> dependencies are not transitive). The result of target platform
> resolution is then fed to (real) OSGi resolver, that deals with various
> Eclipse/OSGi dependencies, like Import-Package or Eclipse-GenericRequire.
>
> Do you think this is a reasonable approach?
>
> You suggestions appear to apply to target platform resolution phase only
> (specifically, Eclipse/OSGi metadata is not checked at all). Is this
> correct?
Not really. My suggestion would generalize the dependencyManagement section
more, making it more useful.
Currently the dependencyManagement section allows to define versions on
dependencies centrally such that a dependency in a child POM doesn't need to
specify a version string and inherits it instead from the parent POM.
Imagine this to work also for other child elements of <dependency> and not
just
for <version>. For instance
<dependencyManagement>
<dependency>
<groupId>org.myorg</groupId>
<type>eclipse-plugin</type>
<version>1.2</version>
</dependency>
</dependencyManagement>
...
<dependency>
<artifactId>my.jar</artifactId>
<type>eclipse-plugin</type>
</dependency>
The dependency would inherit the groupId and version, because the type
element
matches the dependency pattern.
I understand that such an enhancement might be a more long-term effort and
does
not fall into Tycho, although the suggestion would come handy when dealing
with
OSGi dependencies.
Regards,
-Max
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
