Hi Adam, I have no problem with us also supporting such a blank archetype. Previously our archetypes was based on the claims example app, which was 3 domain entities rather than just the one in the current wrj archetype... the reason being to make it quickly easy to get something going. My expectation is that people would rename the ToDo class to Customer, or whatever. But if you're finding it tiresome to strip out what is in ToDo, then perhaps others do too?
With respect to using inmemory vs JDO, there's no need to write JDO-specific implementations of the repositories; a naive impl also works, even if the JDO objectstore is configured. Perhaps this isn't easy to grok from the documentation. Given that we configure the JDO objectstore to run with the inmemory HSQLDB, my thoughts are that it's pretty low ceremony already With respect to viewers, another option for a "prototyping" sort of archetype is also dnd viewer. Although we've now (since removing the client/server remoting component) pretty much deprecated this for production use, the dnd viewer has proven its worth over past years as a good modelling tool. If you look under examples/applications, you can see that there's the outline of such an application already there (though not tested recently). I also thought that this might incorporate the BDD and junit viewers (not that I've formally released those as TLP releases, yet). 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 On 5 February 2013 20:18, Adam Howard <howard.a...@gmail.com> wrote: > Hello, > > I started a new Isis project by generating from the wrj quickstart > archetype. I ran into two issues I'd like to bring up for discussion: > > 1. The archetype really specifies an application (ToDo) rather than a > starting point for my own project. It is helpful that I can see many of the > capabilities of Isis but I have to rip out all of that stuff in order to > start working on my own domain model > > 2. If I'm starting a new application I want to put off persistence for as > long as possible by utilizing the in-memory store. The wrj archetype (by > definition) assumes jdo from the start. To get the in-memory store I had to > add the dependency to a couple pom files. > > I know that at one point there was talk of creating several archetypes with > different combinations of Isis modules. I guess my question is, should the > next archetype be a "blank" project? What is the definition of "blank"? How > stripped down can we make it? > > If I'm voting I would include (on top of the core applib): Wicket viewer, > maybe RO viewer, in-memory object store, bypass auth. I may be able to put > this together and submit a pull request if there is any interest. > > Thanks. > -- > Adam >
