[jira] [Commented] (ISIS-993) Show different object members on multiple tabs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131890#comment-15131890
 ] 

ASF subversion and git services commented on ISIS-993:
--

Commit 20faf33a050b10e0085b01cc027d6d0ef6dd4386 in isis's branch 
refs/heads/ISIS-993 from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=20faf33 ]

ISIS-993: Now allow unreferenced collections to be associated with columns.  
Also sorting out hints for collection selection under tabs.


> Show different object members on multiple tabs
> --
>
> Key: ISIS-993
> URL: https://issues.apache.org/jira/browse/ISIS-993
> Project: Isis
>  Issue Type: New Feature
>  Components: Core, Core: Viewer: Wicket
>Affects Versions: viewer-wicket-1.7.0
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.12.0
>
>
> 4-jan-2016:
> Divide the screen into two halves.
> All properties in separate tabs.
> Each collection in its own tabs.
> ~~~
> as per [1] mailing list thread.
> The example in the mailng list splits up the object's properties/collections 
> (contributed or otherwise) into two different sets of tabs... but as a first 
> pass I think a single row of tabs ought to suffice.
> We also need to be mindful that we may want to use tabs as a metaphor for 
> multiple opened objects (as a replacement for bookmarks), so this is another 
> reason for a single row of tabs. 
> To support this would require extensions to @DomainObjectLayout or equivalent 
> xxx.layout.json file.
> [1] http://markmail.org/message/merftvqoiy6ht3kq



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[Vladimir Nisevic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131823#comment-15131823
 ] 

Vladimir Nisevic commented on ISIS-1303:


Hello, last time I'm showing the prototypes based on Isis, so I need often to 
explain what is the framework behind and the things it stands for: DDD, NO, 
hexagonal architecture, invest/focus on business domain and not infrastructure. 
And yes, lot of other frameworks have some of that arguments as well - 
especially "idea to focus on your business problems and less boilerplate and/or 
infrastructure code".
 
But when I step back and look onto it, as the main usp of Isis that I see, is 
the possibility to establish a totally new way of tight collaboration with 
customer/requester. I use a kind of process as described by Eric Evans [1] 
combined with the NO principle - expose current business model in UI within 
minutes/hours and get the customer on board. This feature boosts me into 
fastest lane of model exploration ever and this is what brings me very fast to 
point where we discuss  about "do we the right things". There is also a famous 
quote by Peter Drucker [2]. 

So I suggest not to promote Isis as a yet another framework for building 
"faster, cheaper" (doing the things right) but more as a tool/process for 
"doing the right things".

Second thing is the idea behind "problem solver vs. process follower" (there 
was a great video from Richard Pawson on Vimeo I believe, unfortunately I can't 
find any more). 
Building the software thru investment in a company is always associated to the 
value it should brings, so extrapolating the business case is the part of the 
game, and the root of business case is often a kind of automation or current 
business steps/processes. Therefore lot of projects we invest into have as a 
goal a kind of "automation of business processes" and often bring as a solution 
"yet another process following system". 

The power of "problem solving tool" could be also something as a core feature 
what Isis stands for as a kind "problem solving framework"...

Therefore I believe that at least one of those two core values I see, should be 
somehow embedded/recognizable in the name.


1] http://domainlanguage.com/ddd/whirlpool/ 

[2] 
http://www.ukessays.com/essays/business/management-is-doing-things-right-leadership-is-doing-the-right-things-business-essay.php



> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the 

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Cesar Lugo (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130587#comment-15130587
 ] 

Cesar Lugo edited comment on ISIS-1303 at 2/3/16 9:57 PM:
--

Hello. I agree that, from a marketing perspective, this is a very good 
initiative, Despite how elegant Isis might sound, the other Isis is making too 
much noise to you, and you need to be heard. I have been involved in a few 
professional marketing processes when marketing some of our products to US, 
Europe and Latin America, and the marketing experts pointed out more or less 
the following (in my own words, sorry about that):

The name must be memorable (easy to remember).
The name should quite simply represent the main properties (not features) of 
your product  (no explanations needed, almost obvious) . The properties are the 
ones in the minds of your potential customers and actual customers.
They also suggested we considered names coming from Latin roots. This helps 
when addressing non-English spoken people, mostly likely it will be the same or 
very similar word in many languages, at least Latin root languages.

That said, let me share with you which ones I think might be your main 
competitors, direct or indirect, and their main property in my mind:
- Spring Framework. (Comprehensive, de facto standard to many, mature / old?)
- Spring Framework. (ups!)
- Grails. (Fast)
- OpenXava. (Faster)
- Vaadin. (Elegant, Beautiful UI, for the Java-only guys)
- Play. (Fast?)
- Django?. (Yes Python, still a competitor,  almost a de facto standard)
- RoR? (Ruby on Rails) (Yes Ruby, still a competitor, de facto standard)
- Cubicweb?. (Python, fast, semantic)

Now, let me share with you the ones I think are the properties that really make 
a difference in your Framework, at least in my mind, and in the ones I could 
infer from the mailing list, success stories and quotes.

Number 1: Faster development. Faster business results. (Fast implies lower cost 
in people´s minds, maybe)
Number 2: Business oriented (the more business add ons you create the better 
for your product, IMHO, much more than the technical stuff, where you have done 
a great job so far).
Number 3: Eases IT-business users communication (via prototyping, not paper, 
users don´t have imagination).
Number 4, 5, 6, 7 Great support, nice documentation, and a lot more, but it 
does not matter: It´s hard to remember more than 2 or three things when you are 
new to something.

I don´t want to suggest a name, Apache Speedy Gonzalez, the latest might be 
well known but doesn´t necessarily have the desired image or reputation (LOL, 
just kidding!). A slogan should be short and simple. Don´t you like things like 
Home Depot´s "More Saving, More Doing" or Walmart´s "Save Money. Live Better"?  
Something like  "Prototype. Deliver. Fast!"  or  "Business. Results. Now." 
might work?.

I hope that helps.

Cesar.





was (Author: cesar.l...@sisorg.com.mx):
Hello. I agree that, from a marketing perspective, this is a very good 
initiative, Despite how elegant Isis might sound, the other Isis is making too 
much noise to you, and you need to be heard. I have been involved in a few 
professional marketing processes when marketing some of our products to US, 
Europe and Latin America, and the marketing experts pointed out more or less 
the following (in my own words, sorry about that):

