开发中经常用到 maven jetty:run，特别是它支持 多个 webapp 资源目录 的特性，在开发环境中相当有用。比如，src/main/webapp 是 prod 的资源，而有些开发或者测试时用到的资源可以安心的放在 src/test/webapp。可以 参考这里 详细了解怎么使用。 但是，迁移了环境之后，发现它总是报错： [ERROR] BUILD ERROR [INFO] ———————————————————————— [INFO] Failed to configure plugin parameters for: org.mortbay.jetty:maven-jetty-plugin:6.1.22 (found static expression: 'src/main/webapp,src/test/webapp' which may act as…
分析新的需求，确实需要增强 jscombiner 了。之前写了一半，时间不够，大家急着看效果。今天把另外一半补上。再修补一下，可以升级到 0.4-SNAPSHOT 了。工具，好用是最实在的。 这次主要是增强了 classpath 的概念。原先使用时不需要设置根类路径，根据文件中的 @class 声明来反向定义根类路径。相应地，入口调整为 buildHierarchy(String className)。外表看来变动很小，而且实现着一样的效果，但是里面整个寻址方式都变了。 代码本身没什么值得深究的。不过结构变了。几番修改，有些共通点： 重要的功能需要规划 实现的进度是看需求的 不到最后不得不修改结构，不会乱动 测试用例需要有一定的抽象 重构很重要 结构发生变化，重写比重构快
这个任务是要求每秒触发一次。 一开始我尝试用 Timer 的 scheduleAtFixedRate，通过简单的测试，发现它会慢慢地累积形成时间差。 虽然这里不要求非常的精确，但是如果只是在某点附近徘徊，不会发生累积的，听起来是不是会好一点呢？ 于是就诞生了下面的代码。 while (true) { try { long i = 1000 – System.currentTimeMillis() % 1000; if (i > 100) { Thread.sleep(i); } else { Thread.sleep(1000 + i); } } catch…
为自己写个工具 Jscombiner，除了帮助自己高效完成任务，可以自娱自乐，还可以开源，和别人分享。 这个工具前一个版本是命令行方式的，一方面技术所限，另一方面是一直坚持认为前台和后台开发是可以而且应该分开进行的。 当然思考的结果是会变的，该分开的还是分开，但有时后台也应该为前台开发提供一些帮助，而单纯的apache httpd提供不了，也有想过用asp, php，但是按照目前的态势，java应该更熟手一点。而且我主要是想和公司的其它同事分享这种开发方式，他们的机器上大多有tomcat而没有apache。 Jscombiner 的基本目标就是减少程序员开发 javascript 项目时所需要投入的管理成本。让 javascript 脚本采取自描述的方式来方便进行管理。因此，开发者可以在开发过程中，随心所欲地更新脚本，而无需担心重构或者脚本规模增长所带来的管理成本。是不是已经有同样的东西存在，我不确定，有是正常的，多个选择，多个竞争，才会有进步的。也许是有开发者像我这样不善推广的。 现在的状况是基本功能以及有了，自己一直在用，我期望的使用感受是感觉不到它的存在。 不过，不是为了做这个东西而做的，还有其它的目标任务，而且只有我一个人在瞎搞，而且主要的更新都是针对自己的实际应用需求的（我相信我所遇到的问题，其它人也会在某个时刻遇到），所以更新会比较慢。 等当前任务完成了，再做一个example出来。不过其实想想也很简单的，mvn archetype:generate一个项目出来，加入依赖，将脚本丢进去，然后mvn jetty:run，立马就可以着手开发了。 关于这个项目的改进计划会在Issue里面发起。目前想到的一个就是先实现前一版本中的一个功能，合并大脚本，这个应该不难，只是怎么提供出来，会更实用，更有趣呢？敬请期待啦！