javacavemaps-developers Mailing List for Java Cave Maps (Page 5)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

A caving video game is a great idea, I'd love to help out with level design. Someone start a project and I'll join it as tech support.

 Larry Gray
la...@ar...

Ok I just enabled 3 hosted apps, Lime Survey, Gallery (example cave photos and cave maps might go here) and Lanconica (a blog tool)  I can create opinion surveys using Lime Survey. I'm working on a demo test survey right now.

Thanks

 Larry Gray
la...@ar...

Also has anyone considered that I'm voluteering my time to create task and specifications and answer emails reguarding assigning of task. I'll also be doing the work in creating release files. I have to take my time to add people to the project and email them. I also take my time to alter permissions for this and that. I realize some of this can be automated. I wish sourceforge would make a Platform independent GUI tool to do the same things their web interface does, maybe with scripting of some kind. Or better yet have some way that ANT could connect and work SF task. Speaking of that I hope to begin using ANT to automate some things a little later on.

Anyway I have 50 hours a week free for thinking maybe, some of that for studying. None of that for coding or web interface work.   So after about 60 hours a week on my job I have some time for coding and web interface work.  BTW I just noticed DocBook has tags for the "view" portion of programming, it has tags for "OOP" and tags for "API" as well as tags for"command line" work. It appears to have great indexing capabilities, but I don't see anything about table of contents yet. I has some interesting "list" alternatives compared with HTML. Yes DOCBOOK has 400  tags roughly. It can be totally converted to HTML or PDF and maybe a few other formats.

I wish I had some kind of way I could poll the developers on the project. This would make for a slightly more democratic situation.  

Oh note that I didn't mention the use of Random Access files. Using RAF is reinventing the Database wheel.  However we have a great plugin capablity already designed which is JDBC. Anyone who loves database work could write their database and provide a JDBC driver if they really wanted to (not for me at this time). If someone wants to do a OpenGL plugin view of this project, then we will give them repository space.  

Oh  and this is what I meant about heavy database work; The storing of cave information including, location, directions to the cave, scientific information, information reguading safety, other interesting statistical information. For example location can be recorded using, Gas Well coordinates which are Township, Range, Section, Feet from East,North,SouthWest section lines. Location can also be Longitude Lattitude. Seems like I recal maybe one other method of getting location as well.  

A cave leads database. I have forgotten what was included in this but its mostly about who gave you the lead, contact information for those giving the lead, and information they may have given, including directions to the cave or its general location and other facts about the cave.  Its for the detective work in tracking down cave locations. Believe it or not the best method for getting lead information is to door knock in the communities that live near the caves. The database might contain the entire description for the vector graphics app that would display a map. The database could also contain survey information as an alternative to the use of XML or flat files.  We could also use XML to store the data for the Vector Graphics map. 

The reason Vector Graphics is so popular for cave mapping is that its very art like.  CAD software while good for aiding in getting the person info about line plots or in printing line plots is too mechanical looking for cave map generation. Pixel graphics software becomes too much work overall. Vector Graphics software offers great layering capabilities which aid in the drafting by allowing scans of in cave sketches to be scanned underlaid.  If we get to this point, and I think is dreamy right now, but I will try to write up specidifactions based on the features of Xara X that cavers seem to like and use. One which may be complicated to code is blending. I don't even want to explain that concept right now.

 Larry Gray
la...@ar...

For those of you that I added to the project before I introduced my plans for this project in reguards to managment, if you feel utterly like you can't can not help out in any way because of this please go ahead and remove yourself from the project. I apologize that I didn't make things clearer in the help wanted advertisement.

I have no intentions of leading this project in a direction where it turns into a video game or cad software. It may turn into vector graphics drawing software however if we ever get the basics coded.

thanks..
Larry Gray
la...@ar...

Oh I forgot about the database talk. Basically I want as we have discussed this far flat files, xml, and later when we get to heavy database work JDBC. The lighter work can still go in flat files and primarily xml files.  As far as sharing goes, the web already provides many  many ways for folks to colaborativly share data on thier own. Some kind of open sharing of cave mapping data for the application would be ok. As I have already said, I won't allow any coding that would allow open publication of full cave maps or any infromation that would lead to the cave location. We will use strong encryption and security measures to ensure that only small tight nit groups can colaborate when it comes to this kind of information. But we are talking about work that is quite a bit away from becoming reality. We are dreaming on this issue for the moment.

 Larry Gray
la...@ar...

________________________________
From: sean wagner <wa...@ya...>
To: Larry Gray <jav...@ya...>
Sent: Thursday, January 8, 2009 6:50:38 PM
Subject: Re: [Javacavemaps-developers] agile XP style development model

There is an orthogonal perspective in OpenGL I know of. I have seen some isometic models done that way. A lot of CAD programs use the orthogonal perspective, I think thats kinda the feel you are going for. 

