Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Can share about

(01-agenda-2.jpg)

What people tell me about why they don't use Apache Isis

Our Asciidoc based stuff

Anything to do with framework internals

...

New UI stuff upcoming in v1.15

Erik's app

Jorg's app

What people tell me about why they don't use Apache Isis

Incode Platform

  • reorg add-ons

...

    • generated reports
    • Javadoc
    • PlantUML/graphviz visualizations
    • selling (XML representation)

...

 

Image RemovedImage Removed

JEE vs Spring

...

(04-jee-vs-spring.jpg)

We voted to stay with JEE, not take an unnecessary dependency on Spring

(Dan: I recall it was said that being able to boot from within Spring Boot would be worthwhile to provide, though)

Apache Isis' Value Proposition / Marketing

(provided by Patrick Pliessnig)

Part 1: Apache Isis

Image Removed

Apache Isis' Value Proposition / Marketing

(provided by Patrick Pliessnig)

Part 1: Apache Isis market boundaries

As a follow-up on the marketing/renaming topic of IsisCon I had some thoughts, I would like to share with you. Maybe this could lead to a more in deep discussion on how to broaden the use and the community of apache isis.

My observation was that the discussion focused implicitely on talking to other IT people. But with marketing we need to define more stuff like to whom we want to talk really, on what markets we like to focus and what are the appropriate properties of apache isis for the choosen market. while marketing is necessarily an opiniated discussion, Apache Isis needs to have a sharp vision to succeed in a market. Like in software development, the market structure follows patterns. I think it is useful to know these patterns and to structure the discussion accordingly.

During the conference the discussion was principally bottom-up and reflected the view of the community. In this mail I decided to take a top-down approach to give the market side more weight.

Obviously if Apache Isis wants to succeed in a market, it needs to have the right marketable properties that give added market value to that specific market. As a consequence we need to know both 1) the marketable properties of Apache Isis and 2) the properties of the specific market that fit.

In part 1, I want to lay out some thoughts about the market properties of Apache Isis while in part 2, I want to talk more about the market itself and its patterns. Part 3 is dedicated to some thoughts about how to hook up in the market.

Apache Isis market bounderies

For me Apache Isis has many facets that make it quite difficult to categorize it correctly and therefore to sell it.

Some facets are quite easy though:

...

I hope this makes sense.... 

-- Patrick

 

Kevin's Notes

from Kevin

(Written at the conference and first posted to the private mailing list [only because the notes were incomplete])

Dear all,

Some interesting topics are being identified at the Apache Isis "IsisCon 2017". In order to try ensure that no-one is left out, I will be listing the topics and ideas, to give you the opportunity to hear what is being talked about and offer your own input.

  • How much "bleed through" annotations are acceptable?

The Apache Isis POJOs currently have many annotations that provide ?

  • Cleaning up the Framework code

On the horizon is support for JPA with the associated dependence (via DataNucleus) on Java 8. This is an opportunity to remove obsolete/deprecated methods/annotations/etc and consolidate (bump the major version number, if we still intend to honour semantic versioning).

  • What is Apache Isis's responsibility on a naked class?

The framework assumes defaults (according to a defined convention). With no additional annotations, how should the framework treat POJOs? It could, for example, assuming that all public classes are entities, and all public methods are actions. Any other desire would be communicated with additional annotations (is a service, mixin or non-entity).

  • Prototype to Production

The "bare" vs "meta annotation" vs "full fat" (production) route. When starting a new application, the developer can start with naked, non-annotated classes. They can use this quickly put together the initial application. Eventually they will want to go to full production. Apache Isis (v2) would have value-adds (like add-ons) that switch on more and more checks that perform sanity checks that require additional meta-data (annotations or XML, etc).

  • Wrap (v2)

All objects will be wrapped. There will still be an "unwrap" WrapperFactory method for when it is programmatically justifiable.(Kevin has posted some notes to private@ , I've asked him if he would be happy to move them here)

 

Jorg's "Framework Qualities"

...

Name Ideas

write-up by Dan Haywood

also documented at 

Jira
serverASF JIRA
serverId5aa69414-a9e9-3523-82ec-879b028fb15b
keyISIS-1303
 and in the table: Name ideas

At IsisCon 2017, held in Amsterdam in June, we had some great discussions about who to pitch the framework to (as well as possible inhibitors). We agreed, I think, that the pitch is to IT Managers/CTOs, who understand the needs of the business, and either know enough about technology to make the call or (probably more likely) would rely on a trusted "technical" leiutenant lieutenant to help make the call about whether to explore our framework. But we don't pitch to the techies directly. (There is a separate discussion about what to do to ensure that those technical leiutenants lieutenants don't "veto" our framework for unimportant reasons... won't address here).

...

FWIW I've listed these in my (Dan's) own preference order

 

Attendees

(Should this list be private for any reason?)

  1. Dan Haywood
  2. Jeroen van der Wal
  3. Jörg Rade
  4. Kevin Meyer
  5. Patrick Pliessnig
  6. Óscar Bou
  7. Marc Alvares
  8. Hessel Bakker
  9. Rosco Kalis
  10. Johan Doornenbal
  11. Jonathan Doornenbal
  12. Erik de Hair
  13. Sebastian Slutzky
  14. Bilgin Ibryam
  15. Jan-Willem Meyling