The name must be memorable (easy to remember).
The name should quite simply represent the main properties (not features) of 
your product  (no explanations needed, almost obvious) . The properties are the 
ones in the minds of your potential customers and actual customers.
They also suggested we considered names coming from Latin roots. This helps 
when addressing non-English spoken people, mostly likely it will be the same or 
very similar word in many languages, at least Latin root languages.

That said, let me share with you which ones I think might be your main 
competitors, direct or indirect, and their main property in my mind:
- Spring Framework. (Comprehensive, de facto standard to many, mature / old?)
- Spring Framework. (ups!)
- Grails. (Fast)
- OpenXava. (Faster)
- Vaadin. (Elegant, Beautiful UI, for the Java-only guys)
- Play. (Fast?)
- Django?. (Yes Python, still a competitor,  almost a de facto standard)
- RoR? (Ruby on Rails) (Yes Ruby, still a competitor, de facto standard)
- Cubicweb?. (Python, fast, semantic)

Now, let me share with you the ones I think are the properties that really make 
a difference in your Framework, at least in my mind, and in the ones I could 
infer from the mailing list, success stories and quotes.

Number 1: Faster development. Faster business results. (Fast implies lower cost 
in people´s minds, maybe)
Number 2: Business oriented (the more business add ons you create the better 
for your product, IMHO, much more than the technical stuff, where you have do

[jira] [Commented] (ISIS-993) Show different object members on multiple tabs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131159#comment-15131159
 ] 

ASF subversion and git services commented on ISIS-993:
--

Commit 8fcac96481cb21a47d8db0a64a76fa4693d5582d in isis's branch 
refs/heads/ISIS-993 from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=8fcac96 ]

ISIS-993: unreferenced properties/actions/collectoins handling


> Show different object members on multiple tabs
> --
>
> Key: ISIS-993
> URL: https://issues.apache.org/jira/browse/ISIS-993
> Project: Isis
>  Issue Type: New Feature
>  Components: Core, Core: Viewer: Wicket
>Affects Versions: viewer-wicket-1.7.0
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.12.0
>
>
> 4-jan-2016:
> Divide the screen into two halves.
> All properties in separate tabs.
> Each collection in its own tabs.
> ~~~
> as per [1] mailing list thread.
> The example in the mailng list splits up the object's properties/collections 
> (contributed or otherwise) into two different sets of tabs... but as a first 
> pass I think a single row of tabs ought to suffice.
> We also need to be mindful that we may want to use tabs as a metaphor for 
> multiple opened objects (as a replacement for bookmarks), so this is another 
> reason for a single row of tabs. 
> To support this would require extensions to @DomainObjectLayout or equivalent 
> xxx.layout.json file.
> [1] http://markmail.org/message/merftvqoiy6ht3kq



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ISIS-993) Show different object members on multiple tabs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131158#comment-15131158
 ] 

ASF subversion and git services commented on ISIS-993:
--

Commit fe46a781eb7472694e705cfd396e630964c3add3 in isis's branch 
refs/heads/ISIS-993 from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=fe46a78 ]

ISIS-993: normalizing the BS3 grid, factoring out commonalities into superclass.