Honestly I think what is more important to worry about though is the data layers representation. The view can always change, or you can have multiple views, but data is the hardest thing to change later on. 

Do you want to run your own database server for this application? How will data be shared amongst users? 

Also OpenGL will not work on some computer possibly older than 4 years depending on which version you use. If you do decide you want to use OpenGL you should be aware of what kind of machines your target audience will be using. If they are using an older computer we may want to use an older version of OpenGL (latest is like 2.1 I believe) since some hardware wont support the new stuff. I am unsure of which version of OpenGL Java3d is built upon I don't remember. 

--- On Thu, 1/8/09, Larry Gray <jav...@ya...> wrote:

From: Larry Gray <jav...@ya...>
Subject: Re: [Javacavemaps-developers] agile XP style development model
To: wa...@ya...
Date: Thursday, January 8, 2009, 5:00 PM

ill look into opengl for the desktop applicaton, im willing to bet it or java3d does not even deal in isometrics because it to simple and easy to code

 Larry Gray
la...@ar...

________________________________
From: sean wagner <wa...@ya...>
To: jav...@li...; Larry Gray <jav...@ya...>
Sent: Thursday, January 8, 2009 4:21:10 PM
Subject: Re: [Javacavemaps-developers] agile XP style development model

I wasn't saying I wont help. I was just saying I didn't want to participate in the 3d thing if that is the way you want to do it. It just doesn't interest me and I'm not getting paid. I will work on other aspects I find interesting, since that is why I am here.

IMO there are many libraries that are very common place in the industry and are worth throwing in to almost any app you work on big or small. These include Log4j, JUnit, some other Swing extensions. They make life easier and take less than an hour to learn. There are other libraries that take a little time to learn, but if your project is medium to large scale, they will save you a lot of time and headache in the end. A good example is where I work there was a web reporting server designed in tomcat for rendering reports from a program that collected data. This web report engine was pretty limited and had alot of javascript and stuff which was a bitch to maintain compared to java, it was all created from the ground up. Yet why reinvent the wheel? I eventually had to rewrite his reporting engine, we used JFreeReport this time. Development time was cut in half and the end result was much more detailed and robust. The original design was a waste of time.
 Morale of the story is, you shouldn't try to re-invent the wheel when you can go pick up a tire for cheaper than it takes to build a wooden wheel.

Also since this is an open source project, you will actually pull in more developers if you use the popular libraries in the field today, because they want to use them. They want to learn, they don't mind the complication. In fact most good programmers embrace the complication and think its fun.  

--- On Thu, 1/8/09, Larry Gray <jav...@ya...> wrote:

From: Larry Gray <jav...@ya...>
Subject: [Javacavemaps-developers] agile XP style development model
To: jav...@li...
Date: Thursday, January 8, 2009, 12:58 PM

Obviously each developer who joins an open source project, his mileage will vary with each type of problem and each type of solution, along with his Architect, Developer and Programmer skills sets. And his mileage will vary from api to api, from library to library.  Some developers for example may handle problems on a lager scale as quickly as new developers on much smaller problems.  Agile development limits the scale of the project as a whole and additions to the project as it moves along.  The problem is scale can not be arbitrarily increased in the name of  extendability.  The addtion of libs other than the standard api shipped with sdk adds bloat as well as complexity. For somoene who is used to that coding that lib instead of the standard lib, this seems only to this person as if the tradeoffs are imaterial.  About extendability. Refactoring is always necessary reguardless of the api's you begin with.  To think you can grab this wonderful
 extendable do it all lib and still not have to worry about refactoring is a little nieve IMHO.   Anyway under agile development model we can't up the scale based on a promise to help if that is done. However if I see I have help because task are being completed, thats a sign that the scale can be increased.  I will keep adding developers to this project until I find maybe a dirty dozen that seem to align themselve more with this process, the rest may simply watch and provide technical assitance sometimes if you really want to help. And maybe some will join in later as the project becomes more complex.

Thanks

 Larry Gray
la...@ar...

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers

Well, I was thinking we were working on a lighter, stronger, faster rodent demolition machine not reinventing the wheel.  But haha, all spin aside, since this is MVC yes the view is almost pluggable and would not take much in the way of design changes to make it totally plugable. Such as writing the specifications for the view in a more general way so that the developer may use Swing, OpenGL, AWT, SWT, or his own custom components.  I'd still like the swing version that I'm working on to be the default. I can maintain a few JPanels myself. Also If we package up a Jar as an applet say or web start app, how does another person add a Jar plugin say to the Applet or WebStart app? by posting it in the same folder on the server as the applet or webstart app? or at least on the same server in a location where the applet or ws app knows to look for plugins?

