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
