Menu
▾
▴
arch4j-developers — List forum for developers of Arch4J.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(15) |
Feb
(10) |
Mar
(12) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Allan W. <al...@wi...> - 2002-01-23 21:57:09
|
Hello, This release concentrates on breaking the components out into separate directories for development and versioning purposes. Users may now pick and choose components that they wish to use. NOTE: Package names have also changed, so you may need to change your imports if you are already using an older version. Regards, Arch4J Development Team |
|
From: Allan W. <al...@wi...> - 2002-01-18 20:08:44
|
Developers, I have put a new full directory out on my web site: http://www.wickidcool.com/arch4j.zip Please download and look it over to see that I have the right components, etc. We can talk about it on Monday night with Infinity guys as well. I will have all of the updated build files, etc in CVS by end of day today if you wan to try to build everything on your own. Regards, -Allan Wick |
|
From: Allan W. <al...@wi...> - 2002-01-18 19:47:58
|
Seems the last setup documentation was corrupt.... |
|
From: Allan W. <al...@wi...> - 2002-01-18 16:57:40
|
Hello, I have created a simple HowTo for using WinCvs and Putty to access the SourceForge repository. This is the only way I have been able to do updates to the repository. That is of course on Windoze :) It is a web page, so unzip and view the .html page ;) Regards, -Allan Wick |
|
From: Allan W. <al...@wi...> - 2002-01-16 16:55:45
|
Everyone, I have an initial version of the new release out in CVS on sourceforge. I am missing one directory, but everything went pretty well once I found the correct instructions ;) I am having problems with SSH and CVS on Windoze. Hopefully, I will figure out the problems and send out instructions... You are able to connect anonymously using pserver and the following CVSROOT: :pserver:ano...@cv...:/cvsroot/arch4j and authentication of pserver.. Regards, -Allan Wick |
|
From: David C. <dco...@sp...> - 2002-01-15 16:45:49
|
I saw an demo for GDPro (http://www.gdpro.com/products/products.html) at a Java User's Group a year ago. It looked like pretty good competition for TogetherJ. Dave -----Original Message----- From: RefuX Zanzebarr To: arc...@li... Sent: 1/15/02 10:02 AM Subject: [Arch4j-developers] Modeling Tools I'm looking in to various Modeling tools for comparison. One on my list so far: TogetherJ Rational Rose argouml Any more would be appreciated! James |
|
From: RefuX Z. <re...@ya...> - 2002-01-15 16:09:42
|
For when we use CVS to access sourceforge here is a nice external client: (for those not using an intergrated one) SmartCVS - http://www.smartcvs.com/ This app will also 'webstart' which is very nice :) James __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ |
|
From: RefuX Z. <re...@ya...> - 2002-01-15 16:02:39
|
I'm looking in to various Modeling tools for comparison. One on my list so far: TogetherJ Rational Rose argouml Any more would be appreciated! James __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ |
|
From: Allan W. <al...@wi...> - 2002-01-11 22:09:00
|
Hello, I added more explanation about the directory structure for each component. Regards, -Al Wick |
|
From: Allan W. <al...@wi...> - 2002-01-11 17:39:09
|
Hello All, Document summary: I have re-packaged the code in two ways: - Changed the imports to remove "framework/provider" split and moved JUnit tests into same package as the source. - Moved each component of Arch4J into separate directory structure. Next Steps: - Get feedback on issues, etc. - Make sure everything got moved properly. - Get into CVS. <== James Roome is looking into doing this. - Get module documentation built! - Need to develop release process. Regards, -Allan Wick |
|
From: David C. <dco...@sp...> - 2002-01-11 16:29:55
|
We now have a FAQ and Who We Are section from the home page. I'm working on the 'Matrix of project decisions' document which will define many types of projects and cross reference each against the different approaches to persistence. This will give us a better context for discussion of persistence and what we want to do with Arch4J. Chuck: any help is hugely appreciated! -----Original Message----- From: Chuck Lewin To: 'Arch4j-Developers' Sent: 1/11/02 10:13 AM Subject: RE: [Arch4j-developers] Arch4j Estimates I would enjoy working with Al on the code generator. My TR experience may help. -----Original Message----- From: arc...@li... [mailto:arc...@li...] On Behalf Of Allan Wick Sent: Friday, January 11, 2002 8:59 AM To: Arch4j-Developers Subject: [Arch4j-developers] Arch4j Estimates These are the tasks I am working on or have identified as needing work... Let me know if you have any others... _______________________________________________ Arch4j-developers mailing list Arc...@li... https://lists.sourceforge.net/lists/listinfo/arch4j-developers |
|
From: Chuck L. <chu...@po...> - 2002-01-11 16:09:55
|
I would enjoy working with Al on the code generator. My TR experience may help. -----Original Message----- From: arc...@li... [mailto:arc...@li...] On Behalf Of Allan Wick Sent: Friday, January 11, 2002 8:59 AM To: Arch4j-Developers Subject: [Arch4j-developers] Arch4j Estimates These are the tasks I am working on or have identified as needing work... Let me know if you have any others... |
|
From: Allan W. <al...@wi...> - 2002-01-11 14:55:23
|
These are the tasks I am working on or have identified as needing work... Let me know if you have any others... |
|
From: Chuck L. <chu...@po...> - 2002-01-08 13:37:36
|
The attached HTML file contains links to the articles used to create yesterday's Java Security Overview presentation. -- Chuck Lewin |
|
From: Chuck L. <chu...@po...> - 2002-01-08 13:27:49
|
Attached are the Java Security PowerPoint slides presented at yesterdays Arch4j user's group meeting. Chuck Lewin |
|
From: Allan W. <al...@wi...> - 2001-12-31 23:11:22
|
SQLExceptions vs DataAccessExceptionsI will make the changes to go with
option #3. I like having the ResultSetCache implement the two interfaces...
As a future enhancement we can add some "helper" class to handle the
interpretation of SQLExceptions.
-Al Wick
-----Original Message-----
From: arc...@li...
[mailto:arc...@li...]On Behalf Of David
Colwell
Sent: Monday, December 31, 2001 12:05 PM
To: 'arc...@li...'
Subject: [Arch4j-developers] SQLExceptions vs DataAccessExceptions
SQLExceptions contain useful but vendor-specific error codes. We
plan to use DataAccessExceptions to wrapper SQLExceptions and shield
developers from vendor dependency. The new dataaccess module is using
DataAccessExceptions and SQLExceptions inconsistently. The DatabaseManager
wraps all SQLExceptions and throws them as DataAccessExceptions. However,
the ResultSetCache implements java.sql.ResultSet and therefore must throw
SQLExceptions.
I don't want to have to catch and wrap SQLExceptions in all code that
uses the ResultSetCache. Here are some options:
1. Don't model ResultSetCache to extend ResultSet and recode it to throw
DataAccessExceptions.
2. Create another cache class that doesn't extend ResultSet.
3. Get rid of DataAccessExceptions and put SQLException services in a
seperate service provider.
I'm leaning toward #3 the most. We can code a seperate provider/service
interface that knows how to break apart SQLExceptions. It will be loaded
for a specific database environment based on a property setting, similar to
our other provider patterns.
What do you think?
|
|
From: David C. <dco...@sp...> - 2001-12-31 18:00:27
|
SQLExceptions contain useful but vendor-specific error codes. We plan
to use DataAccessExceptions to wrapper SQLExceptions and shield developers
from vendor dependency. The new dataaccess module is using
DataAccessExceptions and SQLExceptions inconsistently. The DatabaseManager
wraps all SQLExceptions and throws them as DataAccessExceptions. However,
the ResultSetCache implements java.sql.ResultSet and therefore must throw
SQLExceptions.
I don't want to have to catch and wrap SQLExceptions in all code that
uses the ResultSetCache. Here are some options:
1. Don't model ResultSetCache to extend ResultSet and recode it to throw
DataAccessExceptions.
2. Create another cache class that doesn't extend ResultSet.
3. Get rid of DataAccessExceptions and put SQLException services in a
seperate service provider.
I'm leaning toward #3 the most. We can code a seperate provider/service
interface that knows how to break apart SQLExceptions. It will be loaded
for a specific database environment based on a property setting, similar to
our other provider patterns.
What do you think?
|
|
From: Allan W. <aw...@sp...> - 2001-12-26 20:56:03
|
As far as sorting goes, I kind of like to see the class/classTest next to each other since they are easier to find ;) > -----Original Message----- > From: Ross Greinke [mailto:rgr...@sp...] > Sent: Wednesday, December 26, 2001 2:52 PM > To: Al Wick; 'Arch4j-Developers ' > Subject: RE: [Arch4j-developers] Componentizing the source code > > > I guess we can leave the Test classes as XXXTest.java. The purist in me > would like to see all of the Test classes sort into a localized section > of my directory listing. > > Re: renaming of the provider/implementation packages, I agree with the > long-term goal that Al has suggested. Again, it localizes the package > hierarchy, and the pattern "feels" right. > > Ross > > -----Original Message----- > From: Allan Wick > To: Arch4j-Developers > Sent: 12/26/01 2:26 PM > Subject: RE: [Arch4j-developers] Componentizing the source code > > I agree with the moving of unit tests. I have found the same problems > with unit tests I have done in the past. > > >BTW: The class trees begin with "org", not "com". :-) > Oops :) > > >The class names all should begin with TestXXX.java (to make it easy to > exclude them in a build target if need be). > I thought they should be XXXTest ;). Either way, the test classes can > be stripped out of the jar file for distribution. > > Not that it would be the best thing to do at this time, but what about > removing the "framework/provider" levels in the package structure and > just packaging under org.arch4j.XXXXX and > org.arch4j.XXXXX."implementation". For example org.arch4j.logging and > org.arch4j.logging.log4j. > > This would be a big change and I am not sure if/when would be a good > time to make the changes... > > -Al > > -----Original Message----- > From: arc...@li... > [mailto:arc...@li...]On Behalf Of Ross > Greinke > Sent: Wednesday, December 26, 2001 12:11 PM > To: 'Allan Wick '; 'arc...@li... ' > Subject: RE: [Arch4j-developers] Componentizing the source code > > > > I don't have a problem with splitting up the code, but I would suggest > that if we are going to do this refactoring, we should get rid of the > unit test hierarchy and have them live right next to the classes they > test. This will allow us to white-box test methods that in the past had > to be declared public when they really need to be protected or > package-access. > > The class names all should begin with TestXXX.java (to make it easy to > exclude them in a build target if need be). > > BTW: The class trees begin with "org", not "com". :-) > > Further comments? Bring it on! > > Rossi > > -----Original Message----- > From: Allan Wick > To: arc...@li... > Sent: 12/19/01 4:35 PM > Subject: [Arch4j-developers] Componentizing the source code > > Hello everyone. > > Being new to the team, I thought I would start out with a little > controversy ;) > > I would like to propose splitting up the code base into separate > directory structures for each component. > > We have a lot of different components and, IMHO, not as well organized > as it could be. > > What I am proposing is having a separate directory and build structure > for each component. > > I.E. > core > |-src > | |-com > | |-unit > |-lib > |-doc > |-build.xml > dataaccess > |-src > | |-com > | |-unit > |-lib > |-doc > |-build.xml > .... > > I would also propose that there be a root directory that contains the > build script that would build all of the components by invoking each > individual build script. > > What this structure allows us to do is version each component > individually and provide separation of code by developers. Each > developer may be working on one or more component(s) at a time. > > What do you think? > > Regards, > > -Allan Wick > > |
|
From: Ross G. <rgr...@sp...> - 2001-12-26 20:47:03
|
I guess we can leave the Test classes as XXXTest.java. The purist in me would like to see all of the Test classes sort into a localized section of my directory listing. Re: renaming of the provider/implementation packages, I agree with the long-term goal that Al has suggested. Again, it localizes the package hierarchy, and the pattern "feels" right. Ross -----Original Message----- From: Allan Wick To: Arch4j-Developers Sent: 12/26/01 2:26 PM Subject: RE: [Arch4j-developers] Componentizing the source code I agree with the moving of unit tests. I have found the same problems with unit tests I have done in the past. >BTW: The class trees begin with "org", not "com". :-) Oops :) >The class names all should begin with TestXXX.java (to make it easy to exclude them in a build target if need be). I thought they should be XXXTest ;). Either way, the test classes can be stripped out of the jar file for distribution. Not that it would be the best thing to do at this time, but what about removing the "framework/provider" levels in the package structure and just packaging under org.arch4j.XXXXX and org.arch4j.XXXXX."implementation". For example org.arch4j.logging and org.arch4j.logging.log4j. This would be a big change and I am not sure if/when would be a good time to make the changes... -Al -----Original Message----- From: arc...@li... [mailto:arc...@li...]On Behalf Of Ross Greinke Sent: Wednesday, December 26, 2001 12:11 PM To: 'Allan Wick '; 'arc...@li... ' Subject: RE: [Arch4j-developers] Componentizing the source code I don't have a problem with splitting up the code, but I would suggest that if we are going to do this refactoring, we should get rid of the unit test hierarchy and have them live right next to the classes they test. This will allow us to white-box test methods that in the past had to be declared public when they really need to be protected or package-access. The class names all should begin with TestXXX.java (to make it easy to exclude them in a build target if need be). BTW: The class trees begin with "org", not "com". :-) Further comments? Bring it on! Rossi -----Original Message----- From: Allan Wick To: arc...@li... Sent: 12/19/01 4:35 PM Subject: [Arch4j-developers] Componentizing the source code Hello everyone. Being new to the team, I thought I would start out with a little controversy ;) I would like to propose splitting up the code base into separate directory structures for each component. We have a lot of different components and, IMHO, not as well organized as it could be. What I am proposing is having a separate directory and build structure for each component. I.E. core |-src | |-com | |-unit |-lib |-doc |-build.xml dataaccess |-src | |-com | |-unit |-lib |-doc |-build.xml .... I would also propose that there be a root directory that contains the build script that would build all of the components by invoking each individual build script. What this structure allows us to do is version each component individually and provide separation of code by developers. Each developer may be working on one or more component(s) at a time. What do you think? Regards, -Allan Wick |
|
From: Allan W. <aw...@sp...> - 2001-12-26 20:23:34
|
RE: [Arch4j-developers] Componentizing the source codeI agree with the
moving of unit tests. I have found the same problems with unit tests I have
done in the past.
>BTW: The class trees begin with "org", not "com". :-)
Oops :)
>The class names all should begin with TestXXX.java (to make it easy to
exclude them in a build target if need be).
I thought they should be XXXTest ;). Either way, the test classes can be
stripped out of the jar file for distribution.
Not that it would be the best thing to do at this time, but what about
removing the "framework/provider" levels in the package structure and just
packaging under org.arch4j.XXXXX and org.arch4j.XXXXX."implementation".
For example org.arch4j.logging and org.arch4j.logging.log4j.
This would be a big change and I am not sure if/when would be a good time to
make the changes...
-Al
-----Original Message-----
From: arc...@li...
[mailto:arc...@li...]On Behalf Of Ross
Greinke
Sent: Wednesday, December 26, 2001 12:11 PM
To: 'Allan Wick '; 'arc...@li... '
Subject: RE: [Arch4j-developers] Componentizing the source code
I don't have a problem with splitting up the code, but I would suggest
that if we are going to do this refactoring, we should get rid of the unit
test hierarchy and have them live right next to the classes they test. This
will allow us to white-box test methods that in the past had to be declared
public when they really need to be protected or package-access.
The class names all should begin with TestXXX.java (to make it easy to
exclude them in a build target if need be).
BTW: The class trees begin with "org", not "com". :-)
Further comments? Bring it on!
Rossi
-----Original Message-----
From: Allan Wick
To: arc...@li...
Sent: 12/19/01 4:35 PM
Subject: [Arch4j-developers] Componentizing the source code
Hello everyone.
Being new to the team, I thought I would start out with a little
controversy ;)
I would like to propose splitting up the code base into separate
directory structures for each component.
We have a lot of different components and, IMHO, not as well organized
as it could be.
What I am proposing is having a separate directory and build structure
for each component.
I.E.
core
|-src
| |-com
| |-unit
|-lib
|-doc
|-build.xml
dataaccess
|-src
| |-com
| |-unit
|-lib
|-doc
|-build.xml
....
I would also propose that there be a root directory that contains the
build script that would build all of the components by invoking each
individual build script.
What this structure allows us to do is version each component
individually and provide separation of code by developers. Each
developer may be working on one or more component(s) at a time.
What do you think?
Regards,
-Allan Wick
|
|
From: Ross G. <rgr...@sp...> - 2001-12-26 18:05:45
|
I don't have a problem with splitting up the code, but I would suggest that if we are going to do this refactoring, we should get rid of the unit test hierarchy and have them live right next to the classes they test. This will allow us to white-box test methods that in the past had to be declared public when they really need to be protected or package-access. The class names all should begin with TestXXX.java (to make it easy to exclude them in a build target if need be). BTW: The class trees begin with "org", not "com". :-) Further comments? Bring it on! Rossi -----Original Message----- From: Allan Wick To: arc...@li... Sent: 12/19/01 4:35 PM Subject: [Arch4j-developers] Componentizing the source code Hello everyone. Being new to the team, I thought I would start out with a little controversy ;) I would like to propose splitting up the code base into separate directory structures for each component. We have a lot of different components and, IMHO, not as well organized as it could be. What I am proposing is having a separate directory and build structure for each component. I.E. core |-src | |-com | |-unit |-lib |-doc |-build.xml dataaccess |-src | |-com | |-unit |-lib |-doc |-build.xml .... I would also propose that there be a root directory that contains the build script that would build all of the components by invoking each individual build script. What this structure allows us to do is version each component individually and provide separation of code by developers. Each developer may be working on one or more component(s) at a time. What do you think? Regards, -Allan Wick |
|
From: Allan W. <al...@wi...> - 2001-12-19 22:33:03
|
Hello everyone. Being new to the team, I thought I would start out with a little controversy ;) I would like to propose splitting up the code base into separate directory structures for each component. We have a lot of different components and, IMHO, not as well organized as it could be. What I am proposing is having a separate directory and build structure for each component. I.E. core |-src | |-com | |-unit |-lib |-doc |-build.xml dataaccess |-src | |-com | |-unit |-lib |-doc |-build.xml .... I would also propose that there be a root directory that contains the build script that would build all of the components by invoking each individual build script. What this structure allows us to do is version each component individually and provide separation of code by developers. Each developer may be working on one or more component(s) at a time. What do you think? Regards, -Allan Wick |
1 message has been excluded from this view by a project administrator.