I worked office work for 6 years I used all the big name office software. As you know there are many databases.  The state departement had been licensing Microsoft office software mostly. The office I worked in had an old version of DOS Paradox database.  We needed to update some stuff to a new windows database. The director just knew we must use Paradox database because she had heard MS Access was slow. I wanted to use MS Access so she told me to do some research. I did and found an article exclaiming that the reason MS Access had been given a bad reputation in this requard is because most of the users were not away of or did not use indexing effectively. I ran some test and found that this was true. After showing her the article she let me use MS Access, which I had already invested some time in learning.

I hate to use an old cleiche but I will, Half a dozen of one and 6 of another.  Sometimes choices nearly boil down to this.  Somtimes not. When I first started mapping caves I got resistance to drawing too much detail. I got resitance to using scale that was too large so that I could get more detail in.  I got resistance to using more acurate methods and tools.  Later I got a large group of well know cave mappers to help me on a large cave. Well they did the line survey well enough but didnt listen to me at all when I was explaining the way I wanted the skecthing done. As a result I'll probably resketch small sections some time. They basically didnt provide the detail I was trying to achive.  Also some cavers are basically explorers only, and can't stand mapping.  They may occasionally help out by pulling the dumb end of the tape on a survey.  Anyway I explain to these folks that the cave itself is a geologic formation just like stalactites and flow
 stone and soda straws.  I explain that the only way to view this formation is to map the cave.  I also explain this to sketchers but usually with no results, they sketch the way they want to.  I'm not sure what this means but there it is. Everyone mapping caves is doing it for free. People help out usually so that they can get a copy of the map or find out where the cave is at.

I guess what I was getting at is this. There are lots of areas of enjoyment when it comes to developing software. Some may be more into coding logic, others maybe architecture, others managing the project and yet others trying out various methods of colaboration.  Some developers may feel they can't code any way but alone, others may want the team experiance.  The experiance of having an organized colaborative effort can only be had one way, orgainzed. Even in cave mapping we organize projects and trips and team positions. One guy is in charge of the cave being mapped, its usually the guy who started it and who is drawing up the final map.

 Larry Gray
la...@ar...

________________________________
From: sean wagner <wa...@ya...>
To: Larry Gray <jav...@ya...>
Sent: Thursday, January 8, 2009 6:50:38 PM
Subject: Re: [Javacavemaps-developers] agile XP style development model

There is an orthogonal perspective in OpenGL I know of. I have seen some isometic models done that way. A lot of CAD programs use the orthogonal perspective, I think thats kinda the feel you are going for. 

Honestly I think what is more important to worry about though is the data layers representation. The view can always change, or you can have multiple views, but data is the hardest thing to change later on. 

Do you want to run your own database server for this application? How will data be shared amongst users? 

Also OpenGL will not work on some computer possibly older than 4 years depending on which version you use. If you do decide you want to use OpenGL you should be aware of what kind of machines your target audience will be using. If they are using an older computer we may want to use an older version of OpenGL (latest is like 2.1 I believe) since some hardware wont support the new stuff. I am unsure of which version of OpenGL Java3d is built upon I don't remember. 

--- On Thu, 1/8/09, Larry Gray <jav...@ya...> wrote:

From: Larry Gray <jav...@ya...>
Subject: Re: [Javacavemaps-developers] agile XP style development model
To: wa...@ya...
Date: Thursday, January 8, 2009, 5:00 PM

ill look into opengl for the desktop applicaton, im willing to bet it or java3d does not even deal in isometrics because it to simple and easy to code

 Larry Gray
la...@ar...

________________________________
From: sean wagner <wa...@ya...>
To: jav...@li...; Larry Gray <jav...@ya...>
Sent: Thursday, January 8, 2009 4:21:10 PM
Subject: Re: [Javacavemaps-developers] agile XP style development model

I wasn't saying I wont help. I was just saying I didn't want to participate in the 3d thing if that is the way you want to do it. It just doesn't interest me and I'm not getting paid. I will work on other aspects I find interesting, since that is why I am here.

IMO there are many libraries that are very common place in the industry and are worth throwing in to almost any app you work on big or small. These include Log4j, JUnit, some other Swing extensions. They make life easier and take less than an hour to learn. There are other libraries that take a little time to learn, but if your project is medium to large scale, they will save you a lot of time and headache in the end. A good example is where I work there was a web reporting server designed in tomcat for rendering reports from a program that collected data. This web report engine was pretty limited and had alot of javascript and stuff which was a bitch to maintain compared to java, it was all created from the ground up. Yet why reinvent the wheel? I eventually had to rewrite his reporting engine, we used JFreeReport this time. Development time was cut in half and the end result was much more detailed and robust. The original design was a waste of time.
 Morale of the story is, you shouldn't try to re-invent the wheel when you can go pick up a tire for cheaper than it takes to build a wooden wheel.

