[EMAIL PROTECTED] wrote:
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.
Yes, I understand your scenario and this is exactly the reason we're
adding target platform management logic to Tycho.
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.
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
[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.
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?
--
Regards,
Igor
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
