[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?
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?
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.
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.
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.
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?
--
Regards,
Igor
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
