I'm no lawyer but afaik you should easily be able to just fork the github repo at push that new fork up to apache.org. The code's currently under EPL so moving it to ASL should be easily done -- or just leave it as-is, if it's OK to have ASF-hosted code under an EPL license. The project should be easy enough to build as long as you keep it current against the latest JBoss Tools parent pom [1] version. If you prefer to not have cross-org dependencies, or are not allowed to, you will probably have to implement your own parent pom (copy from ours into the freemarker plugin project's root pom). [1] https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml If you need to rebrand it (change namespace from org.jboss to org.apache) there's a way to ensure that old versions can still be updated through the namespace change. I can provide you with a PR or sample code for the p2.inf instructions you need in your feature(s) to support such a name change. It's really not that much work to move to another foundation -- we've often contributed org.jboss plugins/features to Eclipse so I know it's doable. Once you have it hosted at apache, building and publishing an update site (and/or zip) should be fairly easy too. Do you have a Jenkins or Hudson instance you can use there? Nick On Tue, Mar 6, 2018 at 5:43 AM, Daniel Dekany <ddekany(a)freemail.hu&gt; wrote: > Monday, March 5, 2018, 10:46:59 PM, Nick Boldt wrote: > >> Great question. See reply in >> https://stackoverflow.com/questions/49072160/why-is- > freemarker-ide-in-eclipse-oxygen-jboss-tools-4-5-2- > final-deprecated/49119784#49119784 > > Thanks! > >> Turns out we JUST removed Freemarker tooling from the forthcoming >> JBoss Tools 4.5.3.AM2 build (to be released tomorrow), after >> deprecating > it in July 2017. >> >> So, it could come back if you're willing to take ownership of the >> tooling builds & publication. > > Sure, I'm willing to (assuming there's no crazy administrative > overhead). In fact, I have asked about this earlier (like years ago), > as it was difficult to get my PR-s merged. > > Or, just my quick idea, but you can perhaps donate the code to the > ASF, where the FreeMarker project is anyway. Haven't looked into how > messy that would be legally though... > >> Do you have any stats to demonstrate the size of its user base? > > Nope. > > People who need this plugin need it because of FreeMarker, and they > have no "relationship" with the other JBoss IDE products, so... as > the > installation instructions on apache.freemarker.org say, they only > install the FreeMarker plugin. Then no statistics are collected, as > far as I understand from your answer on StackOverflow. > >> Nick >> >> >> >> On Sat, Mar 3, 2018 at 3:05 AM, Daniel Dekany <ddekany(a)freemail.hu&gt; > wrote: >> I have noticed months ago that the FreeMarker plugin was deprecated. >> As a current maintainer of FreeMarker, I would like to know what >> will >> it practically mean in the future, such as, will PR-s be still >> integrated, will the artifacts be still hosted, and for how long? >> What >> steps should we (at FreeMarker) take to ensure that the plugin >> remains >> available for users (if any)? >> >> Also, can someone answer this user question about the deprecation >> (as >> I'm not entirely sure about the answer either)?: >> https://stackoverflow.com/questions/49072160/why-is- > freemarker-ide-in-eclipse-oxygen-jboss-tools-4-5-2-final-deprecated >> >> -- >> Thanks, >> Daniel Dekany >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> >> > > -- > Thanks, > Daniel Dekany > > -- Nick Boldt Senior Software Engineer, RHCSA Productization Lead :: JBoss Tools & Dev Studio IM: @nickboldt / @nboldt / http://nick.divbyzero.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> @ @redhatnews <https://twitter.com/redhatnews> Red Hat <https://www.facebook.com/RedHatInc> <https://www.facebook.com/RedHatInc> “The Only Thing That Is Constant Is Change” - Heraclitus

_______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Hi, On Wed, Mar 7, 2018 at 5:16 PM, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > just want to raise that we don't need to move to apache - we can make > anyone a contributor > on the jboss tools freemarker plugin that agreeds to the jboss CLA. > This situation is deeply confusing for JBoss Tools maintainers and potential contributors and your proposal wouldn't help: we -as Red Hat employees- ha've been asked to drop maintenance of jbosstools-freemarker for business or strategical reasons, but we keep it under jbosstools (~= Red Hat) organization. This gives the impression to contributors that we're still owning and maintaining this code. If we want to open this repo to new contributors, incoming contributors would expect us to review PRs, maintain builds and all that stuff we're exactly supposed to not do any more while we stop maintaining. Moreover, some contributors may not like contributing to JBoss or Red Hat branded projects because it's not a vendor-neutral ecosystem. Keeping things like it isn't profitable to anyone and we generally need to clarify what we mean by "not maintained" and how to properly "give up" components like this. We're currently in a mid-ground that's blocking all possible progress or decision. The big question in that case is whether we (Red Hat) is ready to make the effort to "give" such almost abandoned code to Eclipse or Apache Foundation (this involves effort to rebrand package and artifacts, make standalone build, move code...)? That's something we need to clarify before moving any further. If the answer is that Red Hat isn't willing to make that migration effort but wouldn't mind anyone else doing it and would approve it legally, let's just write it down very clearly in the README and remove everything else that's not relevant any more. And we can make a statement to Apache or Eclipse that we approve someone else moving this code. If the answer is that Red Hat can support with manpower migration of this code to someplace else, then it needs to be made more official before people can work on this instead of other stuff. But if we do that, it also means we need to make clear that we're moving the code to better abandon it and let other owns it immediately, as there is no more reason to maintain it at Apache/Eclipse than in jbosstools-freemarker repo. @Max: I really believe we need a hierarchical decision here, it's not a 5 minutes task, and leaving it on GitHub like this can be perceived as technical debt because we still get users reaching us with questions. _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

