Anyhow (see bellow) my vote is +1 as the changes does not influence
the discussion bellow.
Alin
On Feb 1, 2008 7:23 PM, Stuart McCulloch <[EMAIL PROTECTED]> wrote:
> 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...
I get the reason now, still...
>
> 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).
In my view the fact that org.osgi:org.osgi.core is not a bundle by
itself is just a mistake related to the jar in the maven central repo
as the osgi original jar's (the ones you can get from osgi.org) are
bundles not plain jars.
>
> 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!)
Well, if it is to become a spec I guess the reason behind is that
there will be other implementations beside felix. And those may decide
to embed the api or not.
>
> 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)
Whatever the status is of obr is now if the bundlerepository exports
the package I guess it should export it with a version. at least
future versions of the api should.
>
> 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?
Yes.
> 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
>