Also since this is an open source project, you will actually pull in more developers if you use the popular libraries in the field today, because they want to use them. They want to learn, they don't mind the complication. In fact most good programmers embrace the complication and think its fun.  

--- On Thu, 1/8/09, Larry Gray <jav...@ya...> wrote:

From: Larry Gray <jav...@ya...>
Subject: [Javacavemaps-developers] agile XP style development model
To: jav...@li...
Date: Thursday, January 8, 2009, 12:58 PM

Obviously each developer who joins an open source project, his mileage will vary with each type of problem and each type of solution, along with his Architect, Developer and Programmer skills sets. And his mileage will vary from api to api, from library to library.  Some developers for example may handle problems on a lager scale as quickly as new developers on much smaller problems.  Agile development limits the scale of the project as a whole and additions to the project as it moves along.  The problem is scale can not be arbitrarily increased in the name of  extendability.  The addtion of libs other than the standard api shipped with sdk adds bloat as well as complexity. For somoene who is used to that coding that lib instead of the standard lib, this seems only to this person as if the tradeoffs are imaterial.  About extendability. Refactoring is always necessary reguardless of the api's you begin with.  To think you can grab this wonderful
 extendable do it all lib and still not have to worry about refactoring is a little nieve IMHO.   Anyway under agile development model we can't up the scale based on a promise to help if that is done. However if I see I have help because task are being completed, thats a sign that the scale can be increased.  I will keep adding developers to this project until I find maybe a dirty dozen that seem to align themselve more with this process, the rest may simply watch and provide technical assitance sometimes if you really want to help. And maybe some will join in later as the project becomes more complex.

Thanks

 Larry Gray
la...@ar...

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers

I wasn't saying I wont help. I was just saying I didn't want to participate in the 3d thing if that is the way you want to do it. It just doesn't interest me and I'm not getting paid. I will work on other aspects I find interesting, since that is why I am here.

IMO there are many libraries that are very common place in the industry and are worth throwing in to almost any app you work on big or small. These include Log4j, JUnit, some other Swing extensions. They make life easier and take less than an hour to learn. There are other libraries that take a little time to learn, but if your project is medium to large scale, they will save you a lot of time and headache in the end. A good example is where I work there was a web reporting server designed in tomcat for rendering reports from a program that collected data. This web report engine was pretty limited and had alot of javascript and stuff which was a bitch to maintain compared to java, it was all created from the ground up. Yet why reinvent the wheel? I eventually had to rewrite his reporting engine, we used JFreeReport this time. Development time was cut in half and the end result was much more detailed and robust. The original design was a waste of time.
 Morale of the story is, you shouldn't try to re-invent the wheel when you can go pick up a tire for cheaper than it takes to build a wooden wheel.

Also since this is an open source project, you will actually pull in more developers if you use the popular libraries in the field today, because they want to use them. They want to learn, they don't mind the complication. In fact most good programmers embrace the complication and think its fun.  

--- On Thu, 1/8/09, Larry Gray <jav...@ya...> wrote:
From: Larry Gray <jav...@ya...>
Subject: [Javacavemaps-developers] agile XP style development model
To: jav...@li...
Date: Thursday, January 8, 2009, 12:58 PM

Obviously each developer who joins an open source project, his mileage will vary with each type of problem and each type of solution, along with his Architect, Developer and Programmer skills sets. And his mileage will vary from api to api, from library to library.  Some developers for example may handle problems on a lager scale as quickly as new developers on much smaller problems.  Agile development limits the scale of the project as a whole and additions to the project as it moves along.  The problem is scale can not be arbitrarily increased in the name of  extendability.  The addtion of libs other than the standard api shipped with sdk adds bloat as well as complexity. For somoene who is used to that coding that lib instead of the standard lib, this seems only to this
 person as if the tradeoffs are imaterial.  About extendability. Refactoring is always necessary reguardless of the api's you begin with.  To think you can grab this wonderful extendable do it all lib and still not have to worry about refactoring is a little nieve IMHO.   Anyway under agile development model we can't up the scale based on a promise to help if that is done. However if I see I have help because task are being completed, thats a sign that the scale can be increased.  I will keep adding developers to this project until I find maybe a dirty dozen that seem to align themselve more with this process, the rest may simply watch and provide technical assitance sometimes if you really want to help. And maybe some will join in later as the project becomes more complex.

Thanks
 Larry Gray
la...@ar...

      ------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers

Oh, by the way, I work a career where while I'm working, I have nothing but freedom when it comes to thinking. So I have maybe 50 hours a week for simply thinking.  Its because my career requires mostly second nature skills and not much conscious thought. Especially since I'm fully trained and have been on the job 7 years now.

 Larry Gray
