--- Log opened Mon Aug 20 00:00:55 2012
15:15 < conseo> wut? a list for a hashmap? couldn't they implement that in javascript?
15:16 < conseo> mcallan: looks like i need to do some modularizing of the code for maven, because i need to separate s at least for gwt in different packages
15:16 < conseo> votorola/s
15:19 < mcallan> conseo: not sure what you mean by modularizing
15:19 < conseo> maven has a clear package structure and modularizes in subpackages which also define their inner and outer dependencies
15:20 < conseo> you get a better dependency management through this
15:20 < conseo> atm. in s we also have the gwt-code, so i have to at least get that out of the module for maven to understand
15:21 < conseo> i will try to symlink, hoping that mercurial won't let me down
15:21 < mcallan> one thing: experiment with hg in separate branch
15:22 < conseo> sure
15:22 < conseo> i still would merge my pending stuff first and then branch
15:22 < mcallan> another: still no idea what propose for s.  yes, it has gwt code, also wicket
15:22 < mcallan> what *u* propose
15:24 < conseo> yes, and everything lands in votorola.jar. it might make sense (on the long run) to factor out application and servlet code in dedicated packages, but for now i will simply add a "mvn" folder in votorola/b and try to configure the build in there with symlinks
15:24 < conseo> we will see how far i get
15:24 < mcallan> all these symlinks will be under your b/c/ ? :-)
15:26 < conseo> yes (or better b/mvn as "c" is barely self-explicatory imo)
15:27 < conseo> i won't disturb your precious work :-
15:27 < conseo> )
15:27 < conseo> :-D
15:31 < mcallan> good fences make good neighbours, as they say in english ;-)
15:32 < conseo> i want to remove the fences collectively, but yes first you need to find the proper common approach
15:32 < mcallan> cool
15:33 < conseo> which can be done through separation (or forking if you like to call it that way)
15:37 < mcallan> fork away, ant lovers...
15:38 < conseo> no ant
15:38 < conseo> and i don't love it. i can very well understand that you prefer to write your perl build script to verbose xml declarative language
15:40 < conseo> it is just a standard interface to a code repository and i care for that because of future compatibility and integration in my workflow. i'd prefer not to rewrite the build system, but the perl scripts can never integrate that way
15:40 < mcallan> yes they can, i think you are mistaken.  they can integrate with anything, unless it's deliberately built to be ant-only
15:41 < conseo> yes they can integrate, but then i have to do it from inside of them. but no outside can understand them automatically, they then have to expose these internals in a language the outside system understands
15:42 < conseo> which will be more work in the long run imo
15:45 < mcallan> i made the opposite bet, and so far it's paid off.  gwt docs assume an eclipse build environment, but i taught gwt to our build scripts
15:46 < mcallan> now if you give me x that assumes ant build, i will teach x to our build scripts
15:47 < mcallan> or y that assumes mvn, i will teach y
15:47 < mcallan> or z that assumes netbeans ...
15:48 < conseo> yes you will do so. but then every project has its own build scripts instead of standard, duplicating a lot of work and having little or no docs. with maven, people can understand the build process and source organisation without bugging us
15:48 < conseo> only if the flexibility is necessary i would go that path
15:48 < conseo> btw. you can always hook scripts from inside the build system
15:49 < conseo> but scratching your own itch has advantages in understanding the process
15:49 < conseo> i agree, that it makes some sense and i liked your perl scripts more than xml-fu. yet the xml is easier to understand structually imo
15:55 < mcallan> honest, i thought carefully about it.  i tried different things over the years.  i never regretted settling on a general-purpose scripting language.  it's a better design.  but if you can prove me wrong over the next few years, then i'll use your maven/ant build
15:56 < conseo> i am not sure, you are more experienced, but from my experience it is good to use defaults where they fit and focus on the actual problem/new solution, but maybe i will be condemning all these magic tools soon and hack your scripts
15:56 < conseo> we will see
15:56 < conseo> ha
15:57 < conseo> like a mirror
15:57 < conseo> XD
15:58 < mcallan> XD?
16:00 < mcallan> ... anyway, truce
--- Log closed Tue Aug 21 00:00:12 2012