> Show different object members on multiple tabs
> --
>
> Key: ISIS-993
> URL: https://issues.apache.org/jira/browse/ISIS-993
> Project: Isis
>  Issue Type: New Feature
>  Components: Core, Core: Viewer: Wicket
>Affects Versions: viewer-wicket-1.7.0
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.12.0
>
>
> 4-jan-2016:
> Divide the screen into two halves.
> All properties in separate tabs.
> Each collection in its own tabs.
> ~~~
> as per [1] mailing list thread.
> The example in the mailng list splits up the object's properties/collections 
> (contributed or otherwise) into two different sets of tabs... but as a first 
> pass I think a single row of tabs ought to suffice.
> We also need to be mindful that we may want to use tabs as a metaphor for 
> multiple opened objects (as a replacement for bookmarks), so this is another 
> reason for a single row of tabs. 
> To support this would require extensions to @DomainObjectLayout or equivalent 
> xxx.layout.json file.
> [1] http://markmail.org/message/merftvqoiy6ht3kq



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[Cesar Lugo (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130634#comment-15130634
 ] 

Cesar Lugo commented on ISIS-1303:
--

Following up with Dan and Tobias, if you like hexagon, what about something 
like XAgon, with X and A leaning forward like giving the impression of speed? 

 Apache XAgon 
Prototype. Deliver. Fast!

> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the 
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down barriers between IT and business
> Of these, I think that hexagonal architecture looks the best fit; it is well 
> regarded as a concept among the "cognoscenti", but there are surprisingly no 
> open source frameworks out there (at least in the Java space) that position 
> themselves as being the natural choice.
> Therefore, I think a name - and appropriate short tag line - based around 
> this idea of hexagonal architecture should be considered.
> Candidate names:
> - hex  (mig

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[Cesar Lugo (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130587#comment-15130587
 ] 

Cesar Lugo commented on ISIS-1303:
--

Hello. I agree that, from a marketing perspective, this is a very good 
initiative, Despite how elegant Isis might sound, the other Isis is making too 
much noise to you, and you need to be heard. I have been involved in a few 
professional marketing processes when marketing some of our products to US, 
Europe and Latin America, and the marketing experts pointed out more or less 
the following (in my own words, sorry about that):

The name must be memorable (easy to remember).
The name should quite simply represent the main properties (not features) of 
your product  (no explanations needed, almost obvious) . The properties are the 
ones in the minds of your potential customers and actual customers.
They also suggested we considered names coming from Latin roots. This helps 
when addressing non-English spoken people, mostly likely it will be the same or 
very similar word in many languages, at least Latin root languages.

That said, let me share with you which ones I think might be your main 
competitors, direct or indirect, and their main property in my mind:
- Spring Framework. (Comprehensive, de facto standard to many, mature / old?)
- Spring Framework. (ups!)
- Grails. (Fast)
- OpenXava. (Faster)
- Vaadin. (Elegant, Beautiful UI, for the Java-only guys)
- Play. (Fast?)
- Django?. (Yes Python, still a competitor,  almost a de facto standard)
- RoR? (Ruby on Rails) (Yes Ruby, still a competitor, de facto standard)
- Cubicweb?. (Python, fast, semantic)

Now, let me share with you the ones I think are the properties that really make 
a difference in your Framework, at least in my mind, and in the ones I could 
infer from the mailing list, success stories and quotes.

Number 1: Faster development. Faster business results. (Fast implies lower cost 
in people´s minds, maybe)
Number 2: Business oriented (the more business add ons you create the better 
for your product, IMHO, much more than the technical stuff, where you have done 
a great job so far).
Number 3: Eases IT-business users communication (via prototyping, not paper, 
users don´t have imagination).
Number 4, 5, 6, 7 Great support, nice documentation, and a lot more, but does 
not matter. It´s hard to remember more than 2 or tree when new to something.

I don´t want to suggest a name, Apache Speedy Gonzalez, the latest might be 
well known but doesn´t necessarily have the desired image or reputation (LOL, 
just kidding!). A slogan should be short and simple. Don´t you like things like 
Home Depot´s "More Saving, More Doing" or Walmart´s "Save Money. Live Better"?  
Something like  "Prototype. Deliver. Fast!"  or  "Business. Results. Now." 
might work?.

I hope that helps.

Cesar.




> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD communi

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[Tobias Poswistak (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130365#comment-15130365
 ] 

Tobias Poswistak commented on ISIS-1303:


I pretty much like the made up word by Dan Haywood 'hexag (partial word)', as 
it could also stand for *hex*agonal *ex*tentionable and *ag*ile

> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the 
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down barriers between IT and business
> Of these, I think that hexagonal architecture looks the best fit; it is well 
> regarded as a concept among the "cognoscenti", but there are surprisingly no 
> open source frameworks out there (at least in the Java space) that position 
> themselves as being the natural choice.
> Therefore, I think a name - and appropriate short tag line - based around 
> this idea of hexagonal architecture should be considered.
> Candidate names:
> - hex  (might hit trademark issues)
> - hexagon
> - hexagn

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130231#comment-15130231
 ] 

Ged edited comment on ISIS-1303 at 2/3/16 11:02 AM:


Another potential name on this theme is Apache Gestalt, based on this slide 
from Shyman Sankar's TED Talk

!ApacheGestalt.jpg!

Gestalt means "an organized whole that is perceived as more than the sum of its 
parts."

According to the equation the Analytic Capability is increased as the friction 
in human-computer interaction is reduced.  Apache [Isis|Gestalt|...] reduces 
this friction.


was (Author: ged.by...@gmail.com):
Another potential name on this theme is Apache Gestalt, based on this slide 
from Shyman Sankar's TED Talk

!ApacheGestalt.jpg!

Gestalt means "an organized whole that is perceived as more than the sum of its 
parts."

> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the 
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down bar

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130231#comment-15130231
 ] 

Ged edited comment on ISIS-1303 at 2/3/16 10:59 AM:


Another potential name on this theme is Apache Gestalt, based on this slide 
from Shyman Sankar's TED Talk

!ApacheGestalt.jpg!

Gestalt means "an organized whole that is perceived as more than the sum of its 
parts."


was (Author: ged.by...@gmail.com):
Another potential name on this theme is Apache Gestalt, based on this slide 
from Shyman Sankar's TED Talk

!ApacheGestalt.gif!

Gestalt means "an organized whole that is perceived as more than the sum of its 
parts."

> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the 
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down barriers between IT and business
> Of these, I think that hexagonal architecture looks the best fit; it is well 
> regarded as a concept among the "cognoscenti", but there are s

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130231#comment-15130231
 ] 

Ged commented on ISIS-1303:
---

Another potential name on this theme is Apache Gestalt, based on this slide 
from Shyman Sankar's TED Talk

!ApacheGestalt.gif!

Gestalt means "an organized whole that is perceived as more than the sum of its 
parts."

> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the 
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down barriers between IT and business
> Of these, I think that hexagonal architecture looks the best fit; it is well 
> regarded as a concept among the "cognoscenti", but there are surprisingly no 
> open source frameworks out there (at least in the Java space) that position 
> themselves as being the natural choice.
> Therefore, I think a name - and appropriate short tag line - based around 
> this idea of hexagonal architecture should be considered.
> Candidate names:
> - hex  (m

[jira] [Updated] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ged updated ISIS-1303:
--
Attachment: ApacheGestalt.jpg

> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the 
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down barriers between IT and business
> Of these, I think that hexagonal architecture looks the best fit; it is well 
> regarded as a concept among the "cognoscenti", but there are surprisingly no 
> open source frameworks out there (at least in the Java space) that position 
> themselves as being the natural choice.
> Therefore, I think a name - and appropriate short tag line - based around 
> this idea of hexagonal architecture should be considered.
> Candidate names:
> - hex  (might hit trademark issues)
> - hexagon
> - hexagn  (deliberately mis-spelled)
> - hxg  (omitting vowels, but could stand for hexagonal, extensible, generic)
> - hx (too short?)
> some made up words
> - hexag (partial word)
> - hexadom (sounds

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[JIRA]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130195#comment-15130195
 ] 

Jörg Rade commented on ISIS-1303:
-

Hi,

{code}We are like dwarfs sitting on the shoulders of giants{code} and 
definitely Engelbart is one of them. It would be nice to have all those 
influences summarized. 

For marketing purposes I think the variants of Hexagonal come in handy, since 
they refer to the very expressive overview diagram and some honeycomb logo 
could dig into the readers brain.

-j


> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the 
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down barriers between IT and business
> Of these, I think that hexagonal architecture looks the best fit; it is well 
> regarded as a concept among the "cognoscenti", but there are surprisingly no 
> open source frameworks out there (at least in the Java space) that position 
> themselves as being the natural choice.
> Therefore, I think a name - and appropriate sh

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120
 ] 

Ged edited comment on ISIS-1303 at 2/3/16 10:13 AM:


My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are just enablers that helps us reach the goal of 
augmenting human activities.  Augmenting the human activities that both develop 
and use software systems.

Engelbart was the pioneer of using computers for human augmentation.  His goal 
was the "boosting mankind’s capability for coping with complex, urgent 
problems".  Reenskaug's forward to Pawson's thesis includes this quote:

| By "augmenting human intellect" we mean increasing the capability of a man to 
approach
a complex problem situation, to gain comprehension to suit his particular 
needs, and to
derive solutions to problems. . . Increased capability in this respect is taken 
to mean a
mixture of the following: more-rapid comprehension, better comprehension, the
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex, speedier solutions, better solutions, and the possibility of 
finding solutions to
problems that before seemed insoluble. |
| http://www.dougengelbart.org/pubs/augment-3906.html  |

Engelbarts 'Mother of all Demos' is essential viewing: 
https://www.youtube.com/watch?v=yJDv-zdhzMY

I believe that Apache Isis also suffers from being to ahead of it's time, as 
Engelbart was.  Here's an interesting retrospect on how Engelbart came to see 
his career as a failure: 
http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/
 

I believe that this change of name should be taken as an opportunity to return 
to this goal of human augmentation as the central theme for the project, 
keeping alive the vision of Pawson and Engelbart.  By focusing on allowing 
humans to do more by augmenting their capabilities rather than seeking to have 
humans do less by automating what they do.

h1. Apache Engelbart
  * speedier solutions
  * better solutions
  * solutions to problems that were once insoluble

Engelbart also helps us understand how DDD fits into all this, with his 
emphasis on comprehension: "more-rapid comprehension, better comprehension, the 
possibility of gaining a useful degree of comprehension in a situation that 
previously was too complex"

I feel that DDD has lost it's way because the focus has been on the second half 
- the patterns for implementation.  The real power of DDD is in the first half: 
Knowledge Crunching.   The implementation patterns are just enablers for 
achieving better comprehension, progressively gaining more insight into complex 
domains.

I would also recommend looking into Shyam Sankar
https://www.ted.com/speakers/shyam_sankar

If there is a problem with the Engelbart name, can I also suggest Apache 
Farthing.  This is a play on Penny Farthing and Steve Jobs 'A Bicycle for the 
Mind.'  Also, I think a Penny Farthing will make for a cool logo.




was (Author: ged.by...@gmail.com):
My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in 

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120
 ] 

