Re: Animated series publicising Isis

an input to the series as a whole, this is the thread to speak up! > > Cheers > Dan > > > [1] > https://docs.google.com/file/d/0B-Ekm92XLvTAN25ZNzNyYjI1eE0/edit?usp=sharing > -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541

Re: GSOC2013 - ISIS-371 (an android viewer)

gt; Can I know who is working on this part. I'm sure I can contribute well > towards that. > > Thanks, > Deepak > > > On Tue, Apr 9, 2013 at 2:11 PM, Minto van der Sluis wrote: > >> Hi Deepak, >> >> Sounds very interesting what you're asking, but I se

Re: GSOC2013 - ISIS-371 (an android viewer)

means that it is open >> and through our mailing list. >> >> In the meantime, I'll also see who in the dev community might want to >> mentor you. It might well be me, but I don't want to spread myself too >> thinly, and there should, in any case, be a back-up mentor. >> >> Thx >> Dan >> Apache Isis PMC Chair >> >> [2] http://restfulobjects.org >> [3] http://danhaywood.com/resources/viewer-stories/ >> > > -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541

[jira] [Commented] (ISIS-371) [GSOC2013] A generic (Naked Objects) Android app, to run against Isis' Restful Objects interface.

[ https://issues.apache.org/jira/browse/ISIS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13612443#comment-13612443 ] Minto van der Sluis commented on ISIS-371: -- http://www.codenameone.com/ might

Re: FWD: A prototype/mockup of an online IDE for Isis

n hours to put together. > > Maurizio: > I agree, this is an open point in every discussion. I have no idea about > how much code is already available as open source as support for a project > like this. The ACE editor is very cool but I don't know about *must have* >

Re: Blank archetype

java > > On 7 February 2013 08:18, Minto van der Sluis wrote: > >> Hi Adam, >> >> You're not the only one who wants this. :-) >> >> I have done some work on creating a tutorial [1]. I am just at the >> start. Is also contains a simplified archetype. &g

Re: Blank archetype

i. Jeroen might just want RO for a specific project. I don't know if > maven allows on-the-fly creation of archetypes at that fine-grained level. > > After talking through all of this I guess what we have now in the wrj > archetype is the right place to start a new project in that it includes the > most active components. > > >> I'm cc'ing this reply to users mailing list to see if there are any >> opinions from folks only on that list. >> >> Cheers >> Dan > > -- > Adam > -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541

Re: [DISCUSS] - Apache Isis Application Suites: Time Tracking and Project Managent System

n Isis application ? > > Best > Maurizio > > 2013/2/5 Minto van der Sluis > >> Hi Mohammad, >> >> Do you know about eHour? >> >> http://ehour.nl/ >> >> Regards, >> >> Minto >>

Re: [DISCUSS] - Apache Isis Application Suites: Time Tracking and Project Managent System

us around the idea > > [1] http://markmail.org/message/xt6cdum5ye5pph5h > [2] I am talking about tasks in general, not technical tasks which can be > reported and tracked by JIRA. Even in the case of JIRA it is not that easy > to use it in that context > [3] http://www.attask.com/ > -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541

Re: Field validation on getters?

Hi Dan, I just created ISIS-325 Regards, Minto Op 3-2-2013 16:04, Dan Haywood schreef: > On 2 February 2013 15:29, Minto van der Sluis wrote: > >> Hi Folks, >> >> In the quickstart ToDo application I just noticed the following: >> >> @RegEx( v

[jira] [Created] (ISIS-325) Field validation annotations should be on setters or fields instead of on the getters.

Minto van der Sluis created ISIS-325: Summary: Field validation annotations should be on setters or fields instead of on the getters. Key: ISIS-325 URL: https://issues.apache.org/jira/browse/ISIS-325

Re: Why is ISIS-227 needed?

her. > > I've copied-n-pasted the above as a comment onto the ticket. > > Dan > > On 3 February 2013 10:38, Minto van der Sluis wrote: > >> Hi Dan, >> >> Can you explain why ISIS-227 was needed? I understand what it does, but >> not why it was n

Why is ISIS-227 needed?

Hi Dan, Can you explain why ISIS-227 was needed? I understand what it does, but not why it was needed. Regards, Minto -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541

[jira] [Created] (ISIS-324) ToDoItem.compare compares against itself.

Minto van der Sluis created ISIS-324: Summary: ToDoItem.compare compares against itself. Key: ISIS-324 URL: https://issues.apache.org/jira/browse/ISIS-324 Project: Isis Issue Type: Bug

Field validation on getters?

Hi Folks, In the quickstart ToDo application I just noticed the following: @RegEx( validation = "\\w[@&:\\-\\,\\.\\+ \\w]*" ) // words, spaces and selected punctuation @MemberOrder( sequence = "2" ) public String getDescription() { ... To me it seems like validation is specif

Re: More random thoughts, graph based object-store

Hi, I guess most people involved with Apache Isis or NO in general probably envision some bigger picture. Here's mine: My vision is a completely generic online environment where applications can be created through point and click. Sort of like Visual Basic, but not with the emphasize on de GUI b

Re: More random thoughts, graph based object-store

Op 1-2-2013 13:40, Dan Haywood schreef: > I think I'd rather look into see whether DN can work with NoSQL DBs (as > apparently JDO supports). Agreed DN is the easy way out. But currently DN only support 2 graph databases (neo4j and orientDB). Of course is would be possible to have DN support Tinke

More random thoughts, graph based object-store

scene. [1] http://www.tinkerpop.com/ [2] https://github.com/tinkerpop/blueprints/wiki Regards, Minto -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV

Re: Oehhh, that would be nice

. > So perhaps as part of that I'll fill in some of the missing gaps. I am willing to help out here, just to improve my knowledge on RO. This comes in handy if I ever DO embark on writing a client RO viewer. To begin with are there small steps that I could perform to improve the existin

Re: Oehhh, that would be nice

t; Cheers > Dan > > [1] https://github.com/danhaywood/ro-winstoreapp > > > On 31 January 2013 20:55, Minto van der Sluis wrote: > >> Hi folks, >> >> Just stumbled upon http://www.codenameone.com >> >> It would be nice to have an Isis and/or RestfullObjec

Oehhh, that would be nice

Hi folks, Just stumbled upon http://www.codenameone.com It would be nice to have an Isis and/or RestfullObjects viewer for Codename One. Just a thought I wanted to share :-) Regards, Minto -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV

Re: [DISCUSS] should we use slf4j rather than log4j

gt; for core, jdo, wicket, restful and shiro (ie the components currently > released as 1.0.0 or greater) > > Opinions? > > [1] http://logging.apache.org/ > [2] http://www.slf4j.org/ > [3] http://www.slf4j.org/manual.html > [4] http://www.slf4j.org/migrator.html > -- ir. ing

JIRA still uses incubator mail address

Hi folks, I just noticed that email messages send from Jira still has the Isis incubator mail address in the subject line: isis-...@incubator.apache.org Shouldn't this be changed? Regards, Minto -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV

Re: [VOTE] adopt semantic versioning

uot; components. HOWEVER, I recall that one > of the plugins we use for release - can't remember which one just now - has > a bug meaning that we cannot do this even if we wanted to. > > [1] http://semver.org. > [2] > http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html > -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541

Re: [DISCUSSION] Making releases easier and more frequent

ll subdirectories, then >> I >>>> think I would prefer if git repositories were grouped by technology >> (e.g. >>>> "sql, jdo",etc for datastores (which would contain the security, etc >>>> packages). Viewers, etc, are probably not affected, are they? >>>> Progmodel - maybe, yes (groovy vs default (java)?). >>>> This will let me ignore (e.g. jdo) for as long as I don't need it. >> Please >>>> also consider those who may still have to pay per MB, like I used to! >> ;) >>>> >>> I thought about doing this, but I think a better solution if we are >> worried >>> about such things is to use separate git repos. Then people can just >> pull >>> down the repos that they want to work on. So, can we park this proposal >>> for now? >>> >>> Thx for the input >>> Dan >>> >>> >>> >>> >>> >>>> If some of my preferences have inconsistent consequences: e.g. >>>> directory structure with separate git repositories, please point this >> out >>>> and I'll reconsider!! >>>> >>>> Regards, >>>> Kevin >>>> >> >> >> -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541

Re: [DISCUSSION] Making releases easier and more frequent

Hi Dan, See my remarks below. Regards, Minto Op 1-12-2012 14:44, Dan Haywood schreef: > OK, so I've replied briefly to each of the most recent posts that Rob and > Kevin made, and I've now gone round the loop again with the wiki page. > > This time I've listed out each and every of the current

Re: [DISCUSSION] Making releases easier and more frequent

here is the >>>> deployment of >>>> binary artifacts up to the Maven central repo. This, after all, is >>>> what >>>> most users/would-be users in the community would use and consider a >>>> release. However, Apache's own formal definition of "release" is >>>> actually >>>> the source code release ... this is what the [VOTE] mechanism is >>>> for. I >>>> don't see this changing... the vote basically says that the software >>>> complies with all the legal license stuff etc. The whole codebase is >>>> tagged >>>> with that release number, and the generated src.zip is a zip of this >>>> release. >>>> >>>> One benefit of this is that it allows the deployment of other >>>> modules to >>>> be >>>> performed "after the fact". For example, suppose that I (Dan) puts >>>> out the >>>> v0.3.1 release as above, and then Rob later on tests the scimpi >>>> viewer in >>>> that tag and finds it works well. He can (I think) push the release >>>> of the >>>> scimpi viewer up to Maven central repo. >>>> >>>> As I see things there are several benefits to this scheme: >>>> >>>> a) (as already noted) the user community will only see binary releases >>>> that >>>> are known to be of production ready. This should mitigate the "is >>>> it safe >>>> to use this component" worry >>>> b) (as hinted at) it should be possible for individual contributors >>>> to put >>>> out releases of their modules more rapidly >>>> c) we get visibility of which modules aren't being released; for >>>> example, >>>> we might say that if a module hasn't been released by anyone for 18 >>>> or 24 >>>> months, say, then it's probably time to remove it from the codebase. >>>> >>>> ~~~ >>>> >>>> In order to support the above scheme, I propose that we rearrange >>>> some of >>>> the modules so that they can be more easily included within Maven >>>> modules. I've >>>> created a page on our wiki [1] which shows my proposed >>>> rearrangement. It >>>> also repeats the above discussion text by way of context. >>>> >>>> >>>> Opinions welcome! >>>> >>>> Thx >>>> >>>> Dan >>>> >>>> >>>> [1] >>>> https://cwiki.apache.org/**confluence/display/ISIS/Make+** >>>> releases+easier+and+more+**frequent<https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent> >>>> >>>> >>>> > -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541

Why is the pluginRepository restricted Codehaus only

makes the build download the nucleus maven plugin. Regards, Minto -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV