Ah ok, gotcha.
On 12 February 2013 13:09, Minto van der Sluis <[email protected]> wrote: > 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 <[email protected]> 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 < > >> [email protected]>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 > >