Ged edited comment on ISIS-1303 at 2/3/16 9:56 AM:
---

My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are just enablers that helps us reach the goal of 
augmenting human activities.  Augmenting the human activities that both develop 
and use software systems.

Engelbart was the pioneer of using computers for human augmentation.  His goal 
was the "boosting mankind’s capability for coping with complex, urgent 
problems".  Reenskaug's forward to Pawson's thesis includes this quote:

| By "augmenting human intellect" we mean increasing the capability of a man to 
approach
a complex problem situation, to gain comprehension to suit his particular 
needs, and to
derive solutions to problems. . . Increased capability in this respect is taken 
to mean a
mixture of the following: more-rapid comprehension, better comprehension, the
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex, speedier solutions, better solutions, and the possibility of 
finding solutions to
problems that before seemed insoluble. |
| http://www.dougengelbart.org/pubs/augment-3906.html  |

Engelbarts 'Mother of all Demos' is essential viewing: 
https://www.youtube.com/watch?v=yJDv-zdhzMY

I believe that Apache Isis also suffers from being to ahead of it's time, as 
Engelbart was.  Here's an interesting retrospect on how Engelbart came to see 
his career as a failure: 
http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/
 

I believe that this change of name should be taken as an opportunity to return 
to this goal of human augmentation as the central theme for the project, 
keeping alive the vision of Pawson and Engelbart.  By focusing on allowing 
humans to do more by augmenting their capabilities rather than seeking to have 
humans do less by automating what they do.

h1. Apache Engelbart
  * speedier solutions
  * better solutions
  * solutions to problems that were once insoluble

Engelbart also helps us understand how DDD fits into all this, with his 
emphasis on comprehension: "more-rapid comprehension, better comprehension, the 
possibility of gaining a useful degree of comprehension in a situation that 
previously was too complex"

I feel that DDD has lost it's way because the focus has been on the second half 
- the patterns for implementation.  The real power of DDD is in the first half: 
Knowledge Crunching.   The implementation patterns are just enablers for 
achieving better comprehension, progressively gaining more insight into complex 
domains.

I would also recommend looking into Shyam Sankar
https://www.ted.com/speakers/shyam_sankar




was (Author: ged.by...@gmail.com):
My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120
 ] 

Ged edited comment on ISIS-1303 at 2/3/16 9:55 AM:
---

My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are just enablers that helps us reach the goal of 
augmenting human activities.  Augmenting the human activities that both develop 
and use software systems.

Engelbart was the pioneer of using computers for human augmentation.  His goal 
was the "boosting mankind’s capability for coping with complex, urgent 
problems".  Reenskaug's forward to Pawson's thesis includes this quote:

| By "augmenting human intellect" we mean increasing the capability of a man to 
approach
a complex problem situation, to gain comprehension to suit his particular 
needs, and to
derive solutions to problems. . . Increased capability in this respect is taken 
to mean a
mixture of the following: more-rapid comprehension, better comprehension, the
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex, speedier solutions, better solutions, and the possibility of 
finding solutions to
problems that before seemed insoluble. |
| http://www.dougengelbart.org/pubs/augment-3906.html  |

Engelbarts 'Mother of all Demos' is essential viewing: 
https://www.youtube.com/watch?v=yJDv-zdhzMY

I believe that Apache Isis also suffers from being to ahead of it's time, as 
Engelbart was.  Here's an interesting retrospect on how Engelbart came to see 
his career as a failure: 
http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/
 

I believe that this change of name should be taken as an opportunity to return 
this goal of human augmentation as the central theme for the project, keeping 
alive the vision of Pawson and Engelbart.  By focusing on allowing humans to do 
more by augmenting their capabilities rather than seeking to have humans do 
less by automating what they do.

h1. Apache Engelbart
  * speedier solutions
  * better solutions
  * solutions to problems that were once insoluble

Engelbart also helps us understand how DDD fits into all this, with his 
emphasis on comprehension: "more-rapid comprehension, better comprehension, the 
possibility of gaining a useful degree of comprehension in a situation that 
previously was too complex"

I feel that DDD has lost it's way because the focus has been on the second half 
- the patterns for implementation.  The real power of DDD is in the first half: 
Knowledge Crunching.   The implementation patterns are just enablers for 
achieving better comprehension, progressively gaining more insight into complex 
domains.

I would also recommend looking into Shyam Sankar
https://www.ted.com/speakers/shyam_sankar




was (Author: ged.by...@gmail.com):
My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a fo

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[Alejandro Duarte (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130135#comment-15130135
 ] 

Alejandro Duarte commented on ISIS-1303:


Hi everyone,

Great to hear about this. Anytime I try to explain what Apache Isis is (a Naked 
Objects implementation), I get jokes about helicopters and sexy stuff ;) This 
redirects attention and interest from the framework to other things. Some 
thoughts:

* Regarding a new name:
** I would advice against using acronyms. The name communicates, it should 
reflect what the framework is about. Acronyms tell nothing to people who comes 
across them.
** In my opinion, _Hexagon_ sounds catchy. The spelling variations might be 
good options only if the change in spelling has meaning.
* JHipster... I see what you did there ;) but it's probably better to follow 
Dan's advice and not to take those seriously :)
* How about using _breaking down barriers between IT and business_ or _don't be 
square_ as slogan?
* I kind of like the association between "hexagonal" and "honeycomb" but would 
rather use honeycomb as inspiration for logo or marketing related art.

