[g...@vmgump]: Project commons-jelly-tags-jaxme (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-30062010.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property maven.jar.commons-jexl. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-30062010.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-30062010.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-30062010.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-30062010.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-30062010.jar:/srv/gump/public/workspace/commons-jexl-1.x/target/commons-jexl-1.1.1-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-30062010.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-30062010.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-30062010.jar:/srv/gu mp/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xmlunit/build/java/lib/xmlunit-sumo-30062010.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.characters(pChars, pOffset, pLen); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:305: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.init(pData); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:315: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] __handler_Name.init(getData()); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressHandler.java:22: cannot find symbol [javac] symbol : method getData() [javac]
[JEXL] Problem Integrating JEXL 1.x Branch and Cocoon 2.2.x
Hi, after a very long time Gump has started to build larger parts of Cocoon again and we've run into an issue. Cocoon's expression language uses JEXL 1.x and in Gump it builds against the the 1.x svn branch of JEXL. Unfortunately the VelPropertyGet interface inside that branch contains a method that is new when compared to JEXL 1.1 http://vmgump.apache.org/gump/public/cocoon/cocoon22-expression-language-impl/gump_work/build_cocoon_cocoon22-expression-language-impl.html A quick scan revealed the isAlive method has been introduced as part of JEXL-13 https://issues.apache.org/jira/browse/JEXL-13 in svn revision 543702 http://svn.apache.org/viewvc/commons/proper/jexl/branches/1.x/src/java/org/apache/commons/jexl/util/introspection/VelPropertyGet.java?r1=480412r2=543702 more than three years ago. JEXL-13 claims 2.0.1 was the release to incorporate the fix, so to me it looks as if the patch should have never been applied to the 1.x branch. My suggestion would be to revert JEXL-13 from the branch, but then again I'm neither familiar with JEXL nor Cocoon's usage of it. If reverting the patch seems to be a bad idea, what would the JEXL developers recommend to the Cocoon developers going forward? I'm not sure whether migrating Cocoon to JEXL 2.x would be an option. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] 3.0-beta? [Was: When is next release of commons-lang planned?]
On 1 July 2010 03:23, Henri Yandell flame...@gmail.com wrote: On Wed, Jun 30, 2010 at 1:38 PM, sebb seb...@gmail.com wrote: On 30/06/2010, Henri Yandell flame...@gmail.com wrote: Here are example tarballs, jar and a site for a 3.0 beta: http://people.apache.org/~bayard/commons-lang-3.0-beta/ Is this basically the same code as in commons-lang-trunk? Yes - exactly the same. The site isn't intended to be ready - that can be done later. What it does right now is provide the relevant 3.0 reports. What I'd like to know right now is if it looks good and whether I should go ahead and tag 3.0-beta and do a real release build. I think we're ready to build a beta. I don't expect a lot of API change after this, and I don't know of any bugs in 3.0 that weren't in 2.x. So not a release vote, but looking for consensus from anyone (users, committers, pmc) that it's time to put a beta stake in the ground. In general I agree. However, I think it is essential to document the intended class thread-safety. For example, the mutable package is not intended to be thread-safe whereas concurrent is presumably intended to be. If you want to do that, then I can see delaying for a defined time. If it's just something you think someone else should do, I know it isn't my priority and not something I'd see as a release blocker for either a beta or for 3.0 itself. I'm happy to start adding comments to the classes and/or package.html files. The package.html files also need some work. They're pretty tiny, so shouldn't be much [unless you have visions of writing a lot in there]. Actually, when looked at in context, they are sufficient. Though it might be worth adding some details on thread safety to them. == Given that we have changed all the package names, the Clirr report is fairly useless. Is it possible to use it to compare corresponding classes? E.g. maybe use Shade to create a lang3 version of lang2 or vice-versa? Or maybe Clirr has an option to alias classes? Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] Problem Integrating JEXL 1.x Branch and Cocoon 2.2.x
Hi Stefan, I've had a quick look at the jexl-1.x source; the VelPropertyGet.isAlive method is not called anywhere in jexl's code or tests. Commenting it out from the interface does the trick. The real problem lies in changing this public interface which could be harmful to other projects that may depend on it. The easiest (obvious) route would be for you to use a locally modified / built jexl-1.x snapshot. We could also create a specific 'gump' branch with that modification but this would be really odd process-wise... A cleaner more future-proof alternative might be to use jexl-2 and the jexl-1 compatibility layer which is part of the distribution as source only ( http://svn.apache.org/viewvc/commons/proper/jexl/trunk/jexl2-compat/src/main/java/org/apache/commons/jexl/ ); I might help/check feasibility if needed. Cheers Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-Problem-Integrating-JEXL-1-x-Branch-and-Cocoon-2-2-x-tp2274718p2274885.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] Problem Integrating JEXL 1.x Branch and Cocoon 2.2.x
On 2010-07-01, Stefan Bodewig wrote: On 2010-07-01, henrib wrote: A cleaner more future-proof alternative might be to use jexl-2 and the jexl-1 compatibility layer which is part of the distribution as source only ( http://svn.apache.org/viewvc/commons/proper/jexl/trunk/jexl2-compat/src/main/java/org/apache/commons/jexl/ ); OK, I see - I may look into building that inside Gump for starters. Done. The layer doesn't provide oac.jexl.util.* which means it wouldn't be useful for the Cocoon case, though. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml-eclipse] User guide feedback
On Wed, Jun 30, 2010 at 11:21 PM, Xun Long Gui ustbco...@gmail.com wrote: Hi Rahul, Thank you for your carefully reiview of the website content. Yes, if you want to edit homepage content, just do it, it is ok, this is our project. snip/ Great, will do so when I get a chance. -Rahul And also, i will fix these problems follow your instruction. -Gui Xun Long On 7/1/10, Rahul Akolkar rahul.akol...@gmail.com wrote: Long, Thanks for updating the [scxml-eclipse] site with the user guide, its looks great and is certainly more accessible than before. Some feedback: * Do you mind if I make some changes to the second paragraph of the home page [1]? I want to correct a couple of typos and its also too conversational for my taste. Such a style may work very well for the guide and other places, but I think for the home page intro we want something slightly more formal. * The 5 min intro to SCXML [2] should simply link to the Commons SCXML page [3] rather than having the same page here for two reasons: (a) avoid duplication of content, harder to maintain; and (b) broken links, such as custom actions at the very end. So, the guide can say something like for a 5 min intro, go to this other site ... * Remove the Coming soon ... sections on the guide page [4]. We don't anticipate APIs in the programming sense being important at the user level for such tooling. We can add other sections when they become available. * At the bottom of the guide pages, the contact is your personal address. In general, we want discussions on the mailing list (so all project discussions can be followed and archived etc.), so I suggest changing to something like ... any questions or suggestions, please send to the Commons user or dev mailing list as appropriate. (and perhaps link to the mailing list page). Bit of an aside, at Commons, we do list project members on the Team page. -Rahul [1] http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/index.html [2] http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/guide/scxml-documents.html [3] http://commons.apache.org/scxml/guide/scxml-documents.html [4] http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/guide.html -- Best Regards Gui Xun Long (桂训龙) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml-eclipse] Basic website up for project and ppt - xdoc
On Thu, Jul 1, 2010 at 4:07 AM, Xun Long Gui ustbco...@gmail.com wrote: Hi Rahul, I have added a new issue COMMONSSITE-58 [1] which has an attachment file in JIRA system to add GSoC relative section in Commons Sandbox index page, now i think you can help me to apply it and deploy it. And also, i have modified Commons SCXML index xdoc file to make it includes a relative projects section which have url links to Jacob's and mine project, submitted it as an attach file of issue COMMONSSITE-59 [2] in JIRA system. If you have time, please help me to deploy them, thank you. snip/ Thanks, I will take a look -- its a long weekend and I'm traveling, so this may have to wait till Tuesday or so. COMMONSSITE-59 is now SCXML-150 (it belongs to SCXML in JIRA). -Rahul [1]https://issues.apache.org/jira/browse/COMMONSSITE-58 [2]https://issues.apache.org/jira/browse/COMMONSSITE-59 On 7/1/10, Rahul Akolkar rahul.akol...@gmail.com wrote: 2010/6/30 Xun Long Gui ustbco...@gmail.com: Hi Rahul, I have add some instruction content in the website, now, i notice that there is not any url link to my project website in sandbox index page [1], i want to add a link in the page to make more people know about our project, how can i do it ? snip/ Edit the main Commons site source, see xdocs here: http://svn.apache.org/repos/asf/commons/proper/commons-build/trunk/ You'll have to submit a patch via JIRA (use COMMONSSITE component) since this isn't in the sandbox. I can help with applying the patch and deploying the Commons website. I think we should add a separate GSoC section to the sandbox page [1] and while we're at it, create the two landing pages [3, 4] that are missing. And also, i think if we can add a link to Visual SCXML editor website in Commons SCXML website [2], it is also very useful for the guys who are interested in SCXML to know about this editor tool. What do yo think ? snap/ Yes -- we can add a Related Work or Related Projects section at the bottom of [2]. If you want, you can attach a patch for the Commons SCXML site to JIRA (SCXML component) for that change containing pointers to this year's two GSoC projects. -Rahul [3] http://commons.apache.org/sandbox/gsoc/ [4] http://commons.apache.org/sandbox/gsoc/2010/ [1] http://commons.apache.org/sandbox/index.html [2] http://commons.apache.org/scxml/index.html snip/ -- Best Regards Gui Xun Long (桂训龙) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] 3.0-beta? [Was: When is next release of commons-lang planned?]
On Thu, Jul 1, 2010 at 2:13 AM, sebb seb...@gmail.com wrote: On 1 July 2010 03:23, Henri Yandell flame...@gmail.com wrote: On Wed, Jun 30, 2010 at 1:38 PM, sebb seb...@gmail.com wrote: On 30/06/2010, Henri Yandell flame...@gmail.com wrote: Here are example tarballs, jar and a site for a 3.0 beta: http://people.apache.org/~bayard/commons-lang-3.0-beta/ Is this basically the same code as in commons-lang-trunk? Yes - exactly the same. The site isn't intended to be ready - that can be done later. What it does right now is provide the relevant 3.0 reports. What I'd like to know right now is if it looks good and whether I should go ahead and tag 3.0-beta and do a real release build. I think we're ready to build a beta. I don't expect a lot of API change after this, and I don't know of any bugs in 3.0 that weren't in 2.x. So not a release vote, but looking for consensus from anyone (users, committers, pmc) that it's time to put a beta stake in the ground. In general I agree. However, I think it is essential to document the intended class thread-safety. For example, the mutable package is not intended to be thread-safe whereas concurrent is presumably intended to be. If you want to do that, then I can see delaying for a defined time. If it's just something you think someone else should do, I know it isn't my priority and not something I'd see as a release blocker for either a beta or for 3.0 itself. I'm happy to start adding comments to the classes and/or package.html files. Go for it :) The package.html files also need some work. They're pretty tiny, so shouldn't be much [unless you have visions of writing a lot in there]. Actually, when looked at in context, they are sufficient. Though it might be worth adding some details on thread safety to them. I think the class files are probably sufficient - having better package.htmls would then be a separate task and would presumably include covering thread safety. == Given that we have changed all the package names, the Clirr report is fairly useless. Is it possible to use it to compare corresponding classes? E.g. maybe use Shade to create a lang3 version of lang2 or vice-versa? Or maybe Clirr has an option to alias classes? Or simpler; a mv of the lang3 directory to lang then running of the clirr report. I've had that setup and running, I just need to put a computer back where it used to be post some home improvement and get it pushing the page up to people.apache. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] 3.0-beta? [Was: When is next release of commons-lang planned?]
On 1 July 2010 16:29, Henri Yandell flame...@gmail.com wrote: On Thu, Jul 1, 2010 at 2:13 AM, sebb seb...@gmail.com wrote: On 1 July 2010 03:23, Henri Yandell flame...@gmail.com wrote: On Wed, Jun 30, 2010 at 1:38 PM, sebb seb...@gmail.com wrote: On 30/06/2010, Henri Yandell flame...@gmail.com wrote: Here are example tarballs, jar and a site for a 3.0 beta: http://people.apache.org/~bayard/commons-lang-3.0-beta/ Is this basically the same code as in commons-lang-trunk? Yes - exactly the same. The site isn't intended to be ready - that can be done later. What it does right now is provide the relevant 3.0 reports. What I'd like to know right now is if it looks good and whether I should go ahead and tag 3.0-beta and do a real release build. I think we're ready to build a beta. I don't expect a lot of API change after this, and I don't know of any bugs in 3.0 that weren't in 2.x. So not a release vote, but looking for consensus from anyone (users, committers, pmc) that it's time to put a beta stake in the ground. In general I agree. However, I think it is essential to document the intended class thread-safety. For example, the mutable package is not intended to be thread-safe whereas concurrent is presumably intended to be. If you want to do that, then I can see delaying for a defined time. If it's just something you think someone else should do, I know it isn't my priority and not something I'd see as a release blocker for either a beta or for 3.0 itself. I'm happy to start adding comments to the classes and/or package.html files. Go for it :) I've already done the package files; decided it was quicker! The package.html files also need some work. They're pretty tiny, so shouldn't be much [unless you have visions of writing a lot in there]. Actually, when looked at in context, they are sufficient. Though it might be worth adding some details on thread safety to them. I think the class files are probably sufficient - having better package.htmls would then be a separate task and would presumably include covering thread safety. == Given that we have changed all the package names, the Clirr report is fairly useless. Is it possible to use it to compare corresponding classes? E.g. maybe use Shade to create a lang3 version of lang2 or vice-versa? Or maybe Clirr has an option to alias classes? Or simpler; a mv of the lang3 directory to lang then running of the clirr report. I've had that setup and running, I just need to put a computer back where it used to be post some home improvement and get it pushing the page up to people.apache. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Commons Wiki] Update of 3377 by 3377
Dear Wiki user, You have subscribed to a wiki page or wiki category on Commons Wiki for change notification. The 3377 page has been changed by 3377. http://wiki.apache.org/jakarta-commons/3377 -- New page: Have the power to place, have the responsibility. Responsibility is to power the twin objects of power, of course the results and necessary complement. This is consistent with well-known principle of authority and responsibility. Fayol that to implement the powers and responsibilities consistent with the principle, it should be effective reward and punishment system, that is, should be encouraged to stop their beneficial actions contrary action. In fact, this is now we speak of rights, responsibilities and interests the principle of combining. 3. Discipline principles Fayol that discipline should include two aspects, namely business and the agreement between subordinates and people's attitude to this Agreement and the agreement compliance. Fayol that discipline is the key to the prosperity of an enterprise, no discipline, no business can prosper. He believes that the development and maintenance of discipline of the most effective way: ① good leadership at all levels. ② as clearly as possible and fair agreement. ③ reasonable implementation of the punishment. Because discipline is created by the leaders. ... ... No matter which social organization, its discipline, all depends on the moral status of their leaders. 4. The principle of unified command Unity of command is an important management principles, in accordance with the requirements of this principle, a lower-level officers can only accept a higher level of command. If the two leaders at the same time the same person or the same thing to exercise their power, there will be chaos. In any case, there would not be to adapt the dual command of social organization. And the principle of unity of command was also under the principle that the principle of unified leadership. 5. The principle of unified leadership The principle of unified leadership means: strive to achieve the same purpose for all activities, only one leader and a plan. ... ... As human society and the animal kingdom, a body with two heads is a monster, it is difficult to live . stresses the principle of unified leadership is a subordinate only one direct superior. It is different with the principle of unity of command, unity of command principle stresses that a subordinate can only accept a higher level of instruction. These two principles are different but also contact. The principle of unified leadership of the organization say that the problem set, that set the organization's time, a subordinate can not have two immediate superiors. The principle of unity of command about the organization set up after the operation, namely, when the organization established after the process in operation, a lower level can not accept the two superior orders. 6. Personal interests to the overall interests of the principle of For this principle, Fayol think it is clear some people are well aware of the principles, but often ignorant, greedy, selfish, lazy, and all human impulses are always people to forget the overall interests of individual interests. In order to adhere to this principle, Fayol that the successful approach is: ① leaders of firmness and good role models; ② fair agreement entered into as far as possible; ③ careful monitoring. 7. Workers compensation principle Fayol that, first of all remuneration depends from employers and their staff will be affected some of the circumstances, such as the cost of living level, the number of personnel can be employed, the general business situation of the enterprise's economic status, then staff to look at the last to see the return by way of. Workers compensation first consideration is to maintain the minimum living of workers and enterprises in the basic operating conditions, determine the remuneration which is a basic starting point. On this basis, consider a contribution under the employee's work to determine the appropriate compensation method. For a variety of compensation methods, Fayol means that regardless of the reward, should be able to do the following: ① it can ensure fair remuneration; ② It can reward good work and inspire enthusiasm; ③ it should not lead to more than reasonable limit excessive pay. 8. Focus on the principles of Fayol refers to the organization of power centralization and decentralization issues. Fayol that the issue of centralized or decentralized is a simple measure of the problem, the problem is find the most appropriate to the enterprise. In small businesses, can be the leader higher order transmitted directly to the lower staff, so the power is relatively more concentrated; in large-scale enterprise, at the top among the leaders and the grassroots, there are many intermediate links, and therefore, the power to
