I just set the project.build.sourceEncoding to UTF-8 in the root pom.xml file. Update your clone to try it out. That should tell the maven compiler how to treat the files and remove the message about the build being platform dependent. If there is still a problem then maybe I need something at the git level.
If you look at the contents of fixture/src/main/java/onaboat/domain/model/location/SampleLocations.java, is the second character of Göteborg corrupted? On Sun, Feb 10, 2013 at 11:16 AM, Dan Haywood <d...@haywood-associates.co.uk>wrote: > If there is a setting, we should probably add it to the archetype too. > > Dan > On 10 Feb 2013 17:13, "Adam Howard" <howard.a...@gmail.com> wrote: > > > 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 > > <christian.steineb...@marintek.sintef.no> wrote: > > > > > I guess it's the ø in Gøteborg. I had the same problem. > > > > > > Christian > > > > > > > > > ________________________________________ > > > From: Mark Wood-Patrick [mwoodpatr...@gmail.com] > > > Sent: Sunday, February 10, 2013 5:18 PM > > > To: users@isis.apache.org > > > 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:d...@haywood-associates.co.uk] > > > Sent: Friday, February 08, 2013 11:28 AM > > > To: users@isis.apache.org > > > Subject: Re: Porting dddsample app > > > > > > On 8 February 2013 03:44, Adam Howard <howard.a...@gmail.com> 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 > > > > > >