Anyway, just my 5 bits...

Cheers.

> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect o

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120
 ] 

Ged edited comment on ISIS-1303 at 2/3/16 9:53 AM:
---

My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are just enablers that helps us reach the goal of 
augmenting human activities.  Augmenting the human activities that both develop 
and use software systems.

Engelbart was the pioneer of using computers for human augmentation.  His goal 
was the "boosting mankind’s capability for coping with complex, urgent 
problems".  Reenskaug's forward to Pawson's thesis includes this quote:

| By "augmenting human intellect" we mean increasing the capability of a man to 
approach
a complex problem situation, to gain comprehension to suit his particular 
needs, and to
derive solutions to problems. . . Increased capability in this respect is taken 
to mean a
mixture of the following: more-rapid comprehension, better comprehension, the
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex, speedier solutions, better solutions, and the possibility of 
finding solutions to
problems that before seemed insoluble. |
| http://www.dougengelbart.org/pubs/augment-3906.html  |

Engelbarts 'Mother of all Demos' is essential viewing: 
https://www.youtube.com/watch?v=yJDv-zdhzMY

I believe that Apache Isis also suffers from being to ahead of it's time, as 
Engelbart was.  Here's an interesting retrospect on how Engelbart came to see 
his career as a failure: 
http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/
 

I believe that this change of name should be taken as an opportunity to return 
this goal of human augmentation as the central theme for the project, keeping 
alive the vision of Pawson and Engelbart.  By focusing on allowing humans to do 
more by augmenting their capabilities rather than seeking to have humans do 
less by automating what they do.

h1. Apache Engelbart
  * speedier solutions
  * better solutions
  * solutions to problems that were once insoluble

Engelbart also helps us understand how DDD fits into all this, with his 
emphasis on comprehension: "more-rapid comprehension, better comprehension, the 
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex"

I feel that DDD has lost it's way because the focus has been on the second half 
- the patterns for implementation.  The real power of DDD is in the first half: 
Knowledge Crunching.   The implementation patterns are just enablers for 
achieving better comprehension, progressively gaining more insight into complex 
domains.

I would also recommend looking into Shyam Sankar
https://www.ted.com/speakers/shyam_sankar




was (Author: ged.by...@gmail.com):
My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a fo

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120
 ] 

Ged edited comment on ISIS-1303 at 2/3/16 9:53 AM:
---

My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are just enablers that helps us reach the goal of 
augmenting human activities.  Augmenting the human activities that both develop 
and use software systems.

Engelbart was the pioneer of using computers for human augmentation.  His goal 
was the "boosting mankind’s capability for coping with complex, urgent 
problems".  Reenskaug's forward to Pawson's thesis includes this quote:

| By "augmenting human intellect" we mean increasing the capability of a man to 
approach
a complex problem situation, to gain comprehension to suit his particular 
needs, and to
derive solutions to problems. . . Increased capability in this respect is taken 
to mean a
mixture of the following: more-rapid comprehension, better comprehension, the
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex, speedier solutions, better solutions, and the possibility of 
finding solutions to
problems that before seemed insoluble. |
| http://www.dougengelbart.org/pubs/augment-3906.html  |

Engelbarts 'Mother of all Demos' is essential viewing: 
https://www.youtube.com/watch?v=yJDv-zdhzMY

I believe that Apache Isis also suffers from being to ahead of it's time, as 
Engelbart was.  Here's an interesting retrospect on how Engelbart came to see 
his career as a failure: 
http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/
 

I believe that this change of name should be taken as an opportunity to return 
this goal of human augmentation as the central theme for the project, keeping 
alive the vision of Pawson and Engelbart.  By focusing on allowing humans to do 
more by augmenting their capabilities rather than seeking to have humans do 
less by automating what they do.

h1. Apache Engelbart
  * speedier solutions
  * better solutions
  * solutions to problems that were once insoluble

Engelbart also helps us understand how DDD fits into all this, with his 
emphasis on comprehension: "more-rapid comprehension, better comprehension, the
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex"

I feel that DDD has lost it's way because the focus has been on the second half 
- the patterns for implementation.  The real power of DDD is in the first half: 
Knowledge Crunching.   The implementation patterns are just enablers for 
achieving better comprehension, progressively gaining more insight into complex 
domains.

I would also recommend looking into Shyam Sankar
https://www.ted.com/speakers/shyam_sankar




was (Author: ged.by...@gmail.com):
My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a for

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120
 ] 

Ged edited comment on ISIS-1303 at 2/3/16 9:45 AM:
---

My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are just enablers that helps us reach the goal of 
augmenting human activities.  Augmenting the human activities that both develop 
and use software systems.

Engelbart was the pioneer of using computers for human augmentation.  His goal 
was the "boosting mankind’s capability for coping with complex, urgent 
problems".  Reenskaug's forward to Pawson's thesis includes this quote:

| By "augmenting human intellect" we mean increasing the capability of a man to 
approach
a complex problem situation, to gain comprehension to suit his particular 
needs, and to
derive solutions to problems. . . Increased capability in this respect is taken 
to mean a
mixture of the following: more-rapid comprehension, better comprehension, the
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex, speedier solutions, better solutions, and the possibility of 
finding solutions to
problems that before seemed insoluble. |
| http://www.dougengelbart.org/pubs/augment-3906.html  |

Engelbarts 'Mother of all Demos' is essential viewing: 
https://www.youtube.com/watch?v=yJDv-zdhzMY

I believe that Apache Isis also suffers from being to ahead of it's time, as 
Engelbart was.  Here's an interesting retrospect on how Engelbart came to see 
his career as a failure: 
http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/
 

I believe that this change of name should be taken as an opportunity to return 
this goal of human augmentation as the central theme for the project, keeping 
alive the vision of Pawson and Engelbart.  By focusing on allowing humans to do 
more by augmenting their capabilities rather than seeking to have humans do 
less by automating what they do.

h1. Apache Engelbart
  * speedier solutions
  * better solutions
  * solutions to problems that were once insoluble

I would also recommend looking into Shyam Sankar
https://www.ted.com/speakers/shyam_sankar


was (Author: ged.by...@gmail.com):
My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are j

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120
 ] 

Ged edited comment on ISIS-1303 at 2/3/16 9:45 AM:
---

My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical difference between Apache Isis and JHipster.

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are just enablers that helps us reach the goal of 
augmenting human activities.  Augmenting the human activities that both develop 
and use software systems.

Engelbart was the pioneer of using computers for human augmentation.  His goal 
was the "boosting mankind’s capability for coping with complex, urgent 
problems".  Reenskaug's forward to Pawson's thesis includes this quote:

| By "augmenting human intellect" we mean increasing the capability of a man to 
approach
a complex problem situation, to gain comprehension to suit his particular 
needs, and to
derive solutions to problems. . . Increased capability in this respect is taken 
to mean a
mixture of the following: more-rapid comprehension, better comprehension, the
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex, speedier solutions, better solutions, and the possibility of 
finding solutions to
problems that before seemed insoluble. |
| http://www.dougengelbart.org/pubs/augment-3906.html  |

Engelbarts 'Mother of all Demos' is essential viewing: 
https://www.youtube.com/watch?v=yJDv-zdhzMY

I believe that Apache Isis also suffers from being to ahead of it's time, as 
Engelbart was.  Here's an interesting retrospect on how Engelbart came to see 
his career as a failure: 
http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/
 

I believe that this change of name should be taken as an opportunity to return 
this goal of human augmentation as the central theme for the project, keeping 
alive the vision of Pawson and Engelbart.  By focusing on allowing humans to do 
more by augmenting their capabilities rather than seeking to have humans to 
less by automating what they do.

h1. Apache Engelbart
  * speedier solutions
  * better solutions
  * solutions to problems that were once insoluble

I would also recommend looking into Shyam Sankar
https://www.ted.com/speakers/shyam_sankar


