On 01/02/2008, Alin Dreghiciu <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Shouldn't org.osgi.service.obr be a bundle not a plain jar? I know
> that is included into org.apache.felix.bundlerepository bundle but why
> it should not be a stand alone bundle?
The main reason this is not a bundle is because it was introduced to break
a cyclic dependency in the build, where the maven-bundle-plugin indirectly
used classes provided by bundlerepository - which had packaging "bundle"
and therefore needed the maven-bundle-plugin to build ...etc...
So the OSGi OBR service classes were refactored into a plain jar, just like
the vanilla "org.osgi:org.osgi.core" jar already in central, which also
isn't a
bundle - it's really a compilation artifact as the frameworks provide the
API
at runtime (either via the system bundle or other bundles).
Once the 1.0.1 org.osgi.service.obr (with the explicit groupId) is released
we could look at turning it into a bundle, because we can then rely on the
released set of artifacts to effectively 'bootstrap' the build...
but there's a danger we could run into cyclic dependency problems in the
future if we need to upgrade the bundleplugin and org.osgi.service.obr at
the same time, so it might be simpler to leave it as a plain jar.
So my gut feeling is to leave it alone for now, as bundlerepository provides
this API in bundle form - though if there was a compelling reason to have it
as a bundle I wouldn't be against it (but not everything has to be a
bundle!)
Something related (maybe) is that org.apache.felix.bundlerepository:
> 1. exports org.osgi.service.obr package without a version. shouldn't be
> 1.0.0?
Possibly - the OBR service API is still being drafted so I'm not sure
whether
we should give this package space a definite version yet (we have to version
the maven artifact, which is why we used 1.0.0 - compare this with the core
Felix bundle where the artifact version is different to the package
versions)
2. the maven pom has dependencies on a couple of artifacts that are
> inlined in bundlerepository bundle. Shouldn't this marked as
> <optional> so when I will have a dependency on it those inlined
> dependencies will not be pulled in as the necessary packages are
> already present?
You mean update the bundlerepository pom to mark these as optional?
That would make things a bit better - can you log this as a task on JIRA?
Alin
>
> On Feb 1, 2008 5:58 PM, Stuart McCulloch <[EMAIL PROTECTED]>
> wrote:
> > Hi folks,
> >
> > I've compiled a minor fix to the "org.osgi.service.obr" sub-project.
> >
> > This fixes a problem I discovered recently where the ${pom.groupId}
> > field in the dependency list was being interpreted wrongly by Maven
> > when using the OBR plugin with a parameter of -DgroupId=example
> >
> > To see this in action, try the following command:
> >
> > mvn
> org.apache.felix:maven-obr-plugin:1.0.0:install-file-DgroupId=example
> >
> > and you'll see it complain about "example:org.osgi.core:jar:1.0.0"
> > ( Maven uses the -DgroupId value instead of the pom's groupId! )
> >
> > While this is obviously a bug in Maven, we have to support users on
> > older versions, like 2.0.5, so it's safer to fix this by changing the
> pom
> > to use an explicit value instead of the groupId property.
> >
> > ( note that so far I've only seen this occur with plugin dependencies )
> >
> > The 1.0.1 release candidate is available here, along with the KEYS:
> >
> > http://people.apache.org/~mcculls/releases/felix/org.osgi.service.obr/
> >
> > Please check the release and cast your votes! (vote will run for 72hrs)
> >
> > --
> > Cheers, Stuart
> >
>
--
Cheers, Stuart
