July 2013 - jboss-osgi-issues - Jboss List Archives

[JBoss JIRA] (JBOSGI-665) OSGiMetaDataBuilder can be used with invalid manifest

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-665?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-665: ---------------------------------- Fix Version/s: JBossOSGi 2.0.1 > OSGiMetaDataBuilder can be used with invalid manifest > ----------------------------------------------------- > > Key: JBOSGI-665 > URL: https://issues.jboss.org/browse/JBOSGI-665 > Project: JBoss OSGi > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core Framework > Reporter: Thomas Diesler > Fix For: JBossOSGi 2.0.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-682) Add ability to provision adapted modules

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-682?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-682: ---------------------------------- Fix Version/s: JBossOSGi 2.0.1 > Add ability to provision adapted modules > ---------------------------------------- > > Key: JBOSGI-682 > URL: https://issues.jboss.org/browse/JBOSGI-682 > Project: JBoss OSGi > Issue Type: Feature Request > Components: Enterprise OSGi > Reporter: Thomas Diesler > Labels: repository > Fix For: JBossOSGi 2.0.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-288) Add HornetQ integration

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-288?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-288: ---------------------------------- Component/s: Enterprise OSGi > Add HornetQ integration > ----------------------- > > Key: JBOSGI-288 > URL: https://issues.jboss.org/browse/JBOSGI-288 > Project: JBoss OSGi > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Enterprise OSGi > Reporter: Thomas Diesler > Fix For: Awaiting Volunteers > > > Initially, we would need a (set of) service that allows an OSGi client to use the JMS API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-561) Add jBPM integration example

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-561?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-561: ---------------------------------- Component/s: Enterprise OSGi > Add jBPM integration example > ---------------------------- > > Key: JBOSGI-561 > URL: https://issues.jboss.org/browse/JBOSGI-561 > Project: JBoss OSGi > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Enterprise OSGi > Reporter: Thomas Diesler > Fix For: Awaiting Volunteers > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-322) Integrate the OSGi Remote Services implementation from CXF

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-322?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-322: ---------------------------------- Component/s: Enterprise OSGi > Integrate the OSGi Remote Services implementation from CXF > ---------------------------------------------------------- > > Key: JBOSGI-322 > URL: https://issues.jboss.org/browse/JBOSGI-322 > Project: JBoss OSGi > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Enterprise OSGi > Reporter: David Bosschaert > Fix For: Awaiting Volunteers > > > The Enterprise OSGi Spec describes OSGi Remote Services which is a way to Distribute OSGi Services. > An implementation on top of Web Services and REST is available at the CXF Distributed OSGi project (http://cxf.apache.org/distributed-osgi.html). > Integrating this in the JBoss OSGi distribution would provide it with support for this important OSGi spec. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-614) Allow Maven URLs to be configured to resolve external bundles

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-614?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-614: ---------------------------------- Labels: repository (was: ) > Allow Maven URLs to be configured to resolve external bundles > ------------------------------------------------------------- > > Key: JBOSGI-614 > URL: https://issues.jboss.org/browse/JBOSGI-614 > Project: JBoss OSGi > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Repository > Affects Versions: Continuing > Environment: All > Reporter: Ulrich Romahn > Assignee: Thomas Diesler > Labels: repository > Fix For: JBossOSGi 2.0.0 > > > Currently, JBoss OSGi allows to provide a Maven URI for a package which will then be resolved by the deployer according to the following rules: > 1. check if the artifact is present in a local Maven repo (.m2) > 2. if not, download the artifact from a remote Maven repo > Currently, the class MavenArtifactRepository has two Maven repository URLs hardcoded: > JBOSS_NEXUS_BASE = "http://repository.jboss.org/nexus/content/groups/public"; > MAVEN_CENTRAL_BASE = "http://repo1.maven.org/maven2"; > It should be possible to configure those URLs using some configuration mechanism. This is especially important in a real production environment where access to external URLs may be blocked by a firewall and an internal Nexus repo should be used to proxy a "stable set" of artifacts to be used for production. > The following configuration options should be possible: > 1. as it is right now > 2. switch off external resolution completely. Only artifacts currently present on the local filesystem (.m2) should be resolved and loaded > 3. Configure Maven URLs in addition to the hardcoded ones above > 4. Configure Maven URLs as complete replacements to the hardcoded ones above -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-732) Populate repository with metadata from system modules/bundles

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-732?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-732: ---------------------------------- Labels: repository (was: ) > Populate repository with metadata from system modules/bundles > ------------------------------------------------------------- > > Key: JBOSGI-732 > URL: https://issues.jboss.org/browse/JBOSGI-732 > Project: JBoss OSGi > Issue Type: Task > Components: Repository, WildFly > Reporter: Thomas Diesler > Labels: repository > > The OSGi configuration supports ModuleIdentifiers. So for example > {code} > <capability name="javax.transaction.api"/> > {code} > references the JTA API module. This actually delegates to the repository implementations which in turn delegates to the ModuleIdentityArtifactProvider. > If the AppServer supports the notion of multiple directories where modules can get loaded from, the ServerEnvironment should reflect that properly. I cannot just load a module on trial/error basis because we use the Repository for impact ananlysis. i.e. Find the modules/bundles that provide the transitive set of capabilities for a given set of requirements (without modifying the runtime). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-721) Separate feature provisioning service from OSGi

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-721?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-721: ---------------------------------- Labels: repository (was: ) > Separate feature provisioning service from OSGi > ------------------------------------------------ > > Key: JBOSGI-721 > URL: https://issues.jboss.org/browse/JBOSGI-721 > Project: JBoss OSGi > Issue Type: Task > Components: Repository > Reporter: Thomas Diesler > Labels: repository > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-585) Separate maven project.version from bundle.version and package version

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-585?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-585: ---------------------------------- Labels: repository (was: ) > Separate maven project.version from bundle.version and package version > ---------------------------------------------------------------------- > > Key: JBOSGI-585 > URL: https://issues.jboss.org/browse/JBOSGI-585 > Project: JBoss OSGi > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Distribution, Repository > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Labels: repository > Fix For: JBossOSGi 2.0.0 > > > We have a requirement to suffix final project versions with ".Final". To use this suffix in OSGi manifest headers changes the semantic meaning because 2.0.0.Final < 2.0.0. Hence a requirement of [2.0,3.0) would not include 2.0.0.Final. > Unless the JBoss version scheme changes we need to deal with this internally. I suggest to generate a maven property that has the suffix removed and use that instead of ${project.version} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-549) Provide API that allows add/remove of repository artefacts

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-549?page=com.atlassian.jira.plugin... ] Thomas Diesler updated JBOSGI-549: ---------------------------------- Labels: repository (was: ) > Provide API that allows add/remove of repository artefacts > ---------------------------------------------------------- > > Key: JBOSGI-549 > URL: https://issues.jboss.org/browse/JBOSGI-549 > Project: JBoss OSGi > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Repository > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Labels: repository > Fix For: JBossOSGi 2.0.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-issues July 2013