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