The hierarchical decision is here as removal as been approved by PM

On Wed, Mar 7, 2018 at 5:46 PM, Mickael Istria <mistria(a)redhat.com&gt; wrote: > Hi, > > On Wed, Mar 7, 2018 at 5:16 PM, Max Rydahl Andersen > <manderse(a)redhat.com&gt; > wrote: > >> just want to raise that we don't need to move to apache - we can >> make >> anyone a contributor >> on the jboss tools freemarker plugin that agreeds to the jboss CLA. >> > This situation is deeply confusing for JBoss Tools maintainers and > potential contributors and your proposal wouldn't help: we -as Red > Hat > employees- ha've been asked to drop maintenance of > jbosstools-freemarker > for business or strategical reasons, but we keep it under jbosstools > (~= > Red Hat) organization. This gives the impression to contributors that > we're > still owning and maintaining this code. If we want to open this repo > to new > contributors, incoming contributors would expect us to review PRs, > maintain > builds and all that stuff we're exactly supposed to not do any more > while > we stop maintaining. Moreover, some contributors may not like > contributing > to JBoss or Red Hat branded projects because it's not a > vendor-neutral > ecosystem. > Keeping things like it isn't profitable to anyone and we generally > need to > clarify what we mean by "not maintained" and how to properly "give > up" > components like this. We're currently in a mid-ground that's blocking > all > possible progress or decision. > > The big question in that case is whether we (Red Hat) is ready to > make the > effort to "give" such almost abandoned code to Eclipse or Apache > Foundation > (this involves effort to rebrand package and artifacts, make > standalone > build, move code...)? That's something we need to clarify before > moving any > further. > If the answer is that Red Hat isn't willing to make that migration > effort > but wouldn't mind anyone else doing it and would approve it legally, > let's > just write it down very clearly in the README and remove everything > else > that's not relevant any more. And we can make a statement to Apache > or > Eclipse that we approve someone else moving this code. > If the answer is that Red Hat can support with manpower migration of > this > code to someplace else, then it needs to be made more official before > people can work on this instead of other stuff. But if we do that, it > also > means we need to make clear that we're moving the code to better > abandon it > and let other owns it immediately, as there is no more reason to > maintain > it at Apache/Eclipse than in jbosstools-freemarker repo. > > @Max: I really believe we need a hierarchical decision here, it's not > a 5 > minutes task, and leaving it on GitHub like this can be perceived as > technical debt because we still get users reaching us with questions. > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- JEFF MAURY Red Hat <https://www.redhat.com/> jmaury(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit> @redhatjobs <https://twitter.com/redhatjobs> redhatjobs <https://www.facebook.com/redhatjobs/> @redhatjobs <https://instagram.com/redhatjobs>

Wednesday, March 7, 2018, 5:46:34 PM, Mickael Istria wrote: > Hi, > > On Wed, Mar 7, 2018 at 5:16 PM, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > just want to raise that we don't need to move to apache - we can make anyone a contributor > on the jboss tools freemarker plugin that agreeds to the jboss CLA. > This situation is deeply confusing for JBoss Tools maintainers and > potential contributors and your proposal wouldn't help: we -as Red > Hat employees- ha've been asked to drop maintenance of > jbosstools-freemarker for business or strategical reasons, but we > keep it under jbosstools (~= Red Hat) organization. This gives the > impression to contributors that we're still owning and maintaining > this code. If we want to open this repo to new contributors, > incoming contributors would expect us to review PRs, maintain builds > and all that stuff we're exactly supposed to not do any more while > we stop maintaining. Moreover, some contributors may not like > contributing to JBoss or Red Hat branded projects because it's not a vendor-neutral ecosystem. > Keeping things like it isn't profitable to anyone and we generally > need to clarify what we mean by "not maintained" and how to properly > "give up" components like this. We're currently in a mid-ground > that's blocking all possible progress or decision. > > The big question in that case is whether we (Red Hat) is ready to > make the effort to "give" such almost abandoned code to Eclipse or > Apache Foundation (this involves effort to rebrand package and > artifacts, make standalone build, move code...)? That's something we > need to clarify before moving any further. I think you can just sign the Software Grant and Corporate Contributor License Agreement, make a PR on Github on the ASF repository prepared for the purpose, and the Apache FreeMarker committers will do the rest (replacing license headers, renaming packages, getting rid of improper dependencies, etc.). Now that's not an official statement from ASF, but I can ask ASF legal if needed. > If the answer is that Red Hat isn't willing to make that migration > effort but wouldn't mind anyone else doing it and would approve it > legally, let's just write it down very clearly in the README and > remove everything else that's not relevant any more. And we can make > a statement to Apache or Eclipse (Apache, surely not Eclipse in this concrete case. FreeMarker is owned by Apache.) > that we approve someone else moving this code. > If the answer is that Red Hat can support with manpower migration > of this code to someplace else, then it needs to be made more > official before people can work on this instead of other stuff. But > if we do that, it also means we need to make clear that we're moving > the code to better abandon it and let other owns it immediately, as > there is no more reason to maintain it at Apache/Eclipse than in jbosstools-freemarker repo. > > @Max: I really believe we need a hierarchical decision here, it's > not a 5 minutes task, and leaving it on GitHub like this can be > perceived as technical debt because we still get users reaching us with questions. -- Thanks, Daniel Dekany _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev