On Thu December 17 2009 5:33:39 am [email protected] wrote: > Yeah - I think its a good idea to put CXF DOSGi as a separate project in > JIRA.
I've set it up: https://issues.apache.org/jira/browse/DOSGI On a related note, should we have a separate DOSGi space on the wiki as well like we do for the docs? It could then have it's own navigation bar, etc.... The top level page at cxf.apache.org would point dosgi project to a subdir like http://cxf.apache.org/dosgi or similar. Thoughts? Dan > > Thanks, > > David > > 2009/12/17 Daniel Kulp <[email protected]>: > > Is there any objections to moving the DOSGI stuff out to it's own JIRA? > > If not, I'll do so on Friday. Speak now... :-) > > > > Dan > > > > On Mon December 14 2009 2:39:17 pm Daniel Kulp wrote: > >> Quick question: > >> > >> What are peoples thoughts about pulling the DOSGi stuff from the "CXF" > >> JIRA into a separate CXFDOSGI (or just DOSGI) JIRA in the "Category: > >> CXF" section at: > >> https://issues.apache.org/jira/secure/BrowseProjects.jspa > >> > >> There are pluses and minuses: > >> DOSGi has it's own release schedule, own version numbers,etc.... Thus, > >> having it's own project in JIRA allows it to track those things > >> properly without it affecting the main CXF project. > >> > >> Also, DOSGi has it's own components such as its own build system, local > >> vs remote discovery, etc... Having it's own JIRA project would allow > >> defining nice components for it's own uses. > >> > >> On the minus side, it does kind of lower the visibility of the DOSGi > >> issues in the CXF JIRA since they wouldn't be there. > >> > >> > >> One COULD argue that JAX-RS could also be pulled out. However, the > >> JAX-RS stuff is currently part of the main build and released as part of > >> the full CXF stuff. Thus, keeping it in is less of an issue. If we > >> eventually split the builds into a "core", "webservices", "rest", etc... > >> then it may make sense to do so at that time. > >> > >> Thoughts? > > > > -- > > Daniel Kulp > > [email protected] > > http://www.dankulp.com/blog > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