was (Author: ged.by...@gmail.com):
My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical different between JHipster and Apache Isis

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are jus

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[Ged (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120
 ] 

Ged commented on ISIS-1303:
---

My name suggestion: Apache Engelbart 

This is in tribute to computer pioneer Douglas Engelbart: 
https://en.wikipedia.org/wiki/Douglas_Engelbart

Please let me explain why.  

I notice from the tonuge in cheek examples that you want to distinguish ISIS 
from the main competition: JHipster.

Here is the critical different between JHipster and Apache Isis

  * Apache Isis is a framework for *AUGMENTATION*
  * jHipster is a framework for *AUTOMATION*

If we return to the Isis' Naked Object roots and the principles that Richard 
Pawson set out in his thesis and book.

When defining the Naked Object approach the second principle put the human in 
control:

| Instead of pursuing optimal efficiency in the execution of each of a finite 
set of scripted tasks, design *a form of user interaction that maximizes the 
overall effectiveness of the users in fulfilling their broader 
responsibilities.* This means giving the users more control, for example over 
the order in which capabilities are invoked in order to achieve a goal. We 
should also design systems that allow users to become more expert as they 
learn, rather than constraining everyone to the lowest common denominator. |
| http://www.nakedobjects.org/book/section7.html (emphais added) |

So the Naked Objects approach is not about developing UIs faster or any type of 
architecture.  Those are just enablers that helps us reach the goal of 
augmenting human activities.  Augmenting the human activities that both develop 
and use software systems.

Engelbart was the pioneer of using computers for human augmentation.  His goal 
was the "boosting mankind’s capability for coping with complex, urgent 
problems".  Reenskaug's forward to Pawson's thesis includes this quote:

| By "augmenting human intellect" we mean increasing the capability of a man to 
approach
a complex problem situation, to gain comprehension to suit his particular 
needs, and to
derive solutions to problems. . . Increased capability in this respect is taken 
to mean a
mixture of the following: more-rapid comprehension, better comprehension, the
possibility of gaining a useful degree of comprehension in a situation that 
previously was
too complex, speedier solutions, better solutions, and the possibility of 
finding solutions to
problems that before seemed insoluble. |
| http://www.dougengelbart.org/pubs/augment-3906.html  |

Engelbarts 'Mother of all Demos' is essential viewing: 
https://www.youtube.com/watch?v=yJDv-zdhzMY

I believe that Apache Isis also suffers from being to ahead of it's time, as 
Engelbart was.  Here's an interesting retrospect on how Engelbart came to see 
his career as a failure: 
http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/
 

I believe that this change of name should be taken as an opportunity to return 
this goal of human augmentation as the central theme for the project, keeping 
alive the vision of Pawson and Engelbart.  By focusing on allowing humans to do 
more by augmenting their capabilities rather than seeking to have humans to 
less by automating what they do.

h1. Apache Engelbart
  * speedier solutions
  * better solutions
  * solutions to problems that were once insoluble

> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And 

Re: Vaadin Viewer for Apache Isis

[Alejandro Duarte]

Hi,

I agree. It's not a trivial task. I have found out that not having
sufficient experience with Apache Isis is a factor that has played against
me while trying make progress with this project. As my coding sessions for
this project have been quite dispersed, any time I start working on it I
end up reviewing what I did in my previous sessions, reading documentation
about Apache Isis, and trying the tutorial again. This process is far from
optimal and will need to do some adjustments if I want to continue working
on it. I'm aiming at working on this every Friday.

At the moment I have a blocker: I don't know how to get the "meta-model"
(if that's a correct term) the viewer should use to dynamically create the
UI. Any ideas or documentation about it would be highly appreciated.

Cheers,
Alejandro Duarte


On Fri, Jan 29, 2016 at 2:51 PM, Bilgin Ibryam  wrote:

> Alejandro,
>
> I also won't be able to commit to such an effort, nor have the
> necessary skills to do it.
> I've tried once to integrate Vaadin with Apache OFBiz and I know it is
> not small peace of work.
>
> I can see it more likely to happen if it is sponsored by a customer
> projects.
>
> My 2p
>
>
>
> On 26 January 2016 at 20:49, Alejandro Duarte 
> wrote:
> > Hi,
> >
> > Unfortunately I haven't been able to put energy into this. Bilgin, would
> > you be interested in collaborating with this? Any other volunteer?
> >
> > Cheers,
> > Alejandro Duarte
> >
> > On Tue, Jan 26, 2016 at 10:14 PM, Bilgin Ibryam 
> wrote:
> >
> >> Hi all,
> >>
> >> being fan of both Vaadin and Isis, I'm just wondering if there is any
> >> progress on this front?
> >>
> >> Thanks
> >> Bilgin
> >>
> >>
> >> On 20 October 2015 at 06:03, Kevin Meyer  wrote:
> >> > Welcome Alejandro!
> >> >
> >> > I wish you great success and joy, you're joining a tight, passionate
> >> group of developers!
> >> >
> >> > All the best,
> >> > Kevin
> >> >
> >> >
> >> > On 19 October 2015 15:28:59 CEST, Alejandro Duarte <
> alejan...@vaadin.com>
> >> wrote:
> >> >>Hi everyone!
> >> >>
> >> >>First of all, congratulations for the work done with Apache Isis. I've
> >> >>been playing with it recently and feeling eager to explore the
> >> >>framework deeper.
> >> >>
> >> >>Besides congratulating, I'd like to quickly introduce myself and
> >> >>announce a related project I will be working on during the next
> months.
> >> >>
> >> >>I'm a software developer working for Vaadin Ltd, the company
> developing
> >> >>the Vaadin Framework [1]. Some days ago, Dan Haywood twitted about his
> >> >>interest in contacting someone willing to implement an Apache Isis
> >> >>viewer using Vaadin. That twitt got my attention and contacted Dan who
> >> >>gave me some advice on how to proceed. It's going to be fun working on
> >> >>this probably during the next months. There is a GitHub repository
> >> >>where you can follow the progress if you are interested [2].
> >> >>
> >> >>[1] https://vaadin.com 
> >> >>[2] https://github.com/alejandro-du/vaadin-viewer
> >> >>
> >> >>
> >> >>--
> >> >>Alejandro Duarte, Vaadin Developer
> >> >>Vaadin.com 
> >> >
> >> > --
> >> > Sent from my phone with K-9 Mail.
> >> > Please excuse my brevity.
> >>
> >>
> >>
> >> --
> >> Bilgin Ibryam
> >> Camel Committer at ASF & Integration Architect at Red Hat
> >> Blog: http://ofbizian.com | Twitter: @bibryam
> >>
> >> Camel Design Patterns https://leanpub.com/camel-design-patterns
> >> Instant Apache Camel Message Routing
> http://www.amazon.com/dp/1783283475
> >>
> >
> >
> >
> > --
> > Alejandro Duarte, Vaadin Developer
> > Vaadin.com  - +358 447 667 581 - skype:alejandro.du
>
>
>
> --
> Bilgin Ibryam
> Camel Committer at ASF & Integration Architect at Red Hat
> Blog: http://ofbizian.com | Twitter: @bibryam
>
> Camel Design Patterns https://leanpub.com/camel-design-patterns
> Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475
>

[jira] [Comment Edited] (ISIS-1302) Use bundled JARs instead of plain ones

[JIRA]

[ 
https://issues.apache.org/jira/browse/ISIS-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15126279#comment-15126279
 ] 

Jörg Rade edited comment on ISIS-1302 at 2/3/16 8:46 AM:
-

List of jars in ~\simpleapp\webapp\target\simpleapp-webapp-\WEB-INF\lib
checked with {code} java -jar biz.aQute.bnd-3.1 jar verify *.jar{code}

List of possible replacements looked up via 
{code}http://jpm4j.org/#!/{code}


was (Author: joerg.rade):
List of jars in ~\simpleapp\webapp\target\simpleapp-webapp-\WEB-INF\lib
checked with {code} java -jar c:\bin\bnd\biz.aQute.bnd-3.1 jar verify 
*.jar{code}

List of possible replacements looked up via 
{code}http://jpm4j.org/#!/{code}

> Use bundled JARs instead of plain ones
> --
>
> Key: ISIS-1302
> URL: https://issues.apache.org/jira/browse/ISIS-1302
> Project: Isis
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Jörg Rade
>Assignee: Dan Haywood
>Priority: Trivial
> Attachments: simpleApp110_not_a_bundle.xlsx
>
>
> list of known replacements yet to be attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (ISIS-1302) Use bundled JARs instead of plain ones

[JIRA]

[ 
https://issues.apache.org/jira/browse/ISIS-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15126279#comment-15126279
 ] 

Jörg Rade edited comment on ISIS-1302 at 2/3/16 8:45 AM:
-

List of jars in ~\simpleapp\webapp\target\simpleapp-webapp-\WEB-INF\lib
checked with {code} java -jar c:\bin\bnd\biz.aQute.bnd-3.1 jar verify 
*.jar{code}

List of possible replacements looked up via 
{code}http://jpm4j.org/#!/{code}


was (Author: joerg.rade):
List of possible replacements

> Use bundled JARs instead of plain ones
> --
>
> Key: ISIS-1302
> URL: https://issues.apache.org/jira/browse/ISIS-1302
> Project: Isis
>  Issue Type: Sub-task
>  Components: Core
>Reporter: Jörg Rade
>Assignee: Dan Haywood
>Priority: Trivial
> Attachments: simpleApp110_not_a_bundle.xlsx
>
>
> list of known replacements yet to be attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ISIS-1303) Rename the project to better describe its values and purpose

[Dan Haywood (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Haywood updated ISIS-1303:
--
Description: 
In the past there have been a couple of discussions regarding renaming the 
project, the reason generally cited being the potential embarrassment of 
sharing a name with the jihadist militant group [1] currently prominent in the 
headlines.  After due discussion on the mailing lists the prevailing view has 
been to retain our name: "we were here first".  

Until now I've concurred with that view also... after all, I originally came up 
with the name "Isis", originally based on the name of the Thames as it flows 
through Oxford [2] (many of the original authors of the framework live within 
Oxfordshire, UK).

Separately to that discussion, we have the issue of marketing.  Originally we 
marketed ourselves as a framework implementing the "naked objects" pattern [3]; 
the original name of the framework (prior to Apache) was of course the Naked 
Objects Framework.  However, this pattern is either not well-known or is 
misunderstood (only a low proportion of developers that encounter the idea 
immediately "get it").  The crudity of the original user interfaces didn't 
help.  And the name also, of course, can cause embarrassment in some cultures.

Then, when domain-driven design [4] came along as a movement, that seemed an 
obvious platform upon which to position the framework: we obviously share the 
core belief that the domain is the most important bit of the system.  However - 
and I still find this surprising - despite attempts otherwise we haven't really 
made too much of an impression in that community.  The fact that the DDD 
community got massively sidetracked for a while by the CQRS pattern is perhaps 
part of it.   I also often detect the view that DDD should imply not using a 
framework.  The irony of course is that in rejecting framework such developers 
actually have to write more infrastructure code vs business domain code.

Also, the fit is perhaps not all that good after all.  In the DDD community I 
don't see anyone talking about modules... one of the named patterns, and a 
major focus of our framework, but missing from DDD talks.  Instead they get 
side-tracked talking only about aggregate roots or bounded contexts; all well 
and good, but over-emphasised).

[Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
person), and he agreed there was little emphasis.  When I described our 
framework's use of domain events to hook modules together (along with vetoing 
behaviour we support) he admitted it was a new approach/pattern to him...]

