There is some discussion about this, though. We aren't sure if it's the "hosting" or the "management" of the code that is the sticking point. The hosting is definitely out, but merely using an external source control system and all the other infrastructure/management services here at the ASF might not work either. Perhaps we need to talk to the board or legal-discuss?
James On Wed, Sep 26, 2012 at 4:04 AM, Willem jiang <willem.ji...@gmail.com> wrote: > +1 if we can unify the wiki and issue for Camel and Camel-Extra. > The reason which we setup the Camel-Extra project is we cannot host the code > of GPL license in Apache. > I don't think we cannot add the document or issues into Apache Camel due to > that kind of issue. > > Any thoughts? > > > On Wednesday, September 26, 2012 at 3:19 PM, Henryk Konsek wrote: > >> > - Using Apache JIRA for Camel extra >> >> >> >> For now, I'll keep Camel Extra issues in Google Issue tracker. We >> shouldn't have Camel Extra issues spread around two places. However it >> will be nice if eventually we could use Jira for that. >> >> > (- Using Issue notifications on iss...@camel.apache.org >> > (mailto:iss...@camel.apache.org) for issues raised >> > in Camel extra) >> > - Using Commit notifications on comm...@camel.apache.org >> > (mailto:comm...@camel.apache.org) for changes in >> > Camel extra >> >> >> >> Yeah, since from the developer point of view it doesn't matter if >> somebody commits to Regular Camel or Extra Camel. >> >> > - Using the Apache Confluence WIKI for Camel extra components >> >> IMHO This is a must. We need uniform documentation format for all >> Camel stuff. I can't imagine redirecting end users to another >> documentation site. >> >> Camel by nature integrates technologies with various licenses. If we >> make non-Apache components a second class citizens, will be a >> second-class integration framework when it comes to non-Apache >> software. And Mule users will laugh at us :) . >> >> -- >> Henryk Konsek >> http://henryk-konsek.blogspot.com > > >
