Re: CM Thoughts
This is why I said Oracle seemed like they weren't really committed to JavaFX (or at least not Scene Builder, which I view as a desirable development product). They used to support/release Scene Builder, but now appear to have stopped. Perhaps the Gluon people will do a great job, but it still makes me question Oracle's commitment and the long-term viability of the technology. On Mon, Jan 11, 2016 at 9:01 PM, Aristedes Maniatis wrote: > On 12/01/2016 12:43pm, Michael Gentry wrote: > > On Mon, Jan 11, 2016 at 6:53 PM, Aristedes Maniatis > > wrote: > > > >> On 12/01/2016 12:41am, Michael Gentry wrote: > >>> Last time I glanced at JFX, Oracle required you to build some of the > >>> developer tools (at least Scene Builder) yourself instead of supplying > >>> packages you could download/use. > >> > >> > >> > http://www.oracle.com/technetwork/java/javase/downloads/javafxscenebuilder-info-2157684.html > > > > > > > > > > And when you click on the download link: > > > > WARNING: These versions of JavaFX Scene Builder may include components > that > > do not contain the latest security patches and are not recommended for > use > > in production. > > Oracle are insane. But this might help: > http://gluonhq.com/open-source/scene-builder/ > > Maybe they are expecting each IDE will implement SceneBuilder-like > functionality. Or maybe Oracle are just insane. > > Ari > > > -- > --> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >
Re: CM Thoughts
On 12/01/2016 12:43pm, Michael Gentry wrote: > On Mon, Jan 11, 2016 at 6:53 PM, Aristedes Maniatis > wrote: > >> On 12/01/2016 12:41am, Michael Gentry wrote: >>> Last time I glanced at JFX, Oracle required you to build some of the >>> developer tools (at least Scene Builder) yourself instead of supplying >>> packages you could download/use. >> >> >> http://www.oracle.com/technetwork/java/javase/downloads/javafxscenebuilder-info-2157684.html > > > > > And when you click on the download link: > > WARNING: These versions of JavaFX Scene Builder may include components that > do not contain the latest security patches and are not recommended for use > in production. Oracle are insane. But this might help: http://gluonhq.com/open-source/scene-builder/ Maybe they are expecting each IDE will implement SceneBuilder-like functionality. Or maybe Oracle are just insane. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: CM Thoughts
On Mon, Jan 11, 2016 at 6:53 PM, Aristedes Maniatis wrote: > On 12/01/2016 12:41am, Michael Gentry wrote: > > Last time I glanced at JFX, Oracle required you to build some of the > > developer tools (at least Scene Builder) yourself instead of supplying > > packages you could download/use. > > > http://www.oracle.com/technetwork/java/javase/downloads/javafxscenebuilder-info-2157684.html And when you click on the download link: WARNING: These versions of JavaFX Scene Builder may include components that do not contain the latest security patches and are not recommended for use in production.
Re: CM Thoughts
On 12/01/2016 2:23am, Hugi Thordarson wrote: > EOF’s Entity Modeler is also provided as a standalone application. That seems > like a winning situation, where the modeler can be run either within the > Eclipse environment or as an app. Not saying that SWT is dying, but it doesn't seem to be growing. In what I've seen, it is similar to Swing: a legacy framework which works really well but isn't the focus of much new attention. JavaFX is really where all the new work is going, both from Oracle and from third party developers with plugins. For example, here are the best-of-class proprietary calendar widgets: Swing: http://migcalendar.com/ (solid, but no updates in over 3 years) JavaFX: http://www.calendarfx.com/ (actively developed) And for example, here is an open source control set: http://fxexperience.com/controlsfx/features/ On 12/01/2016 12:41am, Michael Gentry wrote: > Last time I glanced at JFX, Oracle required you to build some of the > developer tools (at least Scene Builder) yourself instead of supplying > packages you could download/use. http://www.oracle.com/technetwork/java/javase/downloads/javafxscenebuilder-info-2157684.html Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: CM Thoughts
And yeah, a quick google search shows that's about all there is to it http://stackoverflow.com/questions/1809401/packaging-one-or-two-plugins-as-a-standalone-rcp-application On Mon, Jan 11, 2016 at 10:58 AM, Mike Kienenberger wrote: > On Mon, Jan 11, 2016 at 10:49 AM, Mike Kienenberger > wrote: >> ... I'm fairly certain that you can write code that would be >> mostly interchangeable between a standalone app and a plugin. >> However, I haven't done any specific plug-in work to the traditional >> eclipse IDE, but the architecture is identical, and I would imagine >> it's possible. > > I guess I should probably say it's not only possible, but it's > probably easy. A quick review of my code shows that I primarily just > provided sets of actions, perspectives, and views to the eclipse > workbench API. I imagine that'e exactly the same thing that a plug-in > would do. A standalone app based on a plug-in would likely just > provide the startup glue code, set the default perspective to the > plugin perspective, create a menu, etc. > > Again, though, this is all based on work I did five years ago, so take > it with a grain of salt.
Re: CM Thoughts
On Mon, Jan 11, 2016 at 10:49 AM, Mike Kienenberger wrote: > ... I'm fairly certain that you can write code that would be > mostly interchangeable between a standalone app and a plugin. > However, I haven't done any specific plug-in work to the traditional > eclipse IDE, but the architecture is identical, and I would imagine > it's possible. I guess I should probably say it's not only possible, but it's probably easy. A quick review of my code shows that I primarily just provided sets of actions, perspectives, and views to the eclipse workbench API. I imagine that'e exactly the same thing that a plug-in would do. A standalone app based on a plug-in would likely just provide the startup glue code, set the default perspective to the plugin perspective, create a menu, etc. Again, though, this is all based on work I did five years ago, so take it with a grain of salt.
Re: CM Thoughts
I spent a couple of years (2010-2011) writing my own standalone editor using the eclipse platform and SWT. Many of the details are now foggy, but I'm fairly certain that you can write code that would be mostly interchangeable between a standalone app and a plugin. However, I haven't done any specific plug-in work to the traditional eclipse IDE, but the architecture is identical, and I would imagine it's possible. I didn't hate it (most of the time) and I didn't love it (most of the time), but I probably was able to get 95% of what I wanted done, although it had a high learning curve. I don't think the extra pain is worth the small gain it would get you though. If you can run eclipse on your machine, then you can always run "java -jar bin/modeler.jar" easily enough. But then I build all of my generated classes using ant tasks rather than trying to do it from the modeler directly, so I'm probably not a typical user. On Mon, Jan 11, 2016 at 10:30 AM, Hugi Thordarson wrote: > Unfortunately I haven’t done any SWT/Eclipse development at all. If someone > knows Mike Schrag (the original creator of the Entity Modeler) he might have > some insights into whether it’s a sensible path? > > >> On 11. jan. 2016, at 15:27, Michael Gentry wrote: >> >> I was wondering if SWT made it easy/easier to do that. >> >> On Mon, Jan 11, 2016 at 10:23 AM, Hugi Thordarson wrote: >> >>> EOF’s Entity Modeler is also provided as a standalone application. That >>> seems like a winning situation, where the modeler can be run either within >>> the Eclipse environment or as an app. >>> >>> - hugi >>> >>> >>> On 11. jan. 2016, at 13:50, Michael Gentry >>> wrote: Well, using SWT doesn't mean it has to be an Eclipse plugin -- it can be like Apache Directory Studio, which is a standalone application. On Thu, Jan 7, 2016 at 10:02 AM, Gmail wrote: > One problem with moving to an eclipse platform/plugin is that it adds > another barrier to adoption by devs who don't use Eclipse. We have a >>> lot of > IntelliJ IDEA users here. > > Tony Giaccone > >> On Jan 5, 2016, at 7:58 AM, Michael Gentry > wrote: >> >> Hi, >> >> I'd like to start a conversation about future improvements for CM. >> >> My current wish list: >> >> - Java Entities >> - Class Level: >> - Ability to add extra imports. >> - Ability to add interfaces implemented. >> - Ability to add JavaDoc. >> - Ability to add annotations. >> - Attribute Level: >> - Ability to add JavaDoc. >> - Ability to add annotations. >> - Relationship Level: >> - Ability to add JavaDoc. >> - Ability to add annotations. >> - Ability to drill-down through relationships.* >> - DB Entities >> - Table Level: >> - Ability to add comments (for DBs that support comments). >> - Column Level: >> - Ability to add comments (for DBs that support comments). >> - Relationship Level: >> - Ability to add comments (for DBs that support comments). >> - Ability to drill-down through relationships.* >> >> * Llike EOModeler, in the left-hand navigation pane. You could keep >> expanding the relationship tree to expose other entities/relationships. >> >> >> We've also previously chatted a bit about if we even want to keep >> maintaining the current form of CM. If we did want to overhaul the >> implementation, what route should we go? >> >> - JFX (Seems like Oracle's ugly stepchild and I question their > commitment >> to it.) >> - SWT >> - Eclipse Plugin (The WOLips route.) >> - Electron (Used by Atom and Visual Studio Code, among others.) >> >> >> Your thoughts greatly appreciated! >> >> >> Thanks, >> >> mrg > >>> >>> >
Re: CM Thoughts
Unfortunately I haven’t done any SWT/Eclipse development at all. If someone knows Mike Schrag (the original creator of the Entity Modeler) he might have some insights into whether it’s a sensible path? > On 11. jan. 2016, at 15:27, Michael Gentry wrote: > > I was wondering if SWT made it easy/easier to do that. > > On Mon, Jan 11, 2016 at 10:23 AM, Hugi Thordarson wrote: > >> EOF’s Entity Modeler is also provided as a standalone application. That >> seems like a winning situation, where the modeler can be run either within >> the Eclipse environment or as an app. >> >> - hugi >> >> >> >>> On 11. jan. 2016, at 13:50, Michael Gentry >> wrote: >>> >>> Well, using SWT doesn't mean it has to be an Eclipse plugin -- it can be >>> like Apache Directory Studio, which is a standalone application. >>> >>> >>> On Thu, Jan 7, 2016 at 10:02 AM, Gmail wrote: >>> One problem with moving to an eclipse platform/plugin is that it adds another barrier to adoption by devs who don't use Eclipse. We have a >> lot of IntelliJ IDEA users here. Tony Giaccone > On Jan 5, 2016, at 7:58 AM, Michael Gentry wrote: > > Hi, > > I'd like to start a conversation about future improvements for CM. > > My current wish list: > > - Java Entities > - Class Level: > - Ability to add extra imports. > - Ability to add interfaces implemented. > - Ability to add JavaDoc. > - Ability to add annotations. > - Attribute Level: > - Ability to add JavaDoc. > - Ability to add annotations. > - Relationship Level: > - Ability to add JavaDoc. > - Ability to add annotations. > - Ability to drill-down through relationships.* > - DB Entities > - Table Level: > - Ability to add comments (for DBs that support comments). > - Column Level: > - Ability to add comments (for DBs that support comments). > - Relationship Level: > - Ability to add comments (for DBs that support comments). > - Ability to drill-down through relationships.* > > * Llike EOModeler, in the left-hand navigation pane. You could keep > expanding the relationship tree to expose other entities/relationships. > > > We've also previously chatted a bit about if we even want to keep > maintaining the current form of CM. If we did want to overhaul the > implementation, what route should we go? > > - JFX (Seems like Oracle's ugly stepchild and I question their commitment > to it.) > - SWT > - Eclipse Plugin (The WOLips route.) > - Electron (Used by Atom and Visual Studio Code, among others.) > > > Your thoughts greatly appreciated! > > > Thanks, > > mrg >> >> smime.p7s Description: S/MIME cryptographic signature
Re: CM Thoughts
I was wondering if SWT made it easy/easier to do that. On Mon, Jan 11, 2016 at 10:23 AM, Hugi Thordarson wrote: > EOF’s Entity Modeler is also provided as a standalone application. That > seems like a winning situation, where the modeler can be run either within > the Eclipse environment or as an app. > > - hugi > > > > > On 11. jan. 2016, at 13:50, Michael Gentry > wrote: > > > > Well, using SWT doesn't mean it has to be an Eclipse plugin -- it can be > > like Apache Directory Studio, which is a standalone application. > > > > > > On Thu, Jan 7, 2016 at 10:02 AM, Gmail wrote: > > > >> One problem with moving to an eclipse platform/plugin is that it adds > >> another barrier to adoption by devs who don't use Eclipse. We have a > lot of > >> IntelliJ IDEA users here. > >> > >> Tony Giaccone > >> > >>> On Jan 5, 2016, at 7:58 AM, Michael Gentry > >> wrote: > >>> > >>> Hi, > >>> > >>> I'd like to start a conversation about future improvements for CM. > >>> > >>> My current wish list: > >>> > >>> - Java Entities > >>> - Class Level: > >>> - Ability to add extra imports. > >>> - Ability to add interfaces implemented. > >>> - Ability to add JavaDoc. > >>> - Ability to add annotations. > >>> - Attribute Level: > >>> - Ability to add JavaDoc. > >>> - Ability to add annotations. > >>> - Relationship Level: > >>> - Ability to add JavaDoc. > >>> - Ability to add annotations. > >>> - Ability to drill-down through relationships.* > >>> - DB Entities > >>> - Table Level: > >>> - Ability to add comments (for DBs that support comments). > >>> - Column Level: > >>> - Ability to add comments (for DBs that support comments). > >>> - Relationship Level: > >>> - Ability to add comments (for DBs that support comments). > >>> - Ability to drill-down through relationships.* > >>> > >>> * Llike EOModeler, in the left-hand navigation pane. You could keep > >>> expanding the relationship tree to expose other entities/relationships. > >>> > >>> > >>> We've also previously chatted a bit about if we even want to keep > >>> maintaining the current form of CM. If we did want to overhaul the > >>> implementation, what route should we go? > >>> > >>> - JFX (Seems like Oracle's ugly stepchild and I question their > >> commitment > >>> to it.) > >>> - SWT > >>> - Eclipse Plugin (The WOLips route.) > >>> - Electron (Used by Atom and Visual Studio Code, among others.) > >>> > >>> > >>> Your thoughts greatly appreciated! > >>> > >>> > >>> Thanks, > >>> > >>> mrg > >> > >
Re: CM Thoughts
EOF’s Entity Modeler is also provided as a standalone application. That seems like a winning situation, where the modeler can be run either within the Eclipse environment or as an app. - hugi > On 11. jan. 2016, at 13:50, Michael Gentry wrote: > > Well, using SWT doesn't mean it has to be an Eclipse plugin -- it can be > like Apache Directory Studio, which is a standalone application. > > > On Thu, Jan 7, 2016 at 10:02 AM, Gmail wrote: > >> One problem with moving to an eclipse platform/plugin is that it adds >> another barrier to adoption by devs who don't use Eclipse. We have a lot of >> IntelliJ IDEA users here. >> >> Tony Giaccone >> >>> On Jan 5, 2016, at 7:58 AM, Michael Gentry >> wrote: >>> >>> Hi, >>> >>> I'd like to start a conversation about future improvements for CM. >>> >>> My current wish list: >>> >>> - Java Entities >>> - Class Level: >>> - Ability to add extra imports. >>> - Ability to add interfaces implemented. >>> - Ability to add JavaDoc. >>> - Ability to add annotations. >>> - Attribute Level: >>> - Ability to add JavaDoc. >>> - Ability to add annotations. >>> - Relationship Level: >>> - Ability to add JavaDoc. >>> - Ability to add annotations. >>> - Ability to drill-down through relationships.* >>> - DB Entities >>> - Table Level: >>> - Ability to add comments (for DBs that support comments). >>> - Column Level: >>> - Ability to add comments (for DBs that support comments). >>> - Relationship Level: >>> - Ability to add comments (for DBs that support comments). >>> - Ability to drill-down through relationships.* >>> >>> * Llike EOModeler, in the left-hand navigation pane. You could keep >>> expanding the relationship tree to expose other entities/relationships. >>> >>> >>> We've also previously chatted a bit about if we even want to keep >>> maintaining the current form of CM. If we did want to overhaul the >>> implementation, what route should we go? >>> >>> - JFX (Seems like Oracle's ugly stepchild and I question their >> commitment >>> to it.) >>> - SWT >>> - Eclipse Plugin (The WOLips route.) >>> - Electron (Used by Atom and Visual Studio Code, among others.) >>> >>> >>> Your thoughts greatly appreciated! >>> >>> >>> Thanks, >>> >>> mrg >> smime.p7s Description: S/MIME cryptographic signature
Re: CM Thoughts
Well, using SWT doesn't mean it has to be an Eclipse plugin -- it can be like Apache Directory Studio, which is a standalone application. On Thu, Jan 7, 2016 at 10:02 AM, Gmail wrote: > One problem with moving to an eclipse platform/plugin is that it adds > another barrier to adoption by devs who don't use Eclipse. We have a lot of > IntelliJ IDEA users here. > > Tony Giaccone > > > On Jan 5, 2016, at 7:58 AM, Michael Gentry > wrote: > > > > Hi, > > > > I'd like to start a conversation about future improvements for CM. > > > > My current wish list: > > > > - Java Entities > >- Class Level: > >- Ability to add extra imports. > >- Ability to add interfaces implemented. > >- Ability to add JavaDoc. > >- Ability to add annotations. > >- Attribute Level: > >- Ability to add JavaDoc. > >- Ability to add annotations. > >- Relationship Level: > >- Ability to add JavaDoc. > >- Ability to add annotations. > >- Ability to drill-down through relationships.* > > - DB Entities > >- Table Level: > >- Ability to add comments (for DBs that support comments). > >- Column Level: > >- Ability to add comments (for DBs that support comments). > >- Relationship Level: > >- Ability to add comments (for DBs that support comments). > >- Ability to drill-down through relationships.* > > > > * Llike EOModeler, in the left-hand navigation pane. You could keep > > expanding the relationship tree to expose other entities/relationships. > > > > > > We've also previously chatted a bit about if we even want to keep > > maintaining the current form of CM. If we did want to overhaul the > > implementation, what route should we go? > > > > - JFX (Seems like Oracle's ugly stepchild and I question their > commitment > > to it.) > > - SWT > > - Eclipse Plugin (The WOLips route.) > > - Electron (Used by Atom and Visual Studio Code, among others.) > > > > > > Your thoughts greatly appreciated! > > > > > > Thanks, > > > > mrg >
Re: CM Thoughts
I've thought a bit about creating a Tapestry/Web version of CM in the past and it always seemed like it would be just a bit too cumbersome to launch/secure. I'm not sure if a JFX/JS version would be any simpler or if it would even have value over a straight Electron version. On Tue, Jan 5, 2016 at 5:57 PM, Mike Kienenberger wrote: > On Tue, Jan 5, 2016 at 5:34 PM, Aristedes Maniatis > wrote: > > > To my mind, there is only a small gain in moving away from Swing and > quite a bit of work. But if you had the time to put into it, JavaFX is most > likely to survive another 15 years from the options you give above. > > It appears that JavaFx is also usable from javascript, which might be > another reason to use it -- maybe the modeler could run on a web page. > No idea if that is really practical though as I have never tried > anything like that. > > > https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/javafx.html >
Re: CM Thoughts
On Tue, Jan 5, 2016 at 5:34 PM, Aristedes Maniatis wrote: > On 5/01/2016 11:58pm, Michael Gentry wrote: > > - Java Entities > > - Class Level: > > - Ability to add extra imports. > > This seems like something that should go into the velocity templates > rather than the model. > Well, if we are going to support annotations in the modeler (class, attribute, or relationship), it would be much nicer, at least in my opinion, to specify the imports for the annotation in the modeler instead of having to go off and create a custom template whose information is essentially hidden from the CM viewer/user. > > - Ability to add interfaces implemented. > > What would be the purpose of adding an interface to the _superclass when > you need to implement the methods in the subclass? > Mainly organizational (keeping everything grouped together). This isn't a big one, though. > > We've also previously chatted a bit about if we even want to keep > > maintaining the current form of CM. If we did want to overhaul the > > implementation, what route should we go? > > > > - JFX (Seems like Oracle's ugly stepchild and I question their > commitment > > to it.) > > I wouldn't judge it so harshly. I'm slowly moving a project from Swing to > FX and there seems to be a good amount of support and new functionality > added in each Java release. Plus it doesn't have to be an all at once > migration. > Last time I glanced at JFX, Oracle required you to build some of the developer tools (at least Scene Builder) yourself instead of supplying packages you could download/use. This screamed of a solid "meh" to me, at best. Perhaps this has changed, though. I admit to not having put a lot of effort into it, but a couple years ago when I played with JFX/SB a bit more seriously, it seemed interesting. The Oracle site still says: *JavaFX Scene Builder is released under the Oracle BSD License. The source code is provided and developed through the OpenJFX Project in the OpenJDK Community. Please consult the OpenJFX Wiki for instructions describing how to download and build its source code. Please note that the source code for this application can be found in the "apps/scenebuilder" directory.* > - SWT > > I have no opinion there, but I didn't think that was a framework still in > active development. > > > - Eclipse Plugin (The WOLips route.) > > JasperStudio went the same way and it seems to work for them. And I think > Apache Directory Studio might also be an Eclipse plugin. Being bound to > someone else's application does seem potentially dangerous (does the plugin > break with every major release of Eclipse?). Does it increase the > difficulty of new people hacking at the code... I think that should be our > number one criteria: what's the easiest environment for new people to get > involved? > I think Apache Directory Studio uses SWT. It looks Eclipsish, but is a standalone application. > - Electron (Used by Atom and Visual Studio Code, among others.) > > Never played with it. > To even realistically consider Electron, this would have to work well in order to interface to Cayenne JARs: https://github.com/joeferner/node-java Nutshell: Electron gives you a way to create platform-specific applications (like we currently have separate builds for OS X and Windows) running inside a Chrome shell with Node/JS and you write your application with HTML/CSS/JS. It seems to be gaining popularity with some "younger" developers. The main reason to even consider a CM rewrite is to upgrade it to more modern UI frameworks and make it more approachable, both from usability and developer viewpoints. Everything else I mentioned can be done in the current Swing version, but probably some of it would be quite difficult/cumbersome. Thanks again, mrg
Re: CM Thoughts
> On Jan 8, 2016, at 2:49 AM, Aristedes Maniatis wrote: > > On 8/01/2016 4:40am, Andrus Adamchik wrote: >> The argument in favor of a fresh UI toolkit is that our Swing app feels >> stale, and this becomes a serious mental barrier to adoption. I have no idea >> how much JavaFX would help to modernize it, but overall it seems like a >> logic *upgrade* path. > > Perhaps just replacing all the icons with new ones (from one of the many good > libraries), and adding @2x versions (Retina) of those icons would go about > 80% of the way to making it feel modern. > > How do you like: > >http://fortawesome.github.io/Font-Awesome/ This will be a good start I guess. Another thing is bevels and general look of controls. Is that something that is easy to customize in JavaFX with CSS? > >> Next I'd like to see the modeling process to be less tedious, with the tool >> better hiding modeling complexities. Currently we are attacking that >> indirectly by doing an end run around manual modeling [1] by beefing up >> reverse engineering. > > Can you quantify which bits are tedious? To be honest, its been ages since > I've created a large model from scratch. Attributes and relationships presentation and mapping. To many clicks, not enough information in the main table (and trying to add extra columns using current Swing toolkit makes it too overloaded). ObjRelationship path mapping is the most unintuitive part of it. (This is being addressed per [1], which allows to do path mapping straight from the dropdown). As others have mentioned, combining Obj and Db views should also help. So we need some UX rework. Andrus [1] https://github.com/apache/cayenne/pull/77
Re: CM Thoughts
On 8/01/2016 4:40am, Andrus Adamchik wrote: > The argument in favor of a fresh UI toolkit is that our Swing app feels > stale, and this becomes a serious mental barrier to adoption. I have no idea > how much JavaFX would help to modernize it, but overall it seems like a logic > *upgrade* path. Perhaps just replacing all the icons with new ones (from one of the many good libraries), and adding @2x versions (Retina) of those icons would go about 80% of the way to making it feel modern. How do you like: http://fortawesome.github.io/Font-Awesome/ The license is SIL and in category B http://www.apache.org/legal/resolved.html#category-b If everyone is happy with that I'll go and pick out a set of icons for the major features. > Next I'd like to see the modeling process to be less tedious, with the tool > better hiding modeling complexities. Currently we are attacking that > indirectly by doing an end run around manual modeling [1] by beefing up > reverse engineering. Can you quantify which bits are tedious? To be honest, its been ages since I've created a large model from scratch. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: CM Thoughts
On Tue, Jan 5, 2016 at 4:35 PM Aristedes Maniatis wrote: > On 5/01/2016 11:58pm, Michael Gentry wrote: > > Hi, > > > > I'd like to start a conversation about future improvements for CM. > > Cool! > > > > My current wish list: > > > > - Java Entities > > - Class Level: > > - Ability to add extra imports. > > This seems like something that should go into the velocity templates > rather than the model. > > > - Ability to add interfaces implemented. > > What would be the purpose of adding an interface to the _superclass when > you need to implement the methods in the subclass? > > > - Ability to add JavaDoc. > > https://issues.apache.org/jira/browse/CAY-400 is the beginning of this > concept. I put some time into it ages ago. And then I used it as a test > when hiring a couple of new developers. Bad sadly I never went back to tidy > it all up and get it finished. > > > > - Ability to add annotations. > > Yes, that would be cool. > > > > - Attribute Level: > > - Ability to add JavaDoc. > > - Ability to add annotations. > > - Relationship Level: > > - Ability to add JavaDoc. > > - Ability to add annotations. > > - Ability to drill-down through relationships.* > > That would be really useful. > > > > - DB Entities > > - Table Level: > > - Ability to add comments (for DBs that support comments). > > - Column Level: > > - Ability to add comments (for DBs that support comments). > > - Relationship Level: > > - Ability to add comments (for DBs that support comments). > > I think that's https://issues.apache.org/jira/browse/CAY-400 again. > > > > - Ability to drill-down through relationships.* > > > > * Llike EOModeler, in the left-hand navigation pane. You could keep > > expanding the relationship tree to expose other entities/relationships. > > > > > > We've also previously chatted a bit about if we even want to keep > > maintaining the current form of CM. If we did want to overhaul the > > implementation, what route should we go? > Unless someone is committing to do all the work I doubt this is really feasible. But it's ok to dream. What is there to gain in switching platforms? > > > > - JFX (Seems like Oracle's ugly stepchild and I question their > commitment > > to it.) > > I wouldn't judge it so harshly. I'm slowly moving a project from Swing to > FX and there seems to be a good amount of support and new functionality > added in each Java release. Plus it doesn't have to be an all at once > migration. > I don't think JavaFX is going to disappear, but it's not gaining popularity or usage either. But the fact that it integrates with swing makes it possible migrate slowly, which is a big benefit. Still, what is to gain? > > > - SWT > > I have no opinion there, but I didn't think that was a framework still in > active development. > SWT is the UI framework that powers eclipse. It gives you platform-native widgets, so the appearance and interaction is top-notch and feels native. SWT isn't widely used outside eclipse, but it is very much alive. Also there is a web-based version of the same API that can be used to turn your java app into a native-web app; however, this is even less widely used. > > - Eclipse Plugin (The WOLips route.) > > JasperStudio went the same way and it seems to work for them. And I think > Apache Directory Studio might also be an Eclipse plugin. Being bound to > someone else's application does seem potentially dangerous (does the plugin > break with every major release of Eclipse?). Does it increase the > difficulty of new people hacking at the code... I think that should be our > number one criteria: what's the easiest environment for new people to get > involved? > This is similar to SWT, but with more on top. Since there is already a prototype of CayenneModeler in eclipse this would be a realistic path. But are there gains that are worth it? > > > > - Electron (Used by Atom and Visual Studio Code, among others.) > > Never played with it. > Electron is the shell for the Chrome web browser. It allows you to package a web app as a native application (like Chrome). It allows you to develop your app using web technologies (HTML/CSS/Javascript) which could be very productive. But I'm not convinced that's a plus even though I like the platform. > > > Your thoughts greatly appreciated! > > To my mind, there is only a small gain in moving away from Swing and quite > a bit of work. But if you had the time to put into it, JavaFX is most > likely to survive another 15 years from the options you give above. > > > Ari > > > > -- > --> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >
Re: CM Thoughts
On Tue, Jan 5, 2016 at 5:34 PM, Aristedes Maniatis wrote: > To my mind, there is only a small gain in moving away from Swing and quite a > bit of work. But if you had the time to put into it, JavaFX is most likely to > survive another 15 years from the options you give above. It appears that JavaFx is also usable from javascript, which might be another reason to use it -- maybe the modeler could run on a web page. No idea if that is really practical though as I have never tried anything like that. https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/javafx.html
Re: CM Thoughts
On 5/01/2016 11:58pm, Michael Gentry wrote: > Hi, > > I'd like to start a conversation about future improvements for CM. Cool! > My current wish list: > > - Java Entities > - Class Level: > - Ability to add extra imports. This seems like something that should go into the velocity templates rather than the model. > - Ability to add interfaces implemented. What would be the purpose of adding an interface to the _superclass when you need to implement the methods in the subclass? > - Ability to add JavaDoc. https://issues.apache.org/jira/browse/CAY-400 is the beginning of this concept. I put some time into it ages ago. And then I used it as a test when hiring a couple of new developers. Bad sadly I never went back to tidy it all up and get it finished. > - Ability to add annotations. Yes, that would be cool. > - Attribute Level: > - Ability to add JavaDoc. > - Ability to add annotations. > - Relationship Level: > - Ability to add JavaDoc. > - Ability to add annotations. > - Ability to drill-down through relationships.* That would be really useful. > - DB Entities > - Table Level: > - Ability to add comments (for DBs that support comments). > - Column Level: > - Ability to add comments (for DBs that support comments). > - Relationship Level: > - Ability to add comments (for DBs that support comments). I think that's https://issues.apache.org/jira/browse/CAY-400 again. > - Ability to drill-down through relationships.* > > * Llike EOModeler, in the left-hand navigation pane. You could keep > expanding the relationship tree to expose other entities/relationships. > > > We've also previously chatted a bit about if we even want to keep > maintaining the current form of CM. If we did want to overhaul the > implementation, what route should we go? > > - JFX (Seems like Oracle's ugly stepchild and I question their commitment > to it.) I wouldn't judge it so harshly. I'm slowly moving a project from Swing to FX and there seems to be a good amount of support and new functionality added in each Java release. Plus it doesn't have to be an all at once migration. > - SWT I have no opinion there, but I didn't think that was a framework still in active development. > - Eclipse Plugin (The WOLips route.) JasperStudio went the same way and it seems to work for them. And I think Apache Directory Studio might also be an Eclipse plugin. Being bound to someone else's application does seem potentially dangerous (does the plugin break with every major release of Eclipse?). Does it increase the difficulty of new people hacking at the code... I think that should be our number one criteria: what's the easiest environment for new people to get involved? > - Electron (Used by Atom and Visual Studio Code, among others.) Never played with it. > Your thoughts greatly appreciated! To my mind, there is only a small gain in moving away from Swing and quite a bit of work. But if you had the time to put into it, JavaFX is most likely to survive another 15 years from the options you give above. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: CM Thoughts
I'll add another one I forgot about! :-) Possibly merge the ObjEntity and DbEntity in the left-hand navigation pane. I'm not exactly sure what it would look like, but I know EOModeler and WOLips have a combined navigation pane: http://cdn-ak.f.st-hatena.com/images/fotolife/m/mig50/20060731/20060731010550.png On Tue, Jan 5, 2016 at 7:58 AM, Michael Gentry wrote: > Hi, > > I'd like to start a conversation about future improvements for CM. > > My current wish list: > > - Java Entities > - Class Level: > - Ability to add extra imports. > - Ability to add interfaces implemented. > - Ability to add JavaDoc. > - Ability to add annotations. > - Attribute Level: > - Ability to add JavaDoc. > - Ability to add annotations. > - Relationship Level: > - Ability to add JavaDoc. > - Ability to add annotations. > - Ability to drill-down through relationships.* > - DB Entities > - Table Level: > - Ability to add comments (for DBs that support comments). > - Column Level: > - Ability to add comments (for DBs that support comments). > - Relationship Level: > - Ability to add comments (for DBs that support comments). > - Ability to drill-down through relationships.* > > * Llike EOModeler, in the left-hand navigation pane. You could keep > expanding the relationship tree to expose other entities/relationships. > > > We've also previously chatted a bit about if we even want to keep > maintaining the current form of CM. If we did want to overhaul the > implementation, what route should we go? > > - JFX (Seems like Oracle's ugly stepchild and I question their commitment > to it.) > - SWT > - Eclipse Plugin (The WOLips route.) > - Electron (Used by Atom and Visual Studio Code, among others.) > > > Your thoughts greatly appreciated! > > > Thanks, > > mrg > >
