Interesting. I wonder if there is some git setting I need to force UTF-8. -- Adam
On Feb 10, 2013, at 10:35 AM, Christian Steinebach <[email protected]> wrote: > I guess it's the ø in Gøteborg. I had the same problem. > > Christian > > > ________________________________________ > From: Mark Wood-Patrick [[email protected]] > Sent: Sunday, February 10, 2013 5:18 PM > To: [email protected] > Subject: RE: Porting dddsample app > > I tried building the app on centos 5.8 and got the following error any > suggestions on how I can fix it? > > [INFO] > > [INFO] > ------------------------------------------------------------------------ > [INFO] Building Quickstart Wicket/Restful/JDO Fixtures 1.0-SNAPSHOT > [INFO] > ------------------------------------------------------------------------ > [INFO] > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ onaboat-fixture > --- > [INFO] > [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ > onaboat-fixture --- > [debug] execute contextualize > [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered > resources, i.e. build is platform dependent! > [INFO] skip non existing resourceDirectory > /home/app_perf_catalog/mwoodpatrick/apache/isis/onaboat/fixture/src/main/res > ources > [INFO] > [INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ > onaboat-fixture --- > [WARNING] File encoding has not been set, using platform encoding > ANSI_X3.4-1968, i.e. build is platform dependent! > [INFO] Compiling 5 source files to > /home/app_perf_catalog/mwoodpatrick/apache/isis/onaboat/fixture/target/class > es > [INFO] ------------------------------------------------------------- > [ERROR] COMPILATION ERROR : > [INFO] ------------------------------------------------------------- > [ERROR] > /home/app_perf_catalog/mwoodpatrick/apache/isis/onaboat/fixture/src/main/jav > a/onaboat/domain/model/location/SampleLocations.java:[26,75] error: > unmappable character for encoding ASCII > > [INFO] 1error > > -----Original Message----- > From: Dan Haywood [mailto:[email protected]] > Sent: Friday, February 08, 2013 11:28 AM > To: [email protected] > Subject: Re: Porting dddsample app > > On 8 February 2013 03:44, Adam Howard <[email protected]> wrote: > >> Dan, >> >> I just pushed some minor changes to the Voyage model up to github[1]. >> I took out the Collections.unmodifiableList() call so now the Voyage >> page renders with just the VoyageNumber and a link to the Schedule. I >> think the purpose of the Schedule class might be to represent the list >> of CarrierMovements as a whole rather than having the list directly on >> the Voyage. Maybe that pattern doesn't mesh well with Isis. Because >> what I want to see on the Voyage page is really what you get when you >> DO have a list of CarrierMovements directly off the Voyage: the table >> view on the right hand side. > > > Agreed. Last time I think I was asking about Schedule being, apparently, > a value type. In Isis value types aren't represented except in the context > of being owned by an entity. So, yes, I think Schedule as a value type has > to go. > > > > >> I modified Voyage to have that list accesible directly and now I see >> the table. I'm not married to making a line-by-line port of the >> original dddsample code but if there is a Ubiquitous Language reason >> for a class's presence I'd like to try to preserve it. >> >> > My suggestion would be to preserve the name "Schedule" as being the > collection of CarrierMovements in Voyage, ie: > > public class Voyage { > > public List<CarrierMovement> getSchedule() { ... } > > } > > > > >> Side note: This got me thinking about AggregateRoots. Are there any >> features in Isis that make AggregateRoots stand out? > > > ARs aren't as that important in Isis if using JDO. We do have the > @Aggregated annotation, though. This is used by the [not yet released, > Rob's baby] NoSQL objectstore to indicate which entities should be > serialized in the same JSON doc within Mongo. > > > >> Or is that really just >> a technical concern and not related to the user's mental model? >> >> > Most of the discussion and debate around ARs that I read I think relates to > a technical concern, trying to work very hard to make sure that the only > entities modified within a transaction are those contained within an > aggregate root. If one is adopting the CAP/NoSQL route, then its a valid > technical constraint that one must worry about. If using a DBMS with such > exotic things as transactions and isolation levels, then it's not really a > concern (barring deadlocks, I suppose). > > There is, though, something about ARs that does pertain to a users' mental > model. I'm pretty sure this is what Eric Evans was mostly concerned about > (though I re-read the discussion on ARs in his book yesterday, and I think > there's a hell of a lot of hand-waving). But I say what I say because - for > example - when we say Order we usually also mean its OrderLines, and when we > say Car, we usually also mean its Engine, Wheels, Doors etc. > > One can have the same discussion about mental models with respect to modules > (namespaces, packages). Over on the big Government project in Ireland we > find this i a much more important organizing concept... they talk there > about the "customer BOM" (BOM=business object model), "means BOM", > "communications BOM" etc. > > > The next problem I've run into is that my fixture[2] is not saving the full >> object graph I pass to persist. Again, I create a Voyage with a >> Schedule with a CarrierMovement and I pass the Voyage to >> getContainer().persistIfNotAlready(). My Voyage is stored and I can >> see it when I query for allInstances of Voyage.class. But, the >> CarrierMovement list is empty. Does the in-memory object store support >> persistence-by-reachability? > > > It does, but before we delve into whether there's an actual issue here in > Isis, let me just rewind on your domain object model structure. > > You've got lots of immutable classes, where the state is passed in through > the constructor. Although that's good OO design, the issue is that Isis > needs to rehydrate the objects through setters. As you know, we use > annotations to prevent the user from modifying state they shouldn't > (@Disabled). > > For example, CarrierMovement looks like its an entity, but has no setters. > Ditto Voyage. > > You might be best figuring out what the class model is for the domain, and > then porting that over (rather than a line-by-line conversion of existing > code). > > ~~~ > I also see in your SampleVoyages setter that you're instantiating using just > "new". While that might be ok in this particular case, in general you > should always use "container.newTransientInstance". Doing it this way > allows Isis to inject domain services into your entities as they are > instantiated. > > > HTH > Dan >
