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.ukwrote:
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