la...@ar...

Obviously each developer who joins an open source project, his mileage will vary with each type of problem and each type of solution, along with his Architect, Developer and Programmer skills sets. And his mileage will vary from api to api, from library to library.  Some developers for example may handle problems on a lager scale as quickly as new developers on much smaller problems.  Agile development limits the scale of the project as a whole and additions to the project as it moves along.  The problem is scale can not be arbitrarily increased in the name of  extendability.  The addtion of libs other than the standard api shipped with sdk adds bloat as well as complexity. For somoene who is used to that coding that lib instead of the standard lib, this seems only to this person as if the tradeoffs are imaterial.  About extendability. Refactoring is always necessary reguardless of the api's you begin with.  To think you can grab this wonderful
 extendable do it all lib and still not have to worry about refactoring is a little nieve IMHO.   Anyway under agile development model we can't up the scale based on a promise to help if that is done. However if I see I have help because task are being completed, thats a sign that the scale can be increased.  I will keep adding developers to this project until I find maybe a dirty dozen that seem to align themselve more with this process, the rest may simply watch and provide technical assitance sometimes if you really want to help. And maybe some will join in later as the project becomes more complex.

Thanks

 Larry Gray
la...@ar...

Well I didn't officially set task for the first iteration, but we are making headway. I'll declare the first iteration to be complete soon.  Looks like everyone is watching me do the work, but that's ok, at least I have an audience.

 Larry Gray
la...@ar...

significant update on the calculator repository module.  Do an update..

 Larry Gray
la...@ar...

Some of you guys who are not so experienced may want to code some methods for someone who is working a given task.  I may create task specifically for coding certain methods. Someone goto the task and tell me if you, a technician, can assign yourself to a unassigned task. Also I'm thinking of starting all task Brief Descriptions with Architect-, Developer-, Programmer- To show what level of task it may be.

 Larry Gray
la...@ar...

Make sure your user skills and profiles are up to date. Do this under your SF account options. I'm going to work up a little thing that shows me at a glance who knows how to do what, etc. Thanks

 Larry Gray
la...@ar...

I made a new repository module for the specifications and you will note a calculator1.0.xml file which is almost complete. However it is not yet fully docbook compliant so I more work to do before I can post it on the project documentation.

 Larry Gray
la...@ar...

Actually I found a download for a windows installer for a tool that converts docbook xml to html.. I have yet to try it, I'm currently attempting to rewrite the specifications for the calculator in docbook xml.

 Larry Gray
la...@ar...

________________________________
From: Timothy Sprague <tim...@gm...>
To: Manu Mohan Pillai <msm...@gm...>
Cc: jav...@li...
Sent: Sunday, January 4, 2009 6:19:53 PM
Subject: Re: [Javacavemaps-developers] xerces

Hi...

I have a little bit of experience with Xerces where I work, but not very much.  They are using it with a C/C++ application and it is being phased out because the manager prefers using something native to C/C++.

Tim (huh32)

On Sat, Jan 3, 2009 at 2:50 AM, Manu Mohan Pillai <msm...@gm...> wrote:

HI...

I haven't used xerxes but have used a similar
transformation tool, the XSLT API (which comes bundled with j2dk), and
am quite familiar with it.

It uses an xsl document as the transformation guide to create the html document.

Manu(hicsys).

On Sat, Jan 3, 2009 at 4:37 AM, Larry Gray <jav...@ya...> wrote:

http://xerces.apache.org/xerces-j/install.html

a link to the Java xerces parser. Anyone familiar with or used this?  This turns an xml file into some other format such as html using the xsl as a transformation guide.  I'm new to xsl, I've heard about it but never looked into it.

 Larry Gray
la...@ar...

------------------------------------------------------------------------------

_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers

-- 
This email may contain confidential and privileged proprietary material for the sole use of the intended recipient. Any review, use, or distribution or disclosure by others is strictly prohibited. If you are not the intended recipient, or authorized to receive the information from the recipient, please contact the sender by reply email and delete all copies of this message. 

-- 
This email may contain confidential and privileged proprietary material for the sole use of the intended recipient. Any review, use, or distribution or disclosure by others is strictly prohibited. If you are not the intended recipient, or authorized to receive the information from the recipient, please contact the sender by reply email and delete all copies of this message. 

-- 
This email may contain confidential and privileged proprietary material for the sole use of the intended recipient. Any review, use, or distribution or disclosure by others is strictly prohibited. If you are not the intended recipient, or authorized to receive the information from the recipient, please contact the sender by reply email and delete all copies of this message. 

------------------------------------------------------------------------------

_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers

Hi...

I have a little bit of experience with Xerces where I work, but not very
much.  They are using it with a C/C++ application and it is being phased out
because the manager prefers using something native to C/C++.

