openrpg-v2-dev

[Openrpg2 dev] First try at providing some help

[Mykel A. <my...@we...>]

Hi folks,
I'm new to OpenRPG2, although I've spent a little time using OpenRPG. My
background is as an enterprise java architect and developer.  For the last
two years, my secondary responsibilty has been doing build and deployment
process management.  That's what I'd like to talk about with OpenRPG2.

The work that's been done so far is very nice.  It seems to be lacking unit
testing, as well as integration tests between the client and server, and
that's where I think I can help.

I propose a minor structural change to the subversion repository that will
enable me to convert OpenRPG2 to a Maven2 project.  If src/openrpg2 was
moved to src/main/java/openrpg2 it would be possible then to move all the
non-java resources into a resource tree.  It would then be a simple process
to

   - develop unit tests for the existing code,
   - develop integration tests for the (currently co-located) modules
   - eventually separate the code into a modular build for greater
   development flexibility


I've had a great deal of success using maven, and for the last year maven2,
and so far I've found essentially no downside.  For people unfamiliar with
maven (http://maven.apache.org), it's a build process management system that
allows you to dictate the versions of artifacts that are required by your
application and therefore perform reliably repeatable builds.  It provides
internally generated reporting and additions to a well-structured build
process via plugins written in a variety of languages, primarily java.
Maven2 is an enormous improvement over Maven 1.

I exported the current source, generated a basic skeletal pom, and did the
site generation which I've currently published:
http://www.scarybaldcomputing.org/OpenRPG2TestSite/site/
Much of the information is spurious, since I'm not sure what all to put into
the site, but it can obviously be developed along with the application.
Many of the reports are not included, and obviously the checkstyle settings
are arbitrary.

For those who would rather not use maven to perform builds, it's simply a
matter of changing the locations of the sources and output directories .
Given that there's no ant build presently in the system, I assume most
people are using some ide (I use eclipse, but everyone's got their
preferences).  Maven can easily be invoked from within every IDE I've used
as an external app, or inside Eclipse and Netbeans using the appropriate
plugins.

Maven is a pretty small download, it provides dependency management in a
centralized location, and it's entirely open source from the Apache. Group.
Given the very minor change needed to make this happen, I think it's a way I
could initially provide significant benefit to the project and allow for
ease in generating testing and site management.

Well, that's my case.  In short, I'd like the source directory moved down 2
levels and in exchange, I'll make the project into a maven2 build and manage
that as well as attempt to contribute to the actual coding of the
application.  I understand that there's a breaking-in period for code
checkins, but if the source gets moved, I can produce a patch that will
generate the rest of the changes.  Any comments, criticisms, or other input?

Mykel

Re: [Openrpg2 dev] First try at providing some help

[Mark T. <ma...@ly...>]

Bi!  Welcome aboard!

Mykel Alvis wrote:
> Hi folks,
> I'm new to OpenRPG2, although I've spent a little time using OpenRPG. My 
> background is as an enterprise java architect and developer.  For the 
> last two years, my secondary responsibilty has been doing build and 
> deployment process management.  That's what I'd like to talk about with 
> OpenRPG2.
> 
> The work that's been done so far is very nice.  It seems to be lacking 
> unit testing, as well as integration tests between the client and 
> server, and that's where I think I can help.

I've been doing my own unit testing with stuff I've been doing using 
JUnit, putting stuff in test/, which Netbeans directly supports. 
Although Netbeans is not required to compile or to use openrpg2, it is 
the development platform that has been settled upon by the developers. 
  Netbeans works directly with ant scripts, which is the defacto build 
process for java projects, so it's very good that way.

> I propose a minor structural change to the subversion repository that 
> will enable me to convert OpenRPG2 to a Maven2 project.  If src/openrpg2 
> was moved to src/main/java/openrpg2 it would be possible then to move 
> all the non-java resources into a resource tree.  
Doing that would require that the openrpg2 project be renamed to 
main.java.openrpg2 or else the build system (and in particular the unit 
testing system) that Netbeans uses will not work.

Anyways... just a couple of comments about your OpenRPG2 faq that you 
put up on your website...
"Why is there an OpenRPG2? I thought OpenRPG was just fine..."
The actual answer to this is because OpenRPG was becoming 
unmaintainable.  It was felt that starting over from scratch was best, 
taking what we learned from our experiences with OpenRPG and applying 
that knowledge to the direction we take OpenRPG2.

"Why did you choose to write OpenRPG2 in Java instead of using the 
exiting Python code?"
Well now, you see... that's the problem right there.... "using existing 
code".  We didn't want to use *ANY* existing code... we wanted to take 
what we learned from the experience and code it from scratch.  I realize 
that concept might rub some people the wrong way in this day and age of 
so heavily supporting code reuse, but it's worth noting that copying and 
pasting is actually the WORST method of code reuse that exists.  If 
there were any bugs in the old code, copying and pasting guarantees that 
the bugs will be preserved.   The best method of code reuse is to copy 
design patterns rather than actual code, and there's absolutely no 
reason that could not be done with a from-scratch rewrite anyways.

Now, since the code is being done from scratch, why Java, and why not 
Python?   Well, the simplest reason is that for many of the things we 
would want to do, one would have needed to download other packages 
besides Python and our own project.  For example, OpenRPG1 requires not 
only Python, but also wxPython, which in turn requires wxWindows.  If we 
had done OpenRPG2 in python, these two extra requirements would have 
been present again.  Java has support for these and many other 
capabilities that we desired built right in, so there is nothing more to 
download once you have the program and a current JRE.

 >> Mark

Re: [Openrpg2 dev] First try at providing some help

[Mykel A. <my...@we...>]

Hi, Mark!

On 7/15/06, Mark Tarrabain <ma...@ly...> wrote:
>
> Bi!  Welcome aboard!


Thanks, and thanks for replying!

> background is as an enterprise java architect and developer.  For the
> > last two years, my secondary responsibilty has been doing build and
> > deployment process management.  That's what I'd like to talk about with
> > OpenRPG2.
> >
> > The work that's been done so far is very nice.  It seems to be lacking
> > unit testing, as well as integration tests between the client and
> > server, and that's where I think I can help.
>
> I've been doing my own unit testing with stuff I've been doing using
> JUnit, putting stuff in test/, which Netbeans directly supports.
> Although Netbeans is not required to compile or to use openrpg2, it is
> the development platform that has been settled upon by the developers.
>   Netbeans works directly with ant scripts, which is the defacto build
> process for java projects, so it's very good that way.


OK. I must be missing that somehow.  I don't have tests in the repo that I'm
looking at, but  I did just locate the build scripts.  I was blind.

I have no issue with netbeans.  I'm sure it's working well for everyone.
What I'm interested in is the "outside of the IDE" build that's the more
generic case.  With ant, there's always a matter of integrating dependecies
into the build and eventually that turns out to make the build script even
more complex, which I generally think of as a bad thing.  Furthermore, in
the case of Netbeans, it means that anyone who wants to actually work on the
project has to do that within Netbeans, which I don't care for.



> I propose a minor structural change to the subversion repository that
> > will enable me to convert OpenRPG2 to a Maven2 project.  If src/openrpg2
> > was moved to src/main/java/openrpg2 it would be possible then to move
> > all the non-java resources into a resource tree.
> Doing that would require that the openrpg2 project be renamed to
> main.java.openrpg2 or else the build system (and in particular the unit
> testing system) that Netbeans uses will not work.


Actually, I revise my statement.  It would also require a change in a couple
of lines of the project.properties file to point to the new sources in
src/main/java.  It would not require a package structure change at all.  I
just imported the build into netbeans, moved the directories, changed the
source files, and all appears to be well.  With the maven2 netbeans modules
installed, it would make continuous integration builds,dep mgt, and site gen
a pretty simple thing.  I've just installed the netbeans maven module and
it's pretty cool.  Continuum (continuous integration) server integration,
settings and build profile management and some other cool stuff.

Anyways... just a couple of comments about your OpenRPG2 faq that you
> put up on your website...


 That was just to provide an example of what maven produces as part of it's
plugins, but obviously the (real) answers to those questions are always
valuable. :)