Anyway, so DDD - which looked so promising - hasn't delivered.  They might come 
around to us one day, but it's probably time to define our own individual 
space.  Also, in the same way that everyone takes agile development for granted 
as the "de facto", we ought to simply take DDD for granted too... "of course 
you will be doing DDD, but are you doing it well?"

What we need to better market the framework is some other pattern or concept or 
hook, and become known as the framework that best supports that idea.  There 
are several candidates:
- hexagonal architecture (also called ports and adapters, or the onion 
architecture, and related to the clean architecture)
- don't repeat yourself principle
- aspect oriented programming (naked objects pattern is really the recognition 
that UI presentation is a cross-cutting concern)
- the general concept of modularity
- DCI (data/context/interactions).
- "clean" "pure" "essential" pojo programming model
- agile, lean
- breaking down barriers between IT and business

Of these, I think that hexagonal architecture looks the best fit; it is well 
regarded as a concept among the "cognoscenti", but there are surprisingly no 
open source frameworks out there (at least in the Java space) that position 
themselves as being the natural choice.

Therefore, I think a name - and appropriate short tag line - based around this 
idea of hexagonal architecture should be considered.

Candidate names:
- hex  (might hit trademark issues)
- hexagon
- hexagn  (deliberately mis-spelled)
- hxg  (omitting vowels, but could stand for hexagonal, extensible, generic)
- hx (too short?)

some made up words
- hexag (partial word)
- hexadom (sounds like a dinosaur?)
- mhodex (an anagram of hex and mod)

A common usage of hexagons is in bee hives, so:
- honeycomb (the outer hexagon is the BC, the inner hexagons are modules)
- comb (abbreviating it)

picking up on the DRY principle, we have deserts (might have trademark issues):
- sahara
- kalahari
- gobi

Or, we could go a different way altogether.  Some random ideas:
- meld (mind-meld, joining together)
- sweetheart (because we love it)
- neuron (too bland?)
- razor (trademark issues?)
- razr (trademark issues?)

Any new name must pass the ASF naming procedures, documented in [5

[jira] [Created] (ISIS-1303) Rename the project to better describe its values and purpose

[Dan Haywood (JIRA)]

Dan Haywood created ISIS-1303:
-

 Summary: Rename the project to better describe its values and 
purpose
 Key: ISIS-1303
 URL: https://issues.apache.org/jira/browse/ISIS-1303
 Project: Isis
  Issue Type: Wish
Affects Versions: 1.11.1
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: 1.13.0


In the past there have been a couple of discussions regarding renaming the 
project, the reason generally cited being the potential embarrassment of 
sharing a name with the jihadist militant group [1] currently prominent in the 
headlines.  After due discussion on the mailing lists the prevailing view has 
been to retain our name: "we were here first".  

Until now I've concurred with that view also... after all, I originally came up 
with the name "Isis", originally based on the name of the Thames as it flows 
through Oxford [2] (many of the original authors of the framework live within 
Oxfordshire, UK).

Separately to that discussion, we have the issue of marketing.  Originally we 
marketed ourselves as a framework implementing the "naked objects" pattern [3]; 
the original name of the framework (prior to Apache) was of course the Naked 
Objects Framework.  However, this pattern is either not well-known or is 
misunderstood (only a low proportion of developers that encounter the idea 
immediately "get it").  The crudity of the original user interfaces didn't 
help.  And the name also, of course, can cause embarrassment in some cultures.

Then, when domain-driven design [4] came along as a movement, that seemed an 
obvious platform upon which to position the framework: we obviously share the 
core belief that the domain is the most important bit of the system.  However - 
and I still find this surprising - despite attempts otherwise we haven't really 
made too much of an impression in that community.  The fact that the DDD 
community got massively sidetracked for a while by the CQRS pattern is perhaps 
part of it.   I also often detect the view that DDD should imply not using a 
framework.  The irony of course is that in rejecting framework such developers 
actually have to write more infrastructure code vs business domain code.

Also, the fit is perhaps not all that good after all.  In the DDD community I 
don't see anyone talking about modules... one of the named patterns, and a 
major focus of our framework, but missing from DDD talks.  Instead they get 
side-tracked talking only about aggregate roots or bounded contexts; all well 
and good, but over-emphasised).

[Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
person), and he agreed there was little emphasis.  When I described our 
framework's use of domain events to hook modules together (along with vetoing 
behaviour we support) he admitted it was a new approach/pattern to him...]

Anyway, so DDD - which looked so promising - hasn't delivered.  They might come 
around to us one day, but it's probably time to define our own individual 
space.  Also, in the same way that everyone takes agile development for granted 
as the "de facto", we ought to simply take DDD for granted too... "of course 
you will be doing DDD, but are you doing it well?"

What we need to better market the framework is some other pattern or concept or 
hook, and become known as the framework that best supports that idea.  There 
are several candidates:
- hexagonal architecture (also called ports and adapters, or the onion 
architecture, and related to the clean architecture)
- don't repeat yourself principle
- aspect oriented programming (naked objects pattern is really the recognition 
that UI presentation is a cross-cutting concern)
- the general concept of modularity
- DCI (data/context/interactions).
- "clean" "pure" "essential" pojo programming model
- agile, lean
- breaking down barriers between IT and business

Of these, I think that hexagonal architecture looks the best fit; it is well 
regarded as a concept among the "cognoscenti", but there are surprisingly no 
open source frameworks out there (at least in the Java space) that position 
themselves as being the natural choice.

Therefore, I think a name - and appropriate short tag line - based around this 
idea of hexagonal architecture should be considered.

Candidate names:
- hex  (might hit trademark issues)
- hexagon
- hexagn  (deliberately mis-spelled)
- hxg  (omitting vowels, but could stand for hexagonal, extensible, generic)
- hx (too short?)

some made up words
- hexag (partial word)
- hexadom (sounds like a dinosaur?)
- mhodex (an anagram of hex and mod)

A common usage of hexagons is in bee hives, so:
- honeycomb (the outer hexagon is the BC, the inner hexagons are modules)
- comb (abbreviating it)

Or, we could go a different way altogether.  Some random ideas:
- meld (mind-meld, joining together)
- sweetheart (because we love it)
- neuron (too bland?)
- r