Tim (huh32)

On Sat, Jan 3, 2009 at 2:50 AM, Manu Mohan Pillai <msm...@gm...>wrote:

> HI...
>
> I haven't used xerxes but have used a similar transformation tool, the XSLT
> API (which comes bundled with j2dk), and am quite familiar with it.
>
> It uses an xsl document as the transformation guide to create the html
> document.
>
> Manu(hicsys).
>
>
>
>
>> On Sat, Jan 3, 2009 at 4:37 AM, Larry Gray <jav...@ya...>wrote:
>>
>>> http://xerces.apache.org/xerces-j/install.html
>>>
>>> a link to the Java xerces parser. Anyone familiar with or used this?
>>> This turns an xml file into some other format such as html using the xsl as
>>> a transformation guide.  I'm new to xsl, I've heard about it but never
>>> looked into it.
>>>
>>> Larry Gray
>>> la...@ar...
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Javacavemaps-developers mailing list
>>> Jav...@li...
>>> https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers
>>>
>>>
>>
>>
>> --
>> This email may contain confidential and privileged proprietary material
>> for the sole use of the intended recipient. Any review, use, or distribution
>> or disclosure by others is strictly prohibited. If you are not the intended
>> recipient, or authorized to receive the information from the recipient,
>> please contact the sender by reply email and delete all copies of this
>> message.
>>
>
>
>
> --
> This email may contain confidential and privileged proprietary material for
> the sole use of the intended recipient. Any review, use, or distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient, or authorized to receive the information from the recipient,
> please contact the sender by reply email and delete all copies of this
> message.
>
>
>
> --
> This email may contain confidential and privileged proprietary material for
> the sole use of the intended recipient. Any review, use, or distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient, or authorized to receive the information from the recipient,
> please contact the sender by reply email and delete all copies of this
> message.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Javacavemaps-developers mailing list
> Jav...@li...
> https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers
>
>

Ok well the problem was that it will become tough to edit larger spec documents using sourceforge's web interface editor.  XML seems like a good solution because of the structure of the specifications. Each part of the specification is a branch in a tree. There is always XHTML but I'm not sure how sourceforges editor will handle XHTML.  DocBook is a SGLM application in the same way that XML and HTML are.  DocBook in recent years has gone the XML way as HTML has become XHTML the latest DocBook is XDocBook more or less. In 
other words DocBook now is also XML using DocBook DTD's.  I have installed some plug-ins in eclipse under their Web Tools Platform stuff.  I can edit xml easy enough. Had some problems when trying to use the DocBook DTD though.  Now I'm looking into ways to convert the XDocBook document into Html that sourceforge's editor will like.  I tried to use MS Word outline editor and then save as HTML, man, horrible html.

 Larry Gray
la...@ar...

I picked up a book 2003 "Lighter, Faster, Better Java"  It covers extendability in one chapter. It also agrees with the agile keep it simple however it says without sacrificing extendability. Same thing wags said. Anyway the points it basically covers is such.  1. Find Simple Generalizations that can be used for unforseen and unintended purposes as well as intended purposes.  2. Proper use of sub-classing  and interfaces.  3. Use configuration files instead of hard coding. 4. Use MVC, Facade and Other patterns that fit naturally to help with
extendability (coupling). 5. Use Plug-in pattern.  This is roughly what I recall. Any comments?  

 Larry Gray
la...@ar...

HI...

I haven't used xerxes but have used a similar transformation tool, the XSLT
API (which comes bundled with j2dk), and am quite familiar with it.

It uses an xsl document as the transformation guide to create the html
document.

Manu(hicsys).

> On Sat, Jan 3, 2009 at 4:37 AM, Larry Gray <jav...@ya...>wrote:
>
>> http://xerces.apache.org/xerces-j/install.html
>>
>> a link to the Java xerces parser. Anyone familiar with or used this?  This
>> turns an xml file into some other format such as html using the xsl as a
>> transformation guide.  I'm new to xsl, I've heard about it but never looked
>> into it.
>>
>> Larry Gray
>> la...@ar...
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Javacavemaps-developers mailing list
>> Jav...@li...
>> https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers
>>
>>
>
>
> --
> This email may contain confidential and privileged proprietary material for
> the sole use of the intended recipient. Any review, use, or distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient, or authorized to receive the information from the recipient,
> please contact the sender by reply email and delete all copies of this
> message.
>

-- 
This email may contain confidential and privileged proprietary material for
the sole use of the intended recipient. Any review, use, or distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient, or authorized to receive the information from the recipient,
please contact the sender by reply email and delete all copies of this
message.

-- 
This email may contain confidential and privileged proprietary material for
the sole use of the intended recipient. Any review, use, or distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient, or authorized to receive the information from the recipient,
please contact the sender by reply email and delete all copies of this
message.

 I'm now looking into something called DocBook
