Fwd: [epp-dev] Heads Up and some action requested : TCF Terminals Moving to TM
by Max Rydahl Andersen
Hey,
I believe this will end up affecting us too.
Opened jira for this: https://issues.jboss.org/browse/JBDS-3384
For most this is just a repackaging that don't affect code, but for Fuse
Tooling
which currently rely on org.eclipse.tm.internal.terminal this will
require changes.
/max
http://about.me/maxandersen
Forwarded message:
> From: Oberhuber, Martin <Martin.Oberhuber(a)windriver.com>
> To: Eclipse Packaging Project <epp-dev(a)eclipse.org>
> Subject: Re: [epp-dev] Heads Up and some action requested : TCF
> Terminals Moving to TM
> Date: Thu, 19 Mar 2015 15:54:07 +0000
>
> Hi Package Maintainers,
>
> We have been convinced that contributing from TCF under a foreign
> namespace is not a good idea.
> On the other hand, the deprecated legacy terminal view has already
> been removed from the simrel:
> http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=d...
>
> This means there is now some action strongly suggested, or packages
> might fail to build or build against outdated (M5) terminal
> contributions:
>
> - jee : Remove legacy terminal.view , optionally add the new
> tcf.terminals.view - Bug
> 462087<https://bugs.eclipse.org/bugs/show_bug.cgi?id=462087>
>
> - reporting : Remove legacy terminal.view , optionally add
> the new tcf.terminals.view - Bug
> 462089<https://bugs.eclipse.org/bugs/show_bug.cgi?id=462089>
>
> - parallel : Optionally add
> org.eclipse.tcf.te.terminals.feature AND
> org.eclipse.tcf.te.terminals.rse.feature
>
> - cpp : Optionally add org.eclipse.tcf.te.terminals.feature
> AND org.eclipse.tcf.te.terminals.rse.feature
>
> For the must-have changes in jee and reporting, we have created bugs
> and Gerrit changesets.
> Since I am an epp committer, I think I could apply these for you, but
> I would like the package maintainer's OK before I do that.
>
> I would strongly recommend also applying the optional changes (adding
> the TCF Terminals View) such that users can see the new view and
> provide feedback.
> Without doing this, the Terminal view would be GONE in the respective
> packages in M6 and only reappear in M7 once the move has been
> completed.
> I can also apply these changes for you if I get your OK.
>
> Please let me know how you want to proceed, and if there's any
> questions/concerns !
>
> Thanks,
> Martin
> --
> Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
> direct +43.662.457915.85 fax +43.662.457915.6
>
> From: epp-dev-bounces(a)eclipse.org [mailto:epp-dev-bounces@eclipse.org]
> On Behalf Of Oberhuber, Martin
> Sent: Monday, March 16, 2015 6:17 PM
> To: EPP Developer Mailing List (epp-dev(a)eclipse.org)
> Subject: [epp-dev] Heads Up and some action requested : TCF Terminals
> Moving to TM
>
> Hi Package Maintainers,
>
> You might be aware that based on the original TM Terminal view, the
> TCF Project has come up with a much enhanced terminal:
> https://marketplace.eclipse.org/content/tcf-terminals
>
> In order to simplify code adoption and contributions, we want to
> restructure the codebase and re-unite it with the original TM
> codebase.
> The result will be called "TM Terminal 4.0" but will contain the
> related TM _and_ TCF code in a single, small git repository.
> Here is the respective restructuring review:
> https://projects.eclipse.org/projects/tools.cdt.tcf/reviews/move-tcf-term...
>
> Now unfortunately the review is scheduled to complete by April 1 which
> is after M6, but we would like to give adopters
> a preview of the new Terminal with M6 in order to get more feedback.
> Thus here's what we are planning:
>
> - The TM project will no longer contribute its
> org.eclipse.tm.terminal.* to the simrel
>
> - Instead, the TCF project will contribute
> org.eclpse.tm.terminal.*_4.0 to the simrel (already using the *new*
> namespace).
>
> This affects the "jee" and "reporting" packages which currently
> directly use those features:
>
> org.eclipse.epp.packages/packages>grep org.eclipse.tm.terminal
> */feature.xml
> org.eclipse.epp.package.jee.feature/feature.xml: <import
> feature="org.eclipse.tm.terminal"/>
> org.eclipse.epp.package.jee.feature/feature.xml: <import
> feature="org.eclipse.tm.terminal.ssh"/>
> org.eclipse.epp.package.jee.feature/feature.xml: <import
> feature="org.eclipse.tm.terminal.telnet"/>
> org.eclipse.epp.package.jee.feature/feature.xml: <import
> feature="org.eclipse.tm.terminal.view"/>
> org.eclipse.epp.package.reporting.feature/feature.xml: <import
> feature="org.eclipse.tm.terminal"/>
> org.eclipse.epp.package.reporting.feature/feature.xml: <import
> feature="org.eclipse.tm.terminal.ssh"/>
> org.eclipse.epp.package.reporting.feature/feature.xml: <import
> feature="org.eclipse.tm.terminal.telnet"/>
> org.eclipse.epp.package.reporting.feature/feature.xml: <import
> feature="org.eclipse.tm.terminal.view"/>
>
> If you do not take any action, you will simply see the new "4.0"
> version of those features from TCF, giving you the new tabbed terminal
> view.
> If you want, you can take the following two actions as soon as TCF
> starts contributing the new namespace:
>
> - You may REMOVE "org.eclipse.tm.terminal" since that feature
> is auto-required by "org.eclipse.tm.terminal.view" ; that would allow
> updating the widget without updating the view in the future.
>
> - You may ADD "org.eclipse.tm.terminal.local" since that
> feature gives you the new local terminal (console) prompt
>
> - You may want to set the minimum version range to 4.0 to
> ensure you get the new features
>
> - You may want to review the terminal whether it fits your
> needs and provide feedback.
>
> Of course other packages are more than welcome to also consume the new
> Terminal - all relevant docs are in the marketplace entry cited above.
>
> For now this is just a heads up;
> We are planning to add the new "TM Namespace" features to the TCF
> simrel contribution over the course of the week.
> I will send another notification once the new features are available.
>
> Please let me know of any concerns or questions !
> Or comment directly on the Move Review if you want.
>
>
> Thanks,
> Martin
> --
> Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
> direct +43.662.457915.85 fax +43.662.457915.6
>
> _______________________________________________
> epp-dev mailing list
> epp-dev(a)eclipse.org
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/epp-dev
9 years, 6 months
A bit late to the party to join
by Claus Ibsen
Hi guys
Lars told me about this mailing list. Sorry I haven't spotted it earlier.
Great to see the great progress Lars and the Eclipse team have done on the "Fuse IDE" editor.
Related to this we at fabric8 work on some Fabric8 and Camel forge commands to get developers up to speed with fabric8/openshift3/camel etc.
Its still early days.
I put James on CC but as I understand down the road it would be great if these forge commands end up in for example the Data Mapper repo or some place like that.
So all of us can reuse these commands. And/or they can have a bit more Eclipse love.
From fabric8 pov we reuse these commands for web tooling, so you can create new projects / add Camel components / edit Camel endpoints etc.
Okay just wanted to share a bit info about that we are also in the tooling business.
The forge addons currently live here
https://github.com/fabric8io/fabric8/tree/master/forge/addons
I am currently working on a Camel edit endpoint command. So it disovers all the Camel endpoints in your project. And you can select one, and it has a "properties editor" where you can alter or edit the endpoint.
And the changes are saved back. For XML I can do this without changing its structure. So it keeps the <!-- --> and whatnot.
Work on Java code hasn't begun yet. But we want to try use Roaster to parse the Camel model and find the endpoints there too. A bit more tricky though.
But hopefully that can maybe be used in "Fuse IDE" - where it can maybe also "detect" endpoints in the XML editor, and allow a "cmd + XXX" or some action to show the endpoints editable in the properties panel.
Or down the road have in place editor with code completion - something a like IDEA can do.
So you type
<from uri="file:mydir?de[X]
Where [X] is the cursor. And you press cltr+ space, and it shows the options starting with "de" so you can quickly complete this as delete=. And then it knows its a boolean, so it shows you true|false as enums to choose among.
And so on.
And then it would be awesome if we can do the same in the gogs web editor for fabric8.
Okay just me rambling. Something I tend to do.
Just wanted to say hi. Time for a new cup of coffee.
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen(a)redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
9 years, 6 months
changes to transformation module in fuseide repo
by Keith Babo
I just pushed the changes for this:
https://github.com/fusesource/fuseide/issues/159 <https://github.com/fusesource/fuseide/issues/159>
Two areas of impact to note (take note of #1 for sure):
#1 - we have dropped m2e in the editor plugin project and I have added a .classpath and .project file to the source repository. This means you need to delete the existing plugin project from your workspace and then re-import it as an existing Eclipse project (not an existing Maven project). The reason for this change was to align the transformation plugin with how the other plugins in fuseide are structured.
#2 - the Fuse Data Transformation feature has been added to the Fuse IDE site and we have dropped the separate site. The transformation module now builds out of the top-level POM, which means we will build as part of fuseide proper now. It also means that we will install out of the Fuse IDE update site.
regards,
keith
9 years, 6 months
[jbosstools-fuse-dev - 4] new transformation wizard
by Keith Babo
Re: https://github.com/fusesource/fuseide/issues/151 <https://github.com/fusesource/fuseide/issues/151>
I’m thinking it would be a good idea to break our wizard up into a number of pages.
Page 1:
Provides the following inputs:
camel context path
transformation file name
transformation id
source and target type (no path to definitions though)
Finish enabled (next disabled) if transformation is Java to Java
Layout tweaked to present source type and target type dropdowns in the same row
.e.g. [Source Type] —> [Target Type]
Add “Other” as an option to the types
Page 2:
This page configures the source type. If source type is Java, this page is skipped.
Two options on this page (mutually exclusive):
If the type is XML, XSD, JSON, or JSON Schema, provide browser for file as we do today
If the type is “Other”, the user needs to provide two pieces of data:
select from a drop-down of existing data format definitions (this can be queried from the config builder)
specify the source class used for the mapping
If target type != Java, then Next is enabled and Finish is disabled. If target type == Java, reverse that.
Page 3:
This page configures the target type.
Two options on this page (mutually exclusive):
If the type is XML, XSD, JSON, or JSON Schema, provide browser for file as we do today
If the type is “Other”, the user needs to provide two pieces of data:
select from a drop-down of existing data format definitions (this can be queried from the config builder)
specify the target class used for the mapping
Finish is enabled once the target configuration is specified.
Another idea I’ve been playing around with is removing support for changing the source and target types in the editor and instead allowing the user to select the target type in the wizard. Since changing a source or target type invalidates all mappings anyway, I don’t think this is much of an inconvenience. It also makes life simpler as we won’t need to change the Camel config from within the mapper editor any longer to update source/target types. If we went ahead with this plan, then my comments above about skipping the source/target pages in the wizard would no longer apply. Instead, we would have a page where the user had a type browser where they selected the source and target type on each page.
Hopefully, this all makes sense. If no, let me know. :-)
regards,
keith
9 years, 6 months
[jbosstools-fuse-dev - 1] save from palette extension
by Keith Babo
I have pushed a datamapper-integration branch to my fork which demonstrates model updates outside of the route using a palette extension:
https://github.com/kcbabo/fuseide/tree/datamapper-integration <https://github.com/kcbabo/fuseide/tree/datamapper-integration>
There were a couple of issues, but the main culprit was that the save logic would only update routes and would ignore anything else added to the camel context via JAXB. This sort of makes sense, since the Camel editor so far has only edited routes within the camel context. I have a fix for that in my commit. It’s pretty straightforward, but I was only really paying attention to the path I cared about while testing it. I need to review the other marshal* methods in RouteXml and see if anything else needs to be updated. Expect some minor cleanup before a PR.
I have also updated our palette extension class, removing all unnecessary code and structuring it so it’s clear what needs to be added where. I’m using hard-coded data for populating the camel context merely as an example. I will look to wire this into the wizard tomorrow, which will also involve moving all of the tooling over to the Camel JAXB model and removing our own generated JAXB models.
~ keith
9 years, 6 months
