[jbosstools-issues] [JBoss JIRA] (JBIDE-16407) Decouple openshift from legacy astools code

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-16407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940340#comment-12940340 ] 

Rob Stryker commented on JBIDE-16407:
-------------------------------------

The commit can wait until progress on the astools branch is determined, if you'd feel more comfortable.

Openshift needs to decide *how* they want to accomplish those goals. If they want to buy into the concept of subsystems and profiles for their server, then they would need to rewrite their server adapter to work with the new API anyway.   Or, if they just want to handle it all themselves, roll their own mini-solution, they can do that too. 

But, if the ASTools branch is accepted into master, (or even if it's not, honestly) I don't think its smart for openshift to be building out new infrastructure and behavior based on an old api that is hard to follow, not unified in any real way, and a mish-mash of random crap.  

So in that regard, I would suggest they either role their own solution, or use the new API, but I would not advise them to build such new infrastructure on an old broken api that can't be changed or enhanced or flexible in any way to accomodate their needs. It is horrendously tied into each other and nearly impossible to decouple. One look at the existing openshift code immediately shows that it was trying to fit a square peg into a round ASTools  solution.   The old ASTools api was not designed for openshift to be able to use it.

The new one is. 

So again, I would advise OS to either roll their own or use the new subsystems / profiles stuff, but I think it would bad for them to continue using the old api (even if we don't merge the astools branch into master). 

So, in short, I don't think they'd need to roll it back.  But the fact is they do need to design a solution, and the question is whether it'd be their own creation or based on the new astools api. I would honestly suggest they begin looking into the new API to see if it suits their needs and give feedback. 

... But I think I'm generally in charge of the os server code anyway ;) 

Can we get links to those jiras? It'd help me list out the use cases and see any obvious issues or missing functionality with my newer API. 
                
> Decouple openshift from legacy astools code
> -------------------------------------------
>
>                 Key: JBIDE-16407
>                 URL: https://issues.jboss.org/browse/JBIDE-16407
>             Project: Tools (JBoss Tools)
>          Issue Type: Task
>          Components: openshift
>    Affects Versions: 4.2.0.Alpha1
>            Reporter: Rob Stryker
>            Assignee: Rob Stryker
>
> With coming changes to astools, openshift depends on classes that will most likely be deprecated and removed. 
> Even if its not, openshift is currently using an astools framework that is really geared for servers that can change behavior heavily based on various settings. It's not quite appropriate for openshift which has only one core behavior in terms of publishing etc. 

--
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