Larry Gray
la...@ar...

________________________________
From: Larry Gray <jav...@ya...>
To: jav...@li...
Sent: Friday, January 2, 2009 4:42:50 PM
Subject: [Javacavemaps-developers] DocBook DTD

I'm not looking into something called DocBook  www.docbook.org I think. 

This way we may keep the specifications and other Documentation in the repository as xml files.  Then tools that process xml using xsl to make html would be used, after this it would be uploaded to the Documentation on our projects sf web site. Anyone here used DocBook?

 Larry Gray
la...@ar...

http://xerces.apache.org/xerces-j/install.html

a link to the Java xerces parser. Anyone familiar with or used this?  This turns an xml file into some other format such as html using the xsl as a transformation guide.  I'm new to xsl, I've heard about it but never looked into it.

 Larry Gray
la...@ar...

I'm not looking into something called DocBook  www.docbook.org I think. 

This way we may keep the specifications and other Documentation in the repository as xml files.  Then tools that process xml using xsl to make html would be used, after this it would be uploaded to the Documentation on our projects sf web site. Anyone here used DocBook?

 Larry Gray
la...@ar...

I call prototyping or testing ideas (case testing)   JUnit I think may also call unit testing case testing.  

I'm now thinking we need a repository branch for case testing and a repository branch for unit testing.
where I had said use the net.sourceforge.javacavemaps.case.username.case1 etc we may need to pull this out to a
seperate repository branch. If you have any ideas please reply. Also we are contemplating a more extendable package naming structure at the moment. I'll get back with you guys when I get ready to make the change.

The new scheme goes something like this.

net.sourceforge.javacavemaps
net.sourceforge.javacavemaps.utilities (might be a project named uitilities so we must put this one under javacavemaps)
net.sourceforge.javacavemaps.utilities.event
net.sourceforge.javacavemaps.utilities.string
net.sourceforge.javacavemaps.utilities.sysconfig
net.sourceforge.javacavemaps.utilities.accessor
net.sourceforge.javacavemaps.core  (I would have used the javacavemaps package as the core in the past)
net.sourceforge.javacavemaps.core.data    (this iswhat I called models) why not "model"?
net.sourceforge.javacavemaps.core.data.beans (I was follwing the bean format for my datamodels)
net.sourceforge.javacavemaps.core.data.dao (handnt thought of this one.)
net.sourceforge.javacavemaps.core.display (here is what I called UI) why not "view"?
net.sourceforge.javacavemaps.core.handler (here I called it control)  Why not "controller"?
net.sourceforge.javacavemaps.components 
(usually I think of UI as being components but I think  this is what I
might call an in house library or " lib" which before I'd only tought
of putting in a seperate banch of the repository and making a jar for
it and release files seperate from the main branch, but that may be 
too much work might be better to release it all together..).
net.sourceforge.javacavemaps.components.core
net.sourceforge.javacavemaps.components.core.data
net.sourceforge.javacavemaps.components.core.data.beans
net.sourceforge.javacavemaps.components.core.data.dao
net.sourceforge.javacavemaps.components.core.display
net.sourceforge.javacavemaps.components.core.handler

Larry Gray
la...@ar...

Yes you are right, those are good thoughts. I'll keep this in mind as I create modules and organize.  I'm very serious about "growing" the project and features. I do see your point about extendability.  Everyone keep a cool head and lets weight out the trade offs together.

 Larry Gray
la...@ar...

________________________________
From: sean wagner <wa...@ya...>
To: jav...@li...; Larry Gray <jav...@ya...>
Sent: Monday, December 29, 2008 12:44:56 AM
Subject: Re: [Javacavemaps-developers] my style

Just my opinion on the cowboy coding with additional features and etc. If you do a lot of it right you can give people "sand box" areas to which they can play without affecting other portions of the code. That or they can branch, whether their branch is merged into the trunk should be completely up to the project managers digression. Gotta remember that people here are working for free though, and if you want them to stay, you will have to let them do a lot of things that they want to do, cus after all that is why they are here because they want to be. Hell we let people spend at least 25% of their time at work pursueing interests of this sort... and they are getting paid for it.

--- On Sun, 12/28/08, Larry Gray <jav...@ya...> wrote:

From: Larry Gray <jav...@ya...>
Subject: [Javacavemaps-developers] my style
To: jav...@li...
Date: Sunday, December 28, 2008, 7:31 PM

