On 10/22/2008 10:26 PM, Igor Fedorenko wrote: > [EMAIL PROTECTED] wrote: >> Hi Igor, >> >> it works: I was able to satisfy the httpclient dependency with an >> artifact >> coming from the local repository, following the example from the >> integration >> test. >> >> However: Now I have to "declare" all of my *own* plugins in the >> dependencyManagement section in order to build a plugin X, >> install/deploy X >> into the local/group repository, so that I can have the dependency of >> another >> plugin Y onto X get resolved from the repository. >> >> Having to add dependencies into the dependencyManagement section would >> be OK >> for 3rd party plugins, as I want to have this single point of control >> over >> all >> versions, but for my internal plugins, this would not be practical. > > Somehow I managed to convince myself this would be acceptable/reasonable. > > First, this is more or less how dependencyManagement works for regular > maven projects, i.e. the same dependency is listed both in > <dependencyManagement/> and <dependencies/> sections. > > Second, from what I saw, most of the projects have one or very few > top-level features that include all bundles/features produced by the > build. It is enough to only include such top-level feature into > <dependencyManagement/> and this will implicitly add everything included > in the feature to the build target platform. > > And lastly, I assumed that target platform specification is going to be > useful by itself, especially because it is now possible to import > <dependencyManagement/> section from one pom to another using scope=import. > > Does this make any sense or you still think this problem absolutely has > to be addressed for target platform management to be useful?
Let me give you a little more context. I'm trying to introduce Tycho/Maven/m2eclipse to a team of Eclipse plugin developers who are currently using a "monolithic" PDE build and are managing the dependencies manually, i.e. they have to open all plugins as Eclipse projects to resolve all dependencies to get to a compilable set of projects. I want the ability to easily scale in terms of number of components and developers. I.e. having each developer to build the full set of components is exactly what I'm trying to avoid. A developer should only need to open her component from the SCM in Eclipse and all of that component's dependencies are getting resolved from the group repository which in turn gets populated by a CI-driven build and a nightly build which does a full build from scratch. Now, the important point is that I would like developers to be able to create new components without having to "register" them in a dependencyManagement section when another component wants to make of the new component. This is highly desirable for me, though not an absolute requirement. > >> >> Besides, having those dependencies in the dependencyManagement after I >> wipe out >> my local repository gives me errors, because Maven/Tycho tries to >> download >> them >> from the group repository, where they don't exist either. > > I am not sure I understand the problem. Where these dependencies are > supposed to come from if they are not available from anywhere? Or you > think the build should fail at a later stage, during OSGi dependency > resolution? I have two plugins X and Y which do not have any dependencies itself, but are used by other plugins. In order for the other plugins to find X and Y, I declare two dependencies in the dependencyManagent section of my parent POM (applicable to all of my plugins). 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 org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:132) | at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) | at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) | at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) | at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:600) | at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:479) | at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:357) | at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:167) | at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:82) | at org.codehaus.tycho.osgitools.targetplatform.EclipseTargetPlatformFactory.resolveArtifact(EclipseTargetPlatformFactory.java:132) | at org.codehaus.tycho.osgitools.targetplatform.EclipseTargetPlatformFactory.resolvePlugin(EclipseTargetPlatformFactory.java:127) | at org.codehaus.tycho.osgitools.targetplatform.EclipseTargetPlatformFactory.createTargetPlatform(EclipseTargetPlatformFactory.java:67) | at org.codehaus.tycho.maven.EclipseMaven.resolveOSGiState(EclipseMaven.java:52) | at org.codehaus.tycho.maven.EclipseMaven.getProjects(EclipseMaven.java:35) | at org.apache.maven.DefaultMaven.createReactorManager(DefaultMaven.java:98) | at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) | at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:899) | at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) | at org.apache.maven.cli.MavenCli.main(MavenCli.java:63) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:597) | at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) | at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) | at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) | at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) | Caused by: java.io.FileNotFoundException: http://repository.sonatype.org/content/groups/public/group/id/Y/1.0.0/Y-1.0.0.jar | at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1239) | at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:115) | ... 26 more This happens also when I try to build all of my plugins all together using a multi-module POM. > > >> >> 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. Thanks! -Max --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
