Mailing-List: contact issues-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Date: Thu, 26 Jan 2012 14:54:40 +0000 (UTC)
From: =?utf-8?Q?Jean-Baptiste_Onofr=C3=A9_=28Updated=29_=28JIRA=29?=
 <jira@apache.org>
To: issues@karaf.apache.org
Message-ID: 
 <1509763723.81438.1327589680327.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <351861536.77016.1327512880490.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (KARAF-1169) Support for hidden or dependent
 features....
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/KARAF-1169?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Baptiste Onofr=C3=A9 updated KARAF-1169:
----------------------------------------

      Description:=20
Some applications we have have blocks of common dependencies that are share=
d by multiple features.  We currently define them in a new feature, but tha=
t's not really what they are as it's not expected to be installed individua=
lly.  Right now, they appear in things like the features:list which can con=
fuse users.   We can just put all the bundles in that feature into all the =
other features that need it, but that duplicates a lot of stuff and can cre=
ate additional maintenance work.=20

There are a couple options that could be pursued:
1) Could just add a flag like dependency=3D"true" or abstract=3D"true" or h=
idden=3D"true" to <feature> to mark the feature as something that shouldn't=
 really be exposed to the user.

2) Create a new tag to express common blocks of bundles that can be depende=
d on from a feature. =20

For example, CXF has a "cxf-saaj-impl" feature that installs the bundles ne=
eded for SAAJ to work.   That is then required by ws-security and jaxws and=
 a few others.   It's not really something we would expect users to "featur=
es:install", but we also don't want to duplicate that setup in a bunch of o=
ther places.


  was:

Some applications we have have blocks of common dependencies that are share=
d by multiple features.  We currently define them in a new feature, but tha=
t's not really what they are as it's not expected to be installed individua=
lly.  Right now, they appear in things like the features:list which can con=
fuse users.   We can just put all the bundles in that feature into all the =
other features that need it, but that duplicates a lot of stuff and can cre=
ate additional maintenance work.=20

There are a couple options that could be pursued:
1) Could just add a flag like dependency=3D"true" or abstract=3D"true" or h=
idden=3D"true" to <feature> to mark the feature as something that shouldn't=
 really be exposed to the user.

2) Create a new tag to express common blocks of bundles that can be depende=
d on from a feature. =20

For example, CXF has a "cxf-saaj-impl" feature that installs the bundles ne=
eded for SAAJ to work.   That is then required by ws-security and jaxws and=
 a few others.   It's not really something we would expect users to "featur=
es:install", but we also don't want to duplicate that setup in a bunch of o=
ther places.


    Fix Version/s: 3.1.0
         Assignee: Jean-Baptiste Onofr=C3=A9
   =20
> Support for hidden or dependent features....
> --------------------------------------------
>
>                 Key: KARAF-1169
>                 URL: https://issues.apache.org/jira/browse/KARAF-1169
>             Project: Karaf
>          Issue Type: Improvement
>          Components: karaf-features
>            Reporter: Daniel Kulp
>            Assignee: Jean-Baptiste Onofr=C3=A9
>             Fix For: 3.1.0
>
>
> Some applications we have have blocks of common dependencies that are sha=
red by multiple features.  We currently define them in a new feature, but t=
hat's not really what they are as it's not expected to be installed individ=
ually.  Right now, they appear in things like the features:list which can c=
onfuse users.   We can just put all the bundles in that feature into all th=
e other features that need it, but that duplicates a lot of stuff and can c=
reate additional maintenance work.=20
> There are a couple options that could be pursued:
> 1) Could just add a flag like dependency=3D"true" or abstract=3D"true" or=
 hidden=3D"true" to <feature> to mark the feature as something that shouldn=
't really be exposed to the user.
> 2) Create a new tag to express common blocks of bundles that can be depen=
ded on from a feature. =20
> For example, CXF has a "cxf-saaj-impl" feature that installs the bundles =
needed for SAAJ to work.   That is then required by ws-security and jaxws a=
nd a few others.   It's not really something we would expect users to "feat=
ures:install", but we also don't want to duplicate that setup in a bunch of=
 other places.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira