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