"Why is there an OpenRPG2? I thought OpenRPG was just fine..."
> The actual answer to this is because OpenRPG was becoming
> unmaintainable.  It was felt that starting over from scratch was best,
>
.
> .
> .
>
had done OpenRPG2 in python, these two extra requirements would have
> been present again.  Java has support for these and many other
> capabilities that we desired built right in, so there is nothing more to
> download once you have the program and a current JRE.


Thanks!  I actually intuited most of those answers from having used
OpenRPG.  Trying to get OpenRPG1 to work on a friend's Mac was not a fun
process.  In any case, I'll save this post and put them in the site faq if
we ever make one.
I'm not a Python person myself (although I don't have religious views about
it or any other language except a burning desire to never write Cobol again
as long as I live).  I've been pretty consistently hooked on Java since
about '97 or '98 (back when it really sucked) and I can certainly understand
picking it over python as a transportable app.

I didn't and don't want to interrupt anyone's work.  I've just put in my
time managing ant builds.  Frankly the idea of doing it again creeps me
out.  Eventually, ant's flexibility becomes works to it's detriment.  When
there are half a dozen build scripts with multiple targets, one calling
another, it becomes a bit serpentine.  It's effective, but difficult to
navigate and eventually becomes a developer barrier to entry any system with
more than a little complexity.  Even with NetBeans managing most of the
process, it will eventually become another problem to deal with.
I'm not promoting Maven as the kool-aid everyone should drink, although
practically every argument against can be met with a solid rebuttal.  And it
doesn't really make anyone's job exceptionally easier.  It just makes the
entire development process easier and provides dependency management and
site generation practically for free.

In any case, that's sort-of one vote against making OpenRPG a maven project,
although I think I can convince everyone that it'll be better than sliced
bread. :)   The existing ant builds could easily co-exist with the maven
build, I think.
I won't push the issue, but frankly it seems difficult to figure out where
to help.  If it turns out that are willing to move the source trees, let me
know and I'll write up the directions for modification to the project.

Thanks again!
Mykel

-- 

Never wear anything that panics the cat. -- P. J. O'Rourke

Re: [Openrpg2 dev] First try at providing some help

[Mark T. <ma...@ly...>]

