Hi Dan, Simplified as in exchanging JDO for the default in-memory object store.
The ToDo model is still there, but JDO annotations were removed. Also the JDO based repository is removed. Regards, Minto Op 12-2-2013 13:17, Dan Haywood schreef: > Hi Minto, > Nice to see you doing this. > > In what way have you simplified the archetype... it looks like most of > ToDoItem is the same as before [1] ? > > Cheers > Dan > > [1] > https://github.com/misl/Bragger/blob/master/archetype/src/main/resources/archetype-resources/dom/src/main/java/dom/todo/ToDoItem.java > > On 7 February 2013 08:18, Minto van der Sluis <mi...@xup.nl> 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. >> >> Regards, >> >> Minto >> >> >> >> [1] https://github.com/misl/Bragger >> >> Op 6-2-2013 21:30, Adam Howard schreef: >>> Replied inline. TL;DR I'm happy with the current state of the wrj >>> archetype. I think what is needed is documentation of how to go about >>> adding new components as you're working on your own project (adding a >>> different objectstore, adding junit viewer, etc.) And since I want it I >>> guess it falls on me to write it up :) >>> >>> On Tue, Feb 5, 2013 at 2:46 PM, Dan Haywood < >> d...@haywood-associates.co.uk>wrote: >>>> 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? >>>> >>> I guess that makes sense and there really are just a handful of files >> that >>> need to be edited or deleted: >>> - TodoItem.java >>> - TodoItems.java >>> - TodoItemsFixture.java >>> - TodoItemsFixtureService.java >>> - TodoItemsJdo.java >>> - welcome.html >>> >>> And now that you mention it I have referred back to the annotations and >>> patterns used in those files when writing my own classes so maybe it's a >>> good thing. One question: can the pom <name> field be set during >> archetype >>> creation? Right now I enter my choice for group and artifact ids but the >>> name is always "Quickstart Wicket/Restful/JDO App". >>> >>> 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 >>>> >>> So I turned jdo support back on and immediately had to add >>> PersistenceCapable annotations to my classes (both entities and value >>> objects) and select an IdentityType and then my Fixture that creates a >> few >>> sample objects failed to run. I switched back to the in-memory store at >>> that point. It's not a lot of work to add the in-memory dependency so >> this >>> is something I can easily do on my projects. >>> >>> 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). >>> This is where things get tricky for a "default" new project archetype. My >>> preference for default viewer will be different from others default. And >>> the nature of the project can also come into play. For the project I'm >>> working on, I want to deploy to Heroku for demo purposes with minimal >>> overhead so for me that's Wicket + In-memory. Rob might want to default >> to >>> Scimpi. 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 >> >> -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541