If anyone on the project can't stand the XP methodology, please feel free to remove yourself from the project if you think you can't contribute because of it.  I'd as soon see no one in the member list than to see members who simply don't want to help out because of the decisions I make.  I realize methodology can be something like Religion to some folks.  I'm not religious per say about this XP methodology.  But I see some good ideas there. Most developers I think want to start the project out by packing many features and advanced features and they want freedom to work ahead on uneeded features. etc. cowboy coding I guess you might say.  XP is a fairly limiting style.  You only do what is currently within you capability meaning (time/resources/quality/scope). A itteration is 2 to 3 weeks, its just for goal setting.  We would have several itterations inbetween minor versions. and several minor releases or more up to maybe 10 between major releases and
 version changes. You can always work ahead on your local computer and have something ready to contribute when the time comes.  I am going to try to keep the specs worked ahead as much as possible so we can all know whats coming up next.  

I guess idealy we should have one or two task for each person per itteration maybe.  Anyway if we are coding we are getting something done.  If we don't communicate we can't colaborate.  Let me know what your thoughts are other than.. "hi, I'm here to help, I see your an idiot so  I'm here to take over, o I can't so sorry. bye now"

 Larry Gray
la...@ar...

------------------------------------------------------------------------------

_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers

Yes, I guess was ambiguous.  I was only suggesting that if anyone wanted to try the pair coding on line they could use several methods.  Like I said, I've never been able to get anyone interested in trying the pair coding on line. I think could be good for someone with lesser coding experience to maybe do the "navigating". I did not intend to push that part of  XP.  However the iterations will be simple enough to try. Once we get enough task made up I'll set an iteration end date(A goal). I'll set the task for that iteration to be due by that date.  No biggy if it gets pushed out further. At any rate I fully intend to push us to make full use of the sourceforge web interface for management purposes.  Feature request and bug reports will become updated or new specs. Specs become task. Yes the tough part about pair programming is meeting and being online at the same time. Though for some of it you would not have to be online all the time at the same time.

 Larry Gray
la...@ar...

________________________________
From: sean wagner <wa...@ya...>
To: jav...@li...; Larry Gray <jav...@ya...>
Sent: Monday, December 29, 2008 12:39:37 AM
Subject: Re: [Javacavemaps-developers] my style

I read a book on extreme programming. I personally think the pair programming is overkill. Having multiple people agree on an API then one person code then a different person write the test cases works well. As long as the higher level API is defined right and then tested for the agreed functionality you are set, but code reviews are good. That is about as good as I have ever gotten it, otherwise your just doing everything twice. 

I would agree with most of the planning of the XP methodology.

The design part of the XP method I would have some disagreements on though. I don't always think starting with the simplest solution is always the answer. I have had to write and rewrite many systems because the original solution was not extensible enough to support the incoming feature requests. Instead my opinion is to start with the simplest solution  possible that doesn't sacrifice the possibility of extension in the future. For example their are certian groundlaying things I will do in most all of my applications. Alot of it just comes down to good OOP principals as well though. You should also be wary of rushing development without enough active planning.

~Sean

--- On Sun, 12/28/08, Larry Gray <jav...@ya...> wrote:

From: Larry Gray <jav...@ya...>
Subject: [Javacavemaps-developers] my style
To: jav...@li...
Date: Sunday, December 28, 2008, 7:31 PM

If anyone on the project can't stand the XP methodology, please  feel free to remove yourself from the project if you think you can't contribute because of it.  I'd as soon see no one in the member list than to see members who simply don't want to help out because of the decisions I make.  I realize methodology can be something like Religion to some folks.  I'm not religious per say about this XP methodology.  But I see some good ideas there. Most developers I think want to start the project out by packing many features and advanced features and they want freedom to work ahead on uneeded features. etc. cowboy coding I guess you might say.  XP is a fairly limiting style.  You only do what is currently within you capability meaning (time/resources/quality/scope). A  itteration is 2 to 3 weeks, its just for goal setting.  We would have several itterations inbetween minor versions. and several minor releases or more up to maybe 10 between major releases and
 version changes. You can always work ahead on your local computer and have something ready to contribute when the time comes.  I am going to try to keep the specs worked ahead as much as possible so we can all know whats coming up next.  

I guess idealy we should have one or two task for each person per itteration maybe.  Anyway if we are coding we are getting something done.  If we don't communicate we can't colaborate.  Let me know what your thoughts are other than.. "hi, I'm here to help, I see your an idiot so  I'm here to take over, o I can't so sorry. bye now"

 Larry Gray
la...@ar...

------------------------------------------------------------------------------

_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers

2003	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (7)
2004	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2008	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (39)
2009	Jan (79)	Feb (26)	Mar (8)	Apr (6)	May (4)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2010	Jan	Feb	Mar	Apr	May	Jun (1)	Jul (1)	Aug	Sep	Oct	Nov	Dec

javacavemaps-developers Mailing List for Java Cave Maps (Page 5)

javacavemaps-developers — Will be talk about packages, public classes and public methods