Mykel Alvis wrote:
> OK. I must be missing that somehow.  I don't have tests in the repo that 
> I'm looking at, but  I did just locate the build scripts.  I was blind.
The tests/ directory doesn't exist in the svn repository, but you can 
make one yourself, as I did.   It wouldn't be a bad idea to have the 
directory in the svn repository anyways with a few JUnit tests in it for 
individual classes to give developers examples to follow.

> I have no issue with netbeans.  I'm sure it's working well for 
> everyone.  What I'm interested in is the "outside of the IDE" build 
> that's the more generic case.  With ant, there's always a matter of 
> integrating dependecies into the build and eventually that turns out to 
> make the build script even more complex, which I generally think of as a 
> bad thing.  Furthermore, in the case of Netbeans, it means that anyone 
> who wants to actually work on the project has to do that within 
> Netbeans, which I don't care for.

No, not at all.  The ant build files supplied with OpenRPG2 are made so 
that any new files put into the source tree are automatically included 
into the build in the appropriate package or directory inside the jar 
file.   This means that the maintenance on the build file drops to 
effectively zero as there is no need to handle more dependencies or 
targets than what is already there.   A developer could actually use any 
development environment they wanted, or even just a plain text editor. 
It will not cause problems in any way for anyone else if their work is 
added to the repository.

 >> Mark

Re: [Openrpg2 dev] First try at providing some help

[Mark T. <ma...@ly...>]

Mykel Alvis wrote:
> That's falling-down easy.  Make the endpoint artifact an uberjar.  This 
> is a type of jar that's a "Jar of jars" that starts by running an 
> internal classload (pointing inside itself) and running whatever the 
> original main is off that classloader.  It impacts the load-time 
> performance somewhat, but not unacceptably for OpenRPG2s purposes.
I'm not sure how that gains anything... you'd have to encapsulate the 
common stuff into both the client and server "uberjar" files then 
anyways... why not just put them directly in the client and server plain 
jar files?

> I've got to admit, the whole "No external library dependencies" sounds 
> pretty painful.  I think the last time I tried that was the first time I 
> tried it. :)  Currently, I just can't come up with a good reason for 
> doing that in a java app.
It's less extra stuff for developers to have to download and install. 
Remember, we didn't even want developers to be forced to install 
Netbeans if they didn't want to... they could just use their favorite 
text editor instead.

Is that a good reason?

 >> Mark

Re: [Openrpg2 dev] First try at providing some help

[Mykel A. <my...@we...>]

>
> Anyways... just a couple of comments about your OpenRPG2 faq that you
> put up on your website...
> "Why is there an OpenRPG2? I thought OpenRPG was just fine..."
>

And in case it didn't come out correctly in my post, I didn't mean to imply
glib-ness in the "answers" to the FAQ questions I came up with, or with the
questions either for that matter.  Those answers were simply placeholders
and not ever meant to actually see the light of day. :)

-- 

Never wear anything that panics the cat. -- P. J. O'Rourke

Re: [Openrpg2 dev] First try at providing some help

[Snowdog <sn...@ga...>]

Mark Tarrabain wrote:
> Mykel Alvis wrote:
>> OK. I must be missing that somehow.  I don't have tests in the repo that 
>> I'm looking at, but  I did just locate the build scripts.  I was blind.
> The tests/ directory doesn't exist in the svn repository, but you can 
> make one yourself, as I did.   It wouldn't be a bad idea to have the 
> directory in the svn repository anyways with a few JUnit tests in it for 
> individual classes to give developers examples to follow.

The only reason the unit test directory doesn't exist in the SVN is that 
  I never wrote any tests (at least none that were legitimate 'unit 
tests') while coding the majority of the core code. If unit tests have 
since been created by all means post a patch file to the tracker and 
I'll push them into the SVN repository.

> 
>> I have no issue with netbeans.  I'm sure it's working well for 
>> everyone.  What I'm interested in is the "outside of the IDE" build 
>> that's the more generic case.  With ant, there's always a matter of 
>> integrating dependecies into the build and eventually that turns out to 
>> make the build script even more complex, which I generally think of as a 
>> bad thing.  Furthermore, in the case of Netbeans, it means that anyone 
>> who wants to actually work on the project has to do that within 
>> Netbeans, which I don't care for.
> 
> No, not at all.  The ant build files supplied with OpenRPG2 are made so 
> that any new files put into the source tree are automatically included 
> into the build in the appropriate package or directory inside the jar 
> file.   This means that the maintenance on the build file drops to 
> effectively zero as there is no need to handle more dependencies or 
> targets than what is already there.   A developer could actually use any 
> development environment they wanted, or even just a plain text editor. 
> It will not cause problems in any way for anyone else if their work is 
> added to the repository.

As Mark points out we are not using complex ant build files. The ant 
build scripts simply make the assumption that everything must be 
compiled. Which is usually not a problem after an initial full compile 
most of the compiled source stays static and doesn't need to be recompiled.

As for dependencies: its really amazing how useful javac error messages 
are, they do a wonderful job of letting you know you forgot something. 
;-) Seriously though the current ant scripts make sure the entire source 
tree is compiled properly during the build process.

--Snowdog

Re: [Openrpg2 dev] First try at providing some help

