On 10/27/2008 8:11 AM, Igor Fedorenko wrote: > [EMAIL PROTECTED] wrote: >> On 10/22/2008 10:26 PM, Igor Fedorenko wrote: >>> [EMAIL PROTECTED] wrote: ... > I also understand that it is desirable not to explicitly register > inter-component dependencies in dependencyManagement, but unfortunately > I do not see how to implement this without dropping features that I > believe are important. I hope managing dependencyManagement section is > not going to be too difficult for real projects and teams, but I will > certainly revisit this if I am mistaken.
As I said earlier, having to use dependencyManagement for inter-component dependencies is OK for me, though somewhat inconvenient. ... >> Now, I wipe out my local repository and try to re-install X. Because of the >> dependency in the dependencyManagement section for Y, I get this error: >> >> | Downloading: http://repository.sonatype.org/content/groups/public/group/id/Y/1.0.0/Y-1.0.0.jar >> | org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate resource in repository >> | at > > [stack trace was here] > >> >> This happens also when I try to build all of my plugins all together using a >> multi-module POM. > > This should be fixed now... well, almost ;-) Tycho will still print a > warning about target platform resolution problems, but will not fail the > build, assuming all project dependencies can be satisfied. This change does work for me. Just tried it out. Thanks! >>>> 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? I have to admit that I'm not absolutely clear at this point in time, how I will be using these mechanisms. On one hand, I like to keep my target platform as minimal as possible and be able to have even 3rd party plugins in my Maven repository. For sure I want my inhouse plugins to reside in the Maven repository, while operating in MANIFEST-first mode at least in the beginning to confuse my developers as little as possible. On the other hand, I can imagine to later switch to a POM-first mode where I anticipate dependency resolution to be clearer. Anyhow. The way it works right now (i.e. the 20081027.200229 snapshot) is OK for me to start with. > > 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. I respond on this topic in a separate thread. Regards, -Max --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
