[
https://issues.jboss.org/browse/JBIDE-16407?page=com.atlassian.jira.plugi...
]
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