[RESULT][VOTE] Felix 1.0.1 framework and main release
Time to call the vote on the Felix 1.0.1 framework and main release. * +1 votes from Stefano Lenzi, Karl Pauls, Niclas Hedhman, Richard S. Hall, Rob Walker, Marcel Offermans, Felix Meschberger, Didier Donsez, Emil Ivov, Stuart McCulloch, Toni Menzel. * No other votes The vote is successful. I will make the release artifacts available as soon as possible. On 9/18/07, Karl Pauls [EMAIL PROTECTED] wrote: I would like to call a vote on the framework and main 1.0.1 release. The source release archives, signature files, SHA and MD5 message digests for each are available as zip and tar.gz here: http://people.apache.org/~pauls/felix-1.0.1.html Additionally, a binary release is included on the page as a convenience download as well as the framework and main binaries in order to make them available via maven. Please vote to approve these release archives: [ ] +1 Approve the Felix 1.0.1 framework and main releases. [ ] -1 Veto the release (please provide specific comments)
[jira] Work started: (FELIX-296) jsp-api 2.0 wrapping
[ https://issues.apache.org/jira/browse/FELIX-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-296 started by Felix Meschberger. jsp-api 2.0 wrapping Key: FELIX-296 URL: https://issues.apache.org/jira/browse/FELIX-296 Project: Felix Issue Type: New Feature Components: Felix Commons Reporter: Alin Dreghiciu Assignee: Felix Meschberger Priority: Minor Attachments: pom.xml Create an OSGi bundle for the jsp-api 2.0 jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-295) servlet-api 2.4 wrapping
[ https://issues.apache.org/jira/browse/FELIX-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-295. --- Resolution: Fixed I updated the servlet-api project to refer to Servlet API 2.4 instead of 2.3. So I assume this can be closed. Fixed in Rev. 578327 and deployed to SNAPSHOT repo. servlet-api 2.4 wrapping - Key: FELIX-295 URL: https://issues.apache.org/jira/browse/FELIX-295 Project: Felix Issue Type: New Feature Components: Felix Commons Reporter: Alin Dreghiciu Assignee: Felix Meschberger Priority: Minor Attachments: pom.xml Create an OSGi bundle for the servlet-api 2.4 jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems with latest bundle/obr plugin
Ok, I've found the issue - the goal of the obr deploy phase should be deployment not deploy - I've fixed this in the bundleplugin. Carsten Carsten Ziegeler wrote: Hi, I'm trying the latest maven-bundle-plugin and now I get the following error: [ERROR] BUILD FAILURE [INFO] [INFO] Required goal not found: org.apache.felix:maven-obr-plugin:deploy Any ideas? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: FYI, bundles of jar specifications
Sorry for the misunderstanding. I was talking about all j2ee related specification (jms, servlet, etc...) On 9/24/07, Richard S. Hall [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: I've began to change the geronimo versions of the spec jars to be OSGi bundles. See http://svn.apache.org/repos/asf/geronimo/specs/trunk/ I think it will be easier for OSGi users than relying on some unreleased pom in felix commons. There is no problem with using the OSGi JARs for the spec and the compendium...no one is forced to use the Felix ones. However, when Felix' framework and main JARs are created, they contained some modified versions of OSGi classes, so things are not completely replaceable when trying to package the framework... - richard -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: FYI, bundles of jar specifications
On 24/09/2007, Richard S. Hall [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: I've began to change the geronimo versions of the spec jars to be OSGi bundles. See http://svn.apache.org/repos/asf/geronimo/specs/trunk/ I think it will be easier for OSGi users than relying on some unreleased pom in felix commons. There is no problem with using the OSGi JARs for the spec and the compendium...no one is forced to use the Felix ones. However, when I think Guillaume meant the Geronimo spec jars, not the OSGi specs :) Geronimo now provides OSGi bundles of spec jars such as JTA - which is great news! Felix' framework and main JARs are created, they contained some modified versions of OSGi classes, so things are not completely replaceable when trying to package the framework... - richard -- Cheers, Stuart
Re: FYI, bundles of jar specifications
Stuart McCulloch wrote: On 24/09/2007, Richard S. Hall [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: I've began to change the geronimo versions of the spec jars to be OSGi bundles. See http://svn.apache.org/repos/asf/geronimo/specs/trunk/ I think it will be easier for OSGi users than relying on some unreleased pom in felix commons. There is no problem with using the OSGi JARs for the spec and the compendium...no one is forced to use the Felix ones. However, when I think Guillaume meant the Geronimo spec jars, not the OSGi specs :) Yes, I see that now. :-) Geronimo now provides OSGi bundles of spec jars such as JTA - which is great news! This is definitely excellent...we'd be more than happy if all open source projects put Felix Commons out of business! ;-) - richard Felix' framework and main JARs are created, they contained some modified versions of OSGi classes, so things are not completely replaceable when trying to package the framework... - richard
problem with ${pom.groupId} dependencies in Felix poms
Hi,
I've noticed a lot of the Felix poms are using ${pom.groupId} in their
dependencies
this is causing me grief as in some scenarios maven replaces this with my
_local_ project groupId, not org.apache.felix
for example, here it looks for
my.example.project:org.apache.felix.shell:jar:1.0.0 !
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) my.example.project:org.apache.felix.shell:jar:1.0.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=my.example.project -DartifactId=
org.apache.felix.shell \
-Dversion=1.0.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.ops4j:maven-pax-plugin:maven-plugin:0.2.0-SNAPSHOT
2) org.apache.felix:maven-bundle-plugin:maven-plugin:1.1.0-SNAPSHOT
3) org.apache.felix:maven-obr-plugin:jar:0.1.0-SNAPSHOT
4) org.apache.felix:org.apache.felix.bundlerepository:jar:1.0.0
5) my.example.project:org.apache.felix.shell:jar:1.0.0
there is not much gain to using ${pom.groupId} as the group is unlikely to
change much, and even if one artifact
decides to change group what happens if some (or all) of its dependencies
want to retain the old group?
IMHO we should avoid using ${pom.*} variables in pom dependencies to be
certain which artifact it will pick up
WDYT?
--
Cheers, Stuart
Re: problem with ${pom.groupId} dependencies in Felix poms
I remember that issue with ${project.version} (project and pom
variables should be the same) when the version was a snapshot, but
never with groupId
A workaround was to define a property (eg. felix.group) in the parent
pom and use ${felix.group} in the children
On 9/24/07, Stuart McCulloch [EMAIL PROTECTED] wrote:
Hi,
I've noticed a lot of the Felix poms are using ${pom.groupId} in their
dependencies
this is causing me grief as in some scenarios maven replaces this with my
_local_ project groupId, not org.apache.felix
for example, here it looks for
my.example.project:org.apache.felix.shell:jar:1.0.0 !
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) my.example.project:org.apache.felix.shell:jar:1.0.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=my.example.project -DartifactId=
org.apache.felix.shell \
-Dversion=1.0.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.ops4j:maven-pax-plugin:maven-plugin:0.2.0-SNAPSHOT
2) org.apache.felix:maven-bundle-plugin:maven-plugin:1.1.0-SNAPSHOT
3) org.apache.felix:maven-obr-plugin:jar:0.1.0-SNAPSHOT
4) org.apache.felix:org.apache.felix.bundlerepository:jar:1.0.0
5) my.example.project:org.apache.felix.shell:jar:1.0.0
there is not much gain to using ${pom.groupId} as the group is unlikely to
change much, and even if one artifact
decides to change group what happens if some (or all) of its dependencies
want to retain the old group?
IMHO we should avoid using ${pom.*} variables in pom dependencies to be
certain which artifact it will pick up
WDYT?
--
Cheers, Stuart
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: problem with ${pom.groupId} dependencies in Felix poms
On 25/09/2007, Carlos Sanchez [EMAIL PROTECTED] wrote:
I remember that issue with ${project.version} (project and pom
variables should be the same) when the version was a snapshot, but
never with groupId
this appeared when using the invoker plugin to run some integration tests
A workaround was to define a property (eg. felix.group) in the parent
pom and use ${felix.group} in the children
true - but experience has taught me that rather than try to be too clever
with
properties, etc. it makes life much easier to just write org.apache.felix
or
whatever in the dependency - then anyone viewing the pom doesn't have to
hunt around the hierarchy for the property value.
org.apache.felix is only a few characters longer than ${pom.groupId} :)
On 9/24/07, Stuart McCulloch [EMAIL PROTECTED] wrote:
Hi,
I've noticed a lot of the Felix poms are using ${pom.groupId} in their
dependencies
this is causing me grief as in some scenarios maven replaces this with
my
_local_ project groupId, not org.apache.felix
for example, here it looks for
my.example.project:org.apache.felix.shell:jar:1.0.0 !
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) my.example.project:org.apache.felix.shell:jar:1.0.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=my.example.project-DartifactId=
org.apache.felix.shell \
-Dversion=1.0.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.ops4j:maven-pax-plugin:maven-plugin:0.2.0-SNAPSHOT
2)
org.apache.felix:maven-bundle-plugin:maven-plugin:1.1.0-SNAPSHOT
3) org.apache.felix:maven-obr-plugin:jar:0.1.0-SNAPSHOT
4) org.apache.felix:org.apache.felix.bundlerepository:jar:1.0.0
5) my.example.project:org.apache.felix.shell:jar:1.0.0
there is not much gain to using ${pom.groupId} as the group is unlikely
to
change much, and even if one artifact
decides to change group what happens if some (or all) of its
dependencies
want to retain the old group?
IMHO we should avoid using ${pom.*} variables in pom dependencies to be
certain which artifact it will pick up
WDYT?
--
Cheers, Stuart
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
--
Cheers, Stuart
Re: unable to build Felix from clean repository
I guess it sounds reasonable to me. - richard Stuart McCulloch wrote: Hi, me again :) there's been an unfortunate side-effect of adding the OBR plugin to the bundle life-cycle... maven-bundle-plugin has a dependency on maven-obr-plugin maven-obr-plugin has a dependency on bundlerepository bundlerepository has packaging bundle ... which needs maven-bundle-plugin to build :( I have a solution that I've tested locally: create a new sub-project called 'org.osgi.service.obr' and move bundlerepository/src/main/java/org/osgi/service/obr/*.java to it - org.osgi.service.obr will be a standard Jar containing the OSGi OBR service API add 'org.osgi.service.obr' as a dependency to bundlerepository and maven-obr-plugin (it replaces the bundlerepository dependency) replace the 'org.osgi.core' dependency in maven-obr-plugin with org.osgi:osgi_R4_core (ie. the non-bundle artifact from central) add 'org.osgi.service.obr' to the plugin build phase and trunk can once again build from scratch so any comments - should I open a JIRA issue for this, or go ahead and commit my changes?
