You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Stuart McCulloch <st...@jayway.net> on 2008/02/01 10:58:31 UTC
[Vote] release org.osgi.service.obr 1.0.1
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
Re: [Vote] release org.osgi.service.obr 1.0.1
Posted by Stuart McCulloch <st...@jayway.net>.
On 01/02/2008, Stuart McCulloch <st...@jayway.net> 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/<http://people.apache.org/%7Emcculls/releases/felix/org.osgi.service.obr/>
>
> Please check the release and cast your votes! (vote will run for 72hrs)
+1
--
> Cheers, Stuart
--
Cheers, Stuart
Re: [Vote] release org.osgi.service.obr 1.0.1
Posted by Stuart McCulloch <st...@jayway.net>.
On 01/02/2008, Richard S. Hall <he...@ungoverned.org> wrote:
>
> +1
>
> Minor nit, the NOTICE file in the JAR is different than the NOTICE file
> in the project...this may be the case with other releases too...we
> should probably have them be the same.
whoops, forgot to remove the leftover NOTICE and LICENSE files from
src/main/resources - we don't need these now, so I've deleted them
I could just copy it from the subproject root to the resource directory
> and commit, but did we decide on a way to eliminate the two NOTICE files?
yes we did - Carsten added the relevant resources setting to the main
Felix pom so the NOTICE and LICENSE files from the sub-modules root
are also copied to the META-INF directory in the jar.
-> richard
>
> Stuart McCulloch 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
Re: [Vote] release org.osgi.service.obr 1.0.1
Posted by "Richard S. Hall" <he...@ungoverned.org>.
+1
Minor nit, the NOTICE file in the JAR is different than the NOTICE file
in the project...this may be the case with other releases too...we
should probably have them be the same.
I could just copy it from the subproject root to the resource directory
and commit, but did we decide on a way to eliminate the two NOTICE files?
-> richard
Stuart McCulloch 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)
>
>
Re: [Vote] release org.osgi.service.obr 1.0.1
Posted by Felix Meschberger <fm...@gmail.com>.
+1
Regards
Felix
Am Freitag, den 01.02.2008, 17:58 +0800 schrieb Stuart McCulloch:
> 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)
>
Re: [Vote] release org.osgi.service.obr 1.0.1
Posted by Stuart McCulloch <st...@jayway.net>.
On 02/02/2008, Alin Dreghiciu <ad...@gmail.com> wrote:
>
> 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.
actually I remember now - the API version is in the packageinfo file
under "src/main/resources" (similar to the core and compendium)
which is why it's not in the pom.xml
so if/when we release it as a bundle the API will have version "1.0"
--
Cheers, Stuart
Re: [Vote] release org.osgi.service.obr 1.0.1
Posted by Alin Dreghiciu <ad...@gmail.com>.
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 <st...@jayway.net> wrote:
> On 01/02/2008, Alin Dreghiciu <ad...@gmail.com> 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 <st...@jayway.net>
> > 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
>
Re: [Vote] release org.osgi.service.obr 1.0.1
Posted by Stuart McCulloch <st...@jayway.net>.
On 01/02/2008, Alin Dreghiciu <ad...@gmail.com> 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 <st...@jayway.net>
> 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
Re: [Vote] release org.osgi.service.obr 1.0.1
Posted by Alin Dreghiciu <ad...@gmail.com>.
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?
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?
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?
Alin
On Feb 1, 2008 5:58 PM, Stuart McCulloch <st...@jayway.net> 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
>
RE: [Vote] release org.osgi.service.obr 1.0.1
Posted by Clement Escoffier <cl...@gmail.com>.
+1
Clement
> -----Message d'origine-----
> De : Karl Pauls [mailto:karlpauls@gmail.com]
> Envoyé : samedi 2 février 2008 08:08
> À : dev@felix.apache.org
> Objet : Re: [Vote] release org.osgi.service.obr 1.0.1
>
> +1
>
> regards,
>
> Karl
>
> On Feb 1, 2008 10:58 AM, Stuart McCulloch <st...@jayway.net>
> 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
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
Re: [Vote] release org.osgi.service.obr 1.0.1
Posted by Karl Pauls <ka...@gmail.com>.
+1
regards,
Karl
On Feb 1, 2008 10:58 AM, Stuart McCulloch <st...@jayway.net> 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
>
--
Karl Pauls
karlpauls@gmail.com