You can subscribe to this list here.
2007 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(4) |
Sep
(1) |
Oct
(4) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Larry M. <lar...@gm...> - 2008-03-01 02:18:21
|
sounds good to me On Fri, Feb 29, 2008 at 8:55 PM, Kevin Hartig <kev...@gm...> wrote: > I'm thinking we could do a 1.0.1 release with the current codebase in > svn. There have been a number of additions and fixes since the 1.0 > release. A few changes eliminating some annoying problems. Any > objections or opinions? > > I am currently working on getting Assimilator to work using peers across > a network overlay. I have the beginning bits working and will be making > an extra effort to commit time to getting it working over the next few > months. > > -kevin. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Assimilator-developers mailing list > Ass...@li... > https://lists.sourceforge.net/lists/listinfo/assimilator-developers > |
From: Kevin H. <kev...@gm...> - 2008-03-01 01:55:50
|
I'm thinking we could do a 1.0.1 release with the current codebase in svn. There have been a number of additions and fixes since the 1.0 release. A few changes eliminating some annoying problems. Any objections or opinions? I am currently working on getting Assimilator to work using peers across a network overlay. I have the beginning bits working and will be making an extra effort to commit time to getting it working over the next few months. -kevin. |
From: Larry M. <lar...@gm...> - 2007-11-04 03:33:43
|
Yep, crap code must go ;) Mike T. Miller wrote: > Go for it. > > -mike > > On Nov 1, 2007, at 9:16 AM, Kevin Hartig wrote: > > >> Any objections to removing the old Service Viewer code? >> >> -kevin. >> < >> kevin >> .hartig >> .vcf >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a >> browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________ >> Assimilator-developers mailing list >> Ass...@li... >> https://lists.sourceforge.net/lists/listinfo/assimilator-developers >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Assimilator-developers mailing list > Ass...@li... > https://lists.sourceforge.net/lists/listinfo/assimilator-developers > > |
From: Mike T. M. <ji...@gm...> - 2007-11-01 16:22:07
|
Go for it. -mike On Nov 1, 2007, at 9:16 AM, Kevin Hartig wrote: > Any objections to removing the old Service Viewer code? > > -kevin. > < > kevin > .hartig > .vcf > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________ > Assimilator-developers mailing list > Ass...@li... > https://lists.sourceforge.net/lists/listinfo/assimilator-developers |
From: Kevin H. <kev...@gm...> - 2007-11-01 16:17:31
|
Any objections to removing the old Service Viewer code? -kevin. |
From: Kevin H. <kev...@gm...> - 2007-11-01 16:16:25
|
I added the capability to drop oar files onto the console service graph to deploy services. Currently this only works if the console and webster service are running on the same machine. But it makes for a great demo. Future version could enhance webster to accept files remotely so this could work across a network. -kevin. |
From: Kevin H. <kev...@gm...> - 2007-10-23 15:18:19
|
I added a Release Notes page to the project wiki. The intent of the page is to capture changes made to the code base from the last official release. The list of items would become the official release notes for the next release. If we can keep this list up to date as code is changed, hopefully it will be easier than trying to compile a list all at once just before a release. -kevin. |
From: Kevin H. <kev...@gm...> - 2007-10-16 17:36:29
|
I just added JUnit 4.4 to devlib and updated the build_properties file to use the new version. The full ant project build works with the new lib. We can now include new JUnit capabilities. Let me know if there are any issues that come up because of the change. -kevin. |
From: Kevin H. <kev...@gm...> - 2007-10-12 22:02:17
|
I just switched over to using Apache ant 1.7.0. No problems with the build on Windows. I'm switching over to this latest version and will test on the other platforms also. -kevin. |
From: Kevin H. <kev...@gm...> - 2007-10-11 03:40:26
|
I added this page to the project wiki to start capturing ideas about future capabilities. http://assimilator.wiki.sourceforge.net/Under+Development -kevin. |
From: Larry M. <lar...@gm...> - 2007-09-06 15:56:42
|
Hi Everyone, It has been a while since we updated you on what is happening with Assimilator. This short email is intended to give you an idea of what we have done and what we plan to do in the next while. *1) Participation* First of all, I would like to thank those of you who have had great suggestions for features and those who have given usability feedback. We have made a significant number of changes to reflect what you have asked. There is however, a lot more to do. We would like to involve you the community as much as possible. In a great many of these sort of Jini based container projects, it tends to be a on man tyranny where those who use it have very little say in what happens. We have purposefully structured the project to have mutliple developers and we would encourage each of you to participate. At the moment there are 7 committers 3 of whom does the lion's share of work. Since this is a meritocracy, to become a committer requires that those wanting that role develop something for assimilator that we need. Depending on the quality and value of the submitted code the current committers vote to add that person. The last thing we want is this to become another one of those Jini container projects where one guy does it all. Anyway, nuff said on that subject. *2) What's New* Over the summer, we have added a number of things a) build files and project structure: *Status: *almost done There was a real mess there with file system and environment dependencies everywhere so we have set it up so that you can do a fresh checkout and not have to change a single environment variable and it will just work/build. We also included a experimental module so that we could try advanced concepts and make them available to those collaborating. b) Comprehensive examples : *Status: *done The old hello world example was ok but basically incomprehensible to the beginning user. We broke it out to be a staged laerning and added a number of idiomatic programming pattern examples to help people understand what and how assimilator works. Please take a look and suggest other examples you would like to see. If you can make an example we will be sure to include it. c) New service browser: *Status: *functional - some additional features planned The utilities section of Assimilator has 4 different viewing tools. These are a mess and were historic in their importance and relevance. However, they have a number of bugs and problems/limitation associated with them. The new service browser is intended to replace them all. Most of the functionality (remaining feature porting work still remains). Once we have extracted all the capabilities that make sense out of the older utilities we will retire then and tidy up (remove) the older poorer code. The new service browser is a massive improvement over the older viewer so please give it a test drive. d) Installer: *Status: *almost done We added a cross platform installer. This allows the user to add sections that they want and avoids the whole svn type of all or nothing. The installer is basic at the moment (although it was a significant effort to setup) and we plan on enhancing it as we need over the next year. e) New webster service : *Status: *almost done The old webster was a good improvement to the jini class server in that it supported multiple file roots and was multithreaded but is did not fit in with the rest of the infrastructure for lifecycle and ease of use. I made some initial improvement some time ago to add jini configuration properties to it but the most recent work was to give it a jini interface allowing it to be reconfigured on the fly and thus add new file roots. This new webster will vastly change how http clas loading is dynamically managed. f) New archive format for Assimilator and a directory based deployer : *Status: *almost done This is a relatively new development and I am trying to finish it by end of next week. The big problem in the pass is the number of artifacts you had to deal with to setup a opstring deployment. There are the opstrings, policy files, service jars (at least 3 per service), the support libs like jini, spring, hibernate, ad nauseum. We reintroduced the concept (and it is an old one never implemented) of an OAR (operational string archive). This is similar to a war or ear in that it includes all of the above elements in one zip archive with a ".oar" suffix. In order to make this meaning full we added a directory based oar installer/deployer that acts with the same semantics as Tomcat. If you add an oar file to the directory it is unzipped and deployed. If you remove the oar file then it is undeployed. We also added a utiltiy to create oar files and there is an oar deployer admin to discover what is happening. *3) Short Term plans for development* Over the next few months we will be working in the following topics. /a) a new microkernel architecture for Assimilator/ Lets face it, the underlying code base for Assimilator is a mess and this is primarily historic. The little project that grew without discipline. When we forked the codebase from the original project the problem was evident. The biggest surprise is that it worked. :) We can't step forward and let the state of the codebase remain because already we are seeing very difficult to find bugs (nothing major but that is only a matter of time). Thus the question is how to proceed. At the moment, we have some work in the experimental module. In the past we tried a spring based container and this has been added to the experimental codebase. Also we started a declarative OSGi container experiment. The reason for two approaches is to determin how to take the best of these two world and go forward. This will be an interesting and challenging project and we would like participants /b) Class loading abstractions/ class loader source lockin (not the right term but it describes the problem) is a huge problem. For example, if you have a webster serving jars and it crashes you are dead even though these jars are available elsewhere due to the lockin to that specific class loading mechanism. /c) Assimilator communication and discovery over the internet/WAN/ Jini (and assimialtor as well) works well on an open LAN but it is a disaster on an internet with NATS, multicast unfriendly routers and firewalls. This project will attempt to get the current best state of the art in P2P and make it a core technology to the assimilator. We are researching this at the moment. Regards Larry |
From: Kevin H. <kev...@gm...> - 2007-08-27 03:14:29
|
I added docking and resizable panes to the console window for the Trees, Service Graphs, and Service UIs sections. You can now drag the panes around to shift location and just resize them. The panes can also be dragged out to the desktop and put back in. You can also close the panes down to a button in the window. Let me know what you think. -kevin. |
From: Larry M. <lar...@gm...> - 2007-08-12 23:52:22
|
ok, you still working on a Sunday night? Kevin Hartig wrote: > I think we want one installer. It should be oriented towards a user > rather than a developer. Typically developers would get the code > through svn directly from the sourceforge project site. By user I > mean someone wanting to only start the services needed. include in the > install should be the libs, examples, docs, core, utilities, configs > and scripts. > > -kevin. > > Larry Mitchell wrote: >> Hi >> >> I am putting in the installer stuff now. A couple of questions? >> >> Should we keep that same structure as defined in the directories? >> This means a modules directory etc. >> >> Should there be one install or two? >> >> *One installer:* >> >> The single installer would have choices of: >> >> * src and build system - /optional/ >> * examples - /optional/ >> * core - /mandatory/ >> >> >> *Two installers:* >> >> I figure there are two basic installs, one for developer with svn >> tags and a user install. >> >> The developer install is identical to what we have in the >> directories. The user install would be no src and build system. >> There would be only the libs and examples >> >> Thoughts? >> >> I am headed with the first option for now. >> >> Regards >> Larry >> > -- ------------------------------------------ Larry Mitchell Cognitive Dynamics Inc. A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -Lazarus Long |
From: Kevin H. <kev...@gm...> - 2007-08-12 23:51:32
|
I think we want one installer. It should be oriented towards a user rather than a developer. Typically developers would get the code through svn directly from the sourceforge project site. By user I mean someone wanting to only start the services needed. include in the install should be the libs, examples, docs, core, utilities, configs and scripts. -kevin. Larry Mitchell wrote: > Hi > > I am putting in the installer stuff now. A couple of questions? > > Should we keep that same structure as defined in the directories? > This means a modules directory etc. > > Should there be one install or two? > > *One installer:* > > The single installer would have choices of: > > * src and build system - /optional/ > * examples - /optional/ > * core - /mandatory/ > > > *Two installers:* > > I figure there are two basic installs, one for developer with svn tags > and a user install. > > The developer install is identical to what we have in the > directories. The user install would be no src and build system. > There would be only the libs and examples > > Thoughts? > > I am headed with the first option for now. > > Regards > Larry > |
From: Kevin H. <kev...@gm...> - 2007-08-05 23:53:24
|
At some point in the last week or so the example scripts stopped working. I get a Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file I thought maybe it had to do with Webster now being a service so changed the example config files. Although the configs need to be updated that didn't work. I can't tell from the traceback which class it's complaining about. Any ideas why this might be happening? -kevin. C:\Projects\Assimilator\examples\bin>java -cp ..\..\lib\core\boot.jar;..\..\devl ib\jini2_1\lib\start.jar; -Djava.security.policy=..\policy\policy.all -Djava.pro tocol.handler.pkgs=net.jini.url -DASSIMILATOR_CORE_LIBS=..\..\lib\core -DASSIMIL ATOR_SUBSTRATES_LIBS=..\..\lib\substrates -DEXAMPLES_HOME=.. -Dgroup.name=ASSIML ATOR_EXAMPLES -DJINI_HOME=..\..\devlib\jini2_1 -Dwebster.port=9000 com.sun.jini. start.ServiceStarter ..\configs\hello-example\start-helloexample6.config Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version n umber in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 4) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at net.jini.config.ConfigurationFile.findClassExact(ConfigurationFile.ja va:2327) at net.jini.config.ConfigurationFile.findClassNoImports(ConfigurationFil e.java:2302) at net.jini.config.ConfigurationFile$Parser.parseImport(ConfigurationFil e.java:1305) at net.jini.config.ConfigurationFile$Parser.parseSource(ConfigurationFil e.java:1268) at net.jini.config.ConfigurationFile$Parser.<init>(ConfigurationFile.jav a:1222) at net.jini.config.ConfigurationFile.<init>(ConfigurationFile.java:1803) at net.jini.config.ConfigurationProvider.getInstance(ConfigurationProvid er.java:225) at net.jini.config.ConfigurationProvider.getInstance(ConfigurationProvid er.java:137) at com.sun.jini.start.ServiceStarter.main(ServiceStarter.java:455) |
From: Kevin H. <kev...@gm...> - 2007-07-27 00:39:26
|
test |
From: Kevin H. <kev...@gm...> - 2007-07-27 00:08:41
|
When I think of swarming services it would be more like an indeterminate number of services gathering to collaboratively complete some goal. Services would collaborate with like-services or with other specific types of services. Collections of services could be dynamically assigned a behavior or characteristic giving it a context in which it would perform its normal operations. An assigned behavior might be to collocate yourself with other defined services ( not necessarily the same type of service) or to follow a person around using local resources as possible. It could also be a swarming onto newly available resources to consume them to most efficiently complete a task, etc. I have coded some samples of cross cutting service method calls so logic can be applied dynamically to running services. It's not currently in the Assimilator code base but could be added (sometime) enabling services to take on group or swarming behavior. -kevin. Mike Miller wrote: > Some ideas for adding a grouping mechanism for services (swarming). > > Swarms would consist of a homogenous group of services and be > controlled by the provisioner. They would be defined in the meta- > model by enhancing the opstring to include some swarm elements such as: > > <ServiceBean> > ... > <Maintain> 30 </Maintain> > <Swarm count="2"> > <Name> foo </Name> > </Swarm> > </ServiceBean> > > This would create two swarms named 'foo-1' and 'foo-2' and populate > them each with 15 services. I'm imagining the swarms being > implemented as services, allowing discovery and all the other > goodies that services bring. > > Comments? > > -- > Mike T. Miller > Principal Software Engineer > Office of the CTO > LinkedIn, Inc. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Assimilator-developers mailing list > Ass...@li... > https://lists.sourceforge.net/lists/listinfo/assimilator-developers > > |
From: Mike M. <mm...@li...> - 2007-07-25 22:46:49
|
Some ideas for adding a grouping mechanism for services (swarming). Swarms would consist of a homogenous group of services and be controlled by the provisioner. They would be defined in the meta- model by enhancing the opstring to include some swarm elements such as: <ServiceBean> ... <Maintain> 30 </Maintain> <Swarm count="2"> <Name> foo </Name> </Swarm> </ServiceBean> This would create two swarms named 'foo-1' and 'foo-2' and populate them each with 15 services. I'm imagining the swarms being implemented as services, allowing discovery and all the other goodies that services bring. Comments? -- Mike T. Miller Principal Software Engineer Office of the CTO LinkedIn, Inc. |
From: Mike T. M. <ji...@gm...> - 2007-07-25 22:29:48
|
Please ignore. -mike |
From: Kevin H. <kev...@gm...> - 2007-07-03 00:35:15
|
Long overdue update. The restructure is complete with testing of most all the core and example scripts done. Also there is a new HTML manual added to update documentation and consolidate it all in Assimilator/docs/manual. All the old docs were either incorporated or just deleted if they were no longer relevant. It'll be easier to maintain the docs now instead of them being scattered all over different directories. Maybe someday we can have a Wiki for the project. Next up is creating an admin console for viewing and working with services. This is to replace the opmon and viewer utilities which are outdated. Also there will be an installer for users who are non-developers and just want to deploy and manage services. Then we can get an official release out on the download page. -kevin. Kevin Hartig wrote: > Starting today the project files and directories will be reorganized. > The modifications will reduce the complexity of all the sub-levels and > simplify the builds. General cleanup will also take place removing > undesired and no longer used artifacts. > > During this refactoring, build scripts and other things will be > temporarily broken. I will post a follow-up to this thread to indicate > when the project has been successfully reorganized. > > Thanks for your patience. > > -kevin. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Assimilator-users mailing list > Ass...@li... > https://lists.sourceforge.net/lists/listinfo/assimilator-users > > |
From: Larry M. <lar...@gm...> - 2007-03-04 20:08:02
|
Hi I have done a ton of effort in the examples directory. All of it was done with regards to getting examples to work. Specifically * restructuring the configs to be more readable and shifting them to subdirs * changing the windows bat files to remove the dependency on all env files (no reason for these) * a bunch of other things We need to make sure these will run on other platforms. I put the key task of hello world but we really need to have all 5 examples working Also the hello world is way way to complex and need to be broken down into multiple hello world steps. Regards Larry |
From: Kevin H. <kev...@gm...> - 2007-02-26 15:47:37
|
From a clean svn co and ant build using the new local_env.xml file, by default an installed jre is used during the compile rather than the jdk. The jdk.tools.path points to the jre since java.home points there by default. There is no tools.jar in the jre so the javadoc errors are related to not finding the classes in sun.tools.java.* pacakages. If java.home is changed to point to the jdk or if the tools.jar is copied to the jre lib directory the errors go away. The out-of-the-box experience has the errors though. It would be nice to come up with a solution for this. Is there a way to make the local_env.xml use the jdk by default? -kevin. Mike T. Miller wrote: > Hmm, what sort of Javadoc errors are you seeing? Everything is > building on my OSX box (10.4.8 with java 1.5.0_07). > > -mike > > On Feb 25, 2007, at 4:42 PM, Kevin Hartig wrote: > > >> I set up a Mandriva 2007 box running linux core 2.6.17 checked out >> all the assimilator files from svn and built them successfully >> using Java SDK 6. The only thing I had to change in the build files >> was a reference to serviceAnalyzer to use the correct case. I will >> also try building the code on Solaris. >> >> There are still a bunch of javadoc build errors we should fix. I >> noticed a few more show up in JDK 6 then there were in JDK 5. One >> set of javadoc errors that shows up in both versions is in the >> tools build. The javadoc is looking for classes in tools.jar. In >> the default build defs it is using the jre/bin and jre/lib >> directories in the path. The tools.jar file doesn't exist there. >> Should we just exclude these files from the javadoc? >> >> -kevin. >> ---------------------------------------------------------------------- >> --- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV________________________________ >> _______________ >> Assimilator-developers mailing list >> Ass...@li... >> https://lists.sourceforge.net/lists/listinfo/assimilator-developers >> > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Assimilator-developers mailing list > Ass...@li... > https://lists.sourceforge.net/lists/listinfo/assimilator-developers > > |
From: Mike T. M. <ji...@gm...> - 2007-02-26 07:48:13
|
Hmm, what sort of Javadoc errors are you seeing? Everything is building on my OSX box (10.4.8 with java 1.5.0_07). -mike On Feb 25, 2007, at 4:42 PM, Kevin Hartig wrote: > I set up a Mandriva 2007 box running linux core 2.6.17 checked out > all the assimilator files from svn and built them successfully > using Java SDK 6. The only thing I had to change in the build files > was a reference to serviceAnalyzer to use the correct case. I will > also try building the code on Solaris. > > There are still a bunch of javadoc build errors we should fix. I > noticed a few more show up in JDK 6 then there were in JDK 5. One > set of javadoc errors that shows up in both versions is in the > tools build. The javadoc is looking for classes in tools.jar. In > the default build defs it is using the jre/bin and jre/lib > directories in the path. The tools.jar file doesn't exist there. > Should we just exclude these files from the javadoc? > > -kevin. > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > Assimilator-developers mailing list > Ass...@li... > https://lists.sourceforge.net/lists/listinfo/assimilator-developers |
From: Kevin H. <kev...@gm...> - 2007-02-26 00:42:15
|
I set up a Mandriva 2007 box running linux core 2.6.17 checked out all the assimilator files from svn and built them successfully using Java SDK 6. The only thing I had to change in the build files was a reference to serviceAnalyzer to use the correct case. I will also try building the code on Solaris. There are still a bunch of javadoc build errors we should fix. I noticed a few more show up in JDK 6 then there were in JDK 5. One set of javadoc errors that shows up in both versions is in the tools build. The javadoc is looking for classes in tools.jar. In the default build defs it is using the jre/bin and jre/lib directories in the path. The tools.jar file doesn't exist there. Should we just exclude these files from the javadoc? -kevin. |
From: Mike T. M. <ji...@gm...> - 2007-02-22 01:26:09
|
I made some changes that allow a better out-of-the-box experience with Assimilator. You should now be able to check out a fresh copy and just type 'ant'. Nothing to setup. Of course, I've only tested this on OS X, so any feedback would be appreciated. -mike |