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

Reply via email to