[Mykel A. <my...@we...>]

On 7/17/06, Snowdog <sn...@ga...> wrote:

> As for dependencies: its really amazing how useful javac error messages
> are, they do a wonderful job of letting you know you forgot something.


No argument about java's ability to blow up when it's missing a dependency,
but that's not what maven is all about.  Maven actually retrieves the
specified dependencies (generally from http://www.ibiblio.org/maven2 ),
stores them in your local repository, and links them in at the appropriate
phase of the build life-cycle (generate-sources, compile, test, package,
etc).  More specifically, maven picks specific versions of dependencies, so
that future builds are replicable, which is pretty tough without actually
putting the dependencies into the source repository.


;-) Seriously though the current ant scripts make sure the entire source
> tree is compiled properly during the build process.


I did the netbeans thing, made a project, and saw the very reasonable ant
scripts it generated.  I'm totally sure that, for the nonce, those builds
will be fine.  But they're already starting to mutate a bit, with a couple
of "add-on" builds.  Someday soon there'll be a few more, and a few more
targets in the existing ones.  If OpenRPG2 becomes the size that I'm
positively sure it will, assuming it reaches its goals, those build scripts
will have grown quite a bit.  If the past is an accurate indicator,
eventually you'll need documentation for your ant scripts.  And we all know
how much we like to write documentation... :)

Maven reduces the need for that by producing a structure that makes
artifacts that are the same (like jars) have the same source/resource/test
code layout.  That way, anyone learning one module can effectively start
working on any module without having to learn its source/dependency
structure.  There's nothing wrong with having ant builds.  Maven's just does
a lot more.  It's a pain to set up in the beginning, but in the end it pays
for itself in documentation, ease of packaging, and test management.

As I said, I'm not going to push the issue.  I didn't (and don't) think it'd
be a big deal to move a source tree, but if it's going to be a problem, then
it's going to be a problem.  It just means that I can't do much of anything
with maven, like generate the site I set up or post it into my continuous
integration server.  I'll wait and see if something comes up to work on.

Mykel

-- 

Never wear anything that panics the cat. -- P. J. O'Rourke

Re: [Openrpg2 dev] First try at providing some help

[Mark T. <ma...@ly...>]

Bear in mind that it is an explicit goal for this project to have as few 
external dependencies as possible.   If you wish to use Maven for your 
own development in OpenRPG2, you can go right ahead... if, however, it 
requires other developers to download and install it in order to make 
use of your contributions, then that's where it won't do.  It is 
preferable that OpenRPG2 development continue to _not_ be dependent on 
any other facilities than a current JDK and ant.  Any development tool 
or project manager chosen by any particular developer should not 
introduce any more external requirements for anyone else than these, and 
ideally should work directly with them (although the latter 
functionality is not strictly required).

You know, I have to wonder why you need to rename src/ to 
src/main/java/openrpg2 anyways... there already *IS* a src/openrpg2 
directory representing the openrpg2 package that contains the client and 
server programs.   Even files that are not actually going to be put into 
the openrpg2 package can still have their own directories in src/ 
without any changes to existing build scripts.   Further, this project 
will always be entirely in Java, so the java/ directory is redundant. 
The directory main/ is also unnecessary, as we have the main files in 
src/openrpg2/,  and the non-main files in subdirectories off of that.
 >> Mark

Re: [Openrpg2 dev] First try at providing some help

[Mykel A. <my...@we...>]

On 7/17/06, Mark Tarrabain <ma...@ly...> wrote:
>
> Bear in mind that it is an explicit goal for this project to have as few
> external dependencies as possible.   If you wish to use Maven for your

.
.
.

> introduce any more external requirements for anyone else than these, and
> ideally should work directly with them (although the latter
> functionality is not strictly required).


That's cool.  Once again, I don't actually care.  It's value-add simply
outweighs the costs.  Having spent an hour or so going over the existing
build.xml scripts, they're pretty neat.  In fact, they're essentially a
scaled-down, project-specific set of commands that mirror very closely some
of the Maven build lifecycle (sans any of the other goodies, like
integration tests or distribution packaging).

You know, I have to wonder why you need to rename src/ to
> src/main/java/openrpg2 anyways... there already *IS* a src/openrpg2
>
{ Mykel cut and pasted the following comment so it could be answered
> > together with the previous one, since the response is essentially the same.
> > }
> >
> The directory main/ is also unnecessary, as we have the main files in
> src/openrpg2/,  and the non-main files in subdirectories off of that.


While appearing to be true, these statements are misleading:

   - src/ is a directory.  It could be named anything as long as the
   builder (ant in this case) understood that that's where source was.
   - Underneath src/ is the start of the package structure. src/openrpg2
   is not a directory.  It is is the root of the openrpg package and is, as far
   as java is concerned, off limits to discussion once you get past the
   "src/".

They're two different concepts that manifest themselves on the filesystem
identically, and it's perilous not to distinguish between them.

directory representing the openrpg2 package that contains the client and
> server programs.   Even files that are not actually going to be put into
> the openrpg2 package can still have their own directories in src/
>
>
If you're interested in learning about it, I'll refer you to the Maven docs
(http://maven.apache.org/guides/getting-started/index.html) for that, but
the shorter answer is that in every maven project, everything is (supposed)
to be in the (Maven dictated) correct location.  It's a case of "convention
over configuration" and the java source lives in src/main/java, resources
live in src/main/resources, and that's just the way maven works best.  It
seems a bit tyrannical at first, and it is.  But after you realize that you
can generate a new module, include it in a multi-module build and produce a
coherent app with about a dozen lines of a POM (the maven project
descriptor) instead of a couple hundred lines of ant build files, it get's a
lot more palatable.  Coupled with the automatic site documentation and
reporting (the site I produced took about 8 minutes to create all the
necessary files and can easily be internationalized), the automated running
of tests as simply part of the build process, the ability to separate unit
tests from integration tests in the testing phases, etc, maven simply makes
it easier for everyone to keep track of the health of the project.

On a different note, and pertinent more to the second comment, having the
source coincidental with resources is odd to the degree I haven't seen that
in years and years.  I found a long while back, long before Maven, that
keeping resources separate from actual source that was to be compiled made
my life a lot easier and strongly suggest making an additional resources
directory that doesn't live in the java source tree.  This goes true for any
classification of source, be it web service descriptors, grammars,
deployment descriptors that are processed as a group, or whatever.
For the netbeans project, you'd just need to add another source directory
for the externalized resource.

Since we're talking theoretically here, I'll try and explain the Maven
methodology.

Maven is a pattern for build management (usually java projects), in the way
that Publish/Subscribe is a pattern for inter-component communications. The
pattern for Maven is that every Maven project produces exactly 1 artifact.
Every project has the same configuration of source (input) and compiled
(output) trees.  The artifact is generated by java source in src/main/java
and resources in src/main/resources.  Tests are run in the test phase by
combining the src/main java and resources and src/test/java and
src/test/resources, with the resources possibly overriding the
src/main/resources but not under good circumstances.  Integration tests are
run as sub-projects under an integration-tests directory. Web apps are
generated from java source, resources, and the contents of src/main/webapp.
Webservices WSDL sources are kept in src/main/wsdl.  Antlr grammars are kept
in src/main/antlr.  The pattern goes on for various other types of sources.
Thus, when you package the jar (in the package phase), it takes all the
classes (which are generated in target/classes) and all the resources, which
are copied into target/classes, and jars up the contents of target/classes
to make a jar.  Something similar happens when your packaging is "war" or
"ear" or any of the other sorts of packaging that are possible.

As for limiting developer dependencies in a largish app, well, all I can
really say is...it's nice work when you can get it.  I understand about a
desire not to do large installs.  Maven is (initially) a couple megs of
download, and for the netbeans people there's a couple megs of download for
the maven modules, which work superbly  (quite a bit better than the eclipse
ones, at the moment...makes it almost worth switching away from eclipse if
it wasn't for the lack of subversion integration).

If, on the other hand, you're talking about limiting external code
dependencies (i.e. third-party jars), then that's a lot harder to get away
with and essentially pointless given that the java runtime is the expected
execution environment.  There's no reason to re-invent the wheel (or the
web-server) and other people are focused on those things, often intently.

At the end of the OpenRPG2 dev process, I can see something like the
following:

   1. openrpg-client-2.0.jar  that is the client
   2. openrpg-server-2.0.jar  that is the server
   3. openrpg-commonutils-1.0.jar that  common code that the client and
   server share.  There might be one of these types of libraries; there might
   be 10.  It makes a lot of sense to break elements of coding up into
   different jars and project-manage them seperately, and very little not to.
   4. A dozen-ish external libraries, doing everything from logging
   functions to date/time management to database access to being a running
   web-server to whatever else needs to be included
   5. openrpg-foo-plugin-1.0.jar  that is some system-level plugin that's
   distributed with the base package
   6. openrpg-bar-plugin-1.0.jar that is some other system level plugin
   7. openrpg-resources-minis-1.0.jar  that is a packaging of some
   "standard" resource set as a package, thus making it possible to:


   - Distribute packaged adventures as a single jar, (equivalent to a
      Game Tree in OpenRPG1 but it could also contain portable binary resources
      like sounds, images, or whatever as resources rather than web-references)
      - Make that jar obfuscatable and signable
      - Make it easy to distribute the jars internally via a mini
      web-server within openrpg rather than having to distribute individual
      resources one at a time

In that little world, 1, 2, and 3 are would be separate (and occasionally
inter-dependent) artifacts to Maven, much the way they'll eventually have to
be to ant (except it'll be harder to do).  Instances of 7 would be generated
by the client, of course, allowing the user to jar up their "tree",
obfuscate it, sign it, and ship it out to the players by having her client
notify the server.  And, of course, there might be a plugin system for
extending the game via implementation of various interfaces and setting of
configurations, which is what 5 and 6 might be.  You might try and
standardize on various third-party libraries to minimize the variance, but
not using existing code is tough, given that much of it has been extensively
vetted.

without any changes to existing build scripts.   Further, this project


That's because the build.xml has a property set that determines that,
generate by the netbeans project.  Currently, if you place any .java source
in src/ at any level of a package and/or directory tree, the java compiler
will try to compile it as a java source and the package defs have to be
right or it'll fail.  Since all this code should be in the openrpg package
(is that correct?) .  If we were following the guidelines more strictly, the
code would be in net.sourceforge.openrpg or more likely com.openrpg, but
that's package quibbling.  In any case, the contents of src are currently
given an attempted compile by the build, so one needs to take care about
where one places things under src.

will always be entirely in Java, so the java/ directory is redundant.


While essentially true, that's more restrictive than it needs to be.  I
agree (and support) that it's a good idea for the app to be written in java
as much as possible, but what about source-generation tools (like wscompile,
axis, modello, etc).  They don't take java as source, but rather other types
of files.  And who knows what happens in 2 years, when maybe we're at
version 2.9 and we've released the "openrpg2-jython-plugin" and the
"openrpg2-lua-plugin" or whatever and we want to include source from those
languages as resources in the output.

As a continuation to something I said previously, the reason for a
src/main/java rather than just src/ is to distinguish it first from the
various test phases of development and secondly, to distinguish from other
potential types of source (webapp source, grammars, wsdls, etc) as well as
.   That way, rather than someone asking "Where are the WSDLs for the Foo
service?" they'll know that they're in the src/main/wsdl directory.  They
could know that because that's where all WSDLs would be.  Same goes true for
antlr grammars (I keep using this example because they're the current thorn
in my side back in the Real World :)  ).  All such thingies would be in
src/main/antlr because that's where the antlr plugin for Maven is expecting
them to be.  Where are the unit tests?  They're in src/test/java and their
resources are in src/test/resources.  If you put them somewhere else, you'd
have to change the default plugin configuration and in Maven, it's just
easier to put them in the place they're expected.  If you added them to the
ant build, you'd have to change project.properties to reflect that change.
Fortunately, netbeans does that for you when you manually modify the source
trees using the "Netbeans project Properties" editor, but it's still got to
be done.

Anyway, that was a lot more than I meant to write.  I hope it wasn't
terribly disjointed, and I'm sorry if I started sounding like Ben Stein from
"Ferris Beuller's Day Off".  This is a discussion I have with somebody new
about once a week, since my current contract at my day job is to repair a
broken build process.  Since I was brought in to solidify their existing
Maven2 build, I don't actually have to justify any of the reasons because
the suits have already signed off on that.  I also want to thank you guys
for your feedback.  It's great to be able to evangelize Maven to new people,
because they ask questions that I occasionally have to go back and think
about to answer.  Fortunately, rather than having to rely on faith like
religion would, the empirical output of a smooth Maven build is very
quantifiable.  Still, it's great to have someone else's input into my own
thinking, especially if they challenge something that I've long-accepted.

Thanks again, and as always, I'm interested in what everyone thinks and why
they think it.  Especially if they disagree. :)

Mykel

-- 

Never wear anything that panics the cat. -- P. J. O'Rourke

Re: [Openrpg2 dev] First try at providing some help

[Mark T. <ma...@ly...>]

Mykel Alvis wrote:
>    1. openrpg-client-2.0.jar  that is the client
>    2. openrpg-server-2.0.jar  that is the server
Yup.

>    3. openrpg-commonutils-1.0.jar that  common code that the client and
>       server share.  There might be one of these types of libraries;
>       there might be 10.  It makes a lot of sense to break elements of
>       coding up into different jars and project-manage them seperately,
>       and very little not to.
Common stuff is included in both the client and server jar files 
already.  It's done this way so that all dependency errors are caught at 
compile-time (by the JDK, not by some other external tool), and so that 
the client and server jar files provided are easy to execute (ie, 
self-executing).   If you know a way to keep them self-executing and 
still put common stuff in a separate jar file that happens to reside in 
the same directory (without having to append anything to the classpath), 
I'd be very interested in hearing about it.

>    4. A dozen-ish external libraries, doing everything from logging
>       functions to date/time management to database access to being a
>       running web-server to whatever else needs to be included
I believe it is a design goal for OpenRPG2 to have no external libraries 
in this project.  None.  Zero.  Everything is to be dependent on the 
JRE, nothing more.

>    5. openrpg-foo-plugin-1.0.jar  that is some system-level plugin
>       that's distributed with the base package
>    6. openrpg-bar-plugin-1.0.jar that is some other system level plugin
Plugins that come with the base package might very well be given their 
own directory in the hierarchy, and this I can see requiring a small 
change to the ant build file to accomodate it, but if done correctly it 
will not require any further changes to the ant build file, regardless 
of how many plugins we add.

>    7. openrpg-resources-minis-1.0.jar   that is a packaging of some
>       "standard" resource set as a package, thus making it possible to:
>           o Distribute packaged adventures as a single jar, (equivalent
>             to a Game Tree in OpenRPG1 but it could also contain
>             portable binary resources like sounds, images, or whatever
>             as resources rather than web-references)
These things would not be part of the openrpg2 project itself, but would 
be available as separate downloads on the openrpg2 website.

>           o Make that jar obfuscatable and signable
Nothing that is part of this project will be obfuscated or renderered 
inalterable by other people.  People can design their own addons or 
resources and sign them if they wish, and the capability of dealing with 
such resources may be added to the functionality of the software but 
such resources are not and will never be part of openrpg2.

>           o Make it easy to distribute the jars internally via a mini
>             web-server within openrpg rather than having to distribute
>             individual resources one at a time
The server will provide resources to clients that connect to it only as 
required... if the DM wants to use a local file for a resource, it will 
be distributed to each of the other clients that is in the same room as 
necessary.

> In that little world, 1, 2, and 3 are would be separate (and 
> occasionally inter-dependent) artifacts to Maven, much the way they'll 
> eventually have to be to ant (except it'll be harder to do).  Instances 
> of 7 would be generated by the client, of course, allowing the user to 
> jar up their "tree", obfuscate it, sign it, and ship it out to the 
> players by having her client notify the server.
If you are talking about security issues, remember, this is just for a 
game, not real life.  If they do not want to use OpenRPG2 because it has 
no serious authentication facilities, that's their choice.   We are 
writing OpenRPG2 for people like ourselves that want a virtual game 
table, nothing more.  I do not think it is a serious problem to have the 
client implicitly trust the server it connects to because this 
connection is initiated by the client.  I likewise do not think it is a 
serious problem to have the clients implicitly trust any users that the 
server has authenticated as DM's.  If a player does not trust a 
particular DM to not crash their system, they should not join their 
game.   The intent is to design the server so that it will not be 
possible (or will hopefully be exceptionally difficult) for anyone who 
is not a server admin to affect other users on that server who are not 
all part of the same game.  Security through obscurity won't work 
anyways because this project is 100% open source.

> If we were following the 
> guidelines more strictly, the code would be in net.sourceforge.openrpg 
> or more likely com.openrpg, but that's package quibbling.
Actually, I think it's a good idea to standardize on that front... 
Snowdog, I'd like to propose that the openrpg2 package be moved to 
com.openrpg2 in the interests of standards conformance.

>  In any case, 
> the contents of src are currently given an attempted compile by the 
> build, so one needs to take care about where one places things under src.
> 
>     will always be entirely in Java, so the java/ directory is redundant.
> 
> 
> While essentially true, that's more restrictive than it needs to be.  I 
> agree (and support) that it's a good idea for the app to be written in 
> java as much as possible, but what about source-generation tools (like 
> wscompile, axis, modello, etc).  They don't take java as source, but
> rather other types of files.  And who knows what happens in 2 years, 
> when maybe we're at version 2.9 and we've released the 
> "openrpg2-jython-plugin" and the "openrpg2-lua-plugin" or whatever and 
> we want to include source from those languages as resources in the output.
While a neat idea, adding stuff like this to openrpg2 would add a 
dependency on the appropriate 3rd party tool.  For example, I myself had 
originally thought about using antlr for making the dice parser.   It 
would have been drastically more straightforward to do so, but it would 
have added another external dependency to this project, which is 
undesirable, even though antlr is freely available.  So I coded it by 
hand instead.

Re: [Openrpg2 dev] First try at providing some help

[Mykel A. <my...@we...>]

On 7/18/06, Mark Tarrabain <ma...@ly...> wrote:
>
> Mykel Alvis wrote:
> >    3. openrpg-commonutils-1.0.jar that  common code that the client and
> >       server share.  There might be one of these types of libraries;
> >       there might be 10.  It makes a lot of sense to break elements of
> >       coding up into different jars and project-manage them seperately,
> >       and very little not to.
> Common stuff is included in both the client and server jar files
> already.  It's done this way so that all dependency errors are caught at
> compile-time (by the JDK, not by some other external tool), and so that
> the client and server jar files provided are easy to execute (ie,
> self-executing).   If you know a way to keep them self-executing and
> still put common stuff in a separate jar file that happens to reside in
> the same directory (without having to append anything to the classpath),
> I'd be very interested in hearing about it.


That's falling-down easy.  Make the endpoint artifact an uberjar.  This is a
type of jar that's a "Jar of jars" that starts by running an internal
classload (pointing inside itself) and running whatever the original main is
off that classloader.  It impacts the load-time performance somewhat, but
not unacceptably for OpenRPG2s purposes.

>    4. A dozen-ish external libraries, doing everything from logging

> >       functions to date/time management to database access to being a
> >       running web-server to whatever else needs to be included
> I believe it is a design goal for OpenRPG2 to have no external libraries
> in this project.  None.  Zero.  Everything is to be dependent on the
> JRE, nothing more.


Wow.  That's about all I can say.

>    5. openrpg-foo-plugin-1.0.jar  that is some system-level plugin
> >       that's distributed with the base package
> >    6. openrpg-bar-plugin-1.0.jar that is some other system level plugin
> Plugins that come with the base package might very well be given their
> own directory in the hierarchy, and this I can see requiring a small
> change to the ant build file to accomodate it, but if done correctly it
> will not require any further changes to the ant build file, regardless
> of how many plugins we add.
>
> >    7. openrpg-resources-minis-1.0.jar   that is a packaging of some
> >       "standard" resource set as a package, thus making it possible to:
> >           o Distribute packaged adventures as a single jar, (equivalent
> >             to a Game Tree in OpenRPG1 but it could also contain
> >             portable binary resources like sounds, images, or whatever
> >             as resources rather than web-references)
> These things would not be part of the openrpg2 project itself, but would
> be available as separate downloads on the openrpg2 website.


That was just a distribution idea, actually. :)

>           o Make that jar obfuscatable and signable
> Nothing that is part of this project will be obfuscated or renderered
> inalterable by other people.  People can design their own addons or
> resources and sign them if they wish, and the capability of dealing with
> such resources may be added to the functionality of the software but
> such resources are not and will never be part of openrpg2.


You're probably right.  As I said, distributing "adventures" as a jar was
just an idea, and signing and obfuscating them is pretty simple stuff
(unless you don't want to use outside tools :) ).  This, and the ability to
encrypt the contents, is pretty powerful stuff.

>           o Make it easy to distribute the jars internally via a mini
> >             web-server within openrpg rather than having to distribute
> >             individual resources one at a time
> The server will provide resources to clients that connect to it only as
> required... if the DM wants to use a local file for a resource, it will
> be distributed to each of the other clients that is in the same room as
> necessary.


Understood.

> In that little world, 1, 2, and 3 are would be separate (and
> > occasionally inter-dependent) artifacts to Maven, much the way they'll
> > eventually have to be to ant (except it'll be harder to do).  Instances
> > of 7 would be generated by the client, of course, allowing the user to
> > jar up their "tree", obfuscate it, sign it, and ship it out to the
> > players by having her client notify the server.
> If you are talking about security issues, remember, this is just for a
> game, not real life.  If they do not want to use OpenRPG2 because it has
> no serious authentication facilities, that's their choice.   We are
> writing OpenRPG2 for people like ourselves that want a virtual game
> table, nothing more.  I do not think it is a serious problem to have the
> client implicitly trust the server it connects to because this
> connection is initiated by the client.  I likewise do not think it is a
> serious problem to have the clients implicitly trust any users that the
> server has authenticated as DM's.  If a player does not trust a
> particular DM to not crash their system, they should not join their
> game.   The intent is to design the server so that it will not be
> possible (or will hopefully be exceptionally difficult) for anyone who
> is not a server admin to affect other users on that server who are not
> all part of the same game.  Security through obscurity won't work
> anyways because this project is 100% open source.


I'm talking about security on the adventure jar idea I had.  Obviously,
nobody would care if you decompiled the client/server jars.  Sorry. That was
unclear.


> >  In any case,
> > the contents of src are currently given an attempted compile by the
> > build, so one needs to take care about where one places things under
> src.
> >
> >     will always be entirely in Java, so the java/ directory is
> redundant.
> >
> >
> > While essentially true, that's more restrictive than it needs to be.  I
> > agree (and support) that it's a good idea for the app to be written in
> > java as much as possible, but what about source-generation tools (like
> > wscompile, axis, modello, etc).  They don't take java as source, but
> > rather other types of files.  And who knows what happens in 2 years,
> > when maybe we're at version 2.9 and we've released the
> > "openrpg2-jython-plugin" and the "openrpg2-lua-plugin" or whatever and
> > we want to include source from those languages as resources in the
> output.
> While a neat idea, adding stuff like this to openrpg2 would add a
> dependency on the appropriate 3rd party tool.  For example, I myself had
> originally thought about using antlr for making the dice parser.   It
> would have been drastically more straightforward to do so, but it would
> have added another external dependency to this project, which is
> undesirable, even though antlr is freely available.  So I coded it by
> hand instead.


That was actually the place I thought it could work best. :)

I've got to admit, the whole "No external library dependencies" sounds
pretty painful.  I think the last time I tried that was the first time I
tried it. :)  Currently, I just can't come up with a good reason for doing
that in a java app.  I can TOTALLY understand with the python app.  wxPython
was a pretty tough dependency to swallow for some (specifically my Mac-using
friends).  But java just makes that stuff easy.
Coupled with a "No external tools" policy, it seems like a pretty tough row
to hoe.


-- 

Never wear anything that panics the cat. -- P. J. O'Rourke

Re: [Openrpg2 dev] First try at providing some help

[Snowdog <sn...@ga...>]

Mark Tarrabain wrote:

>> I've got to admit, the whole "No external library dependencies" sounds 
>> pretty painful.  I think the last time I tried that was the first time I 
>> tried it. :)  Currently, I just can't come up with a good reason for 
>> doing that in a java app.
> It's less extra stuff for developers to have to download and install. 
> Remember, we didn't even want developers to be forced to install 
> Netbeans if they didn't want to... they could just use their favorite 
> text editor instead.
> 
> Is that a good reason?
> 
>  >> Mark

He's referring to those packages/libs (dependencies) that would place 
into your repository Mark. Like log4j, which you'd include within your 
SVN and in turn gets bundled with your apps jar when you deploy. He is 
not referring to external separate downloads that would need to be made 
by users during an OpenRPG2 install.

--Snowdog

Re: [Openrpg2 dev] First try at providing some help

[Dj G. <dig...@gm...>]

Cant you just make a directory "src/main/java" then check out the
contents of the svn's src directory there so you can use Maven and the
other devs can use what they want without requiring a change to the
SVN directory structure. I tested that and it seemed to work just fine
for me, I could still check out the files (and check in if I was a dev
for the 2.x project) and it worked fine for Maven