Re: Gump-Check task
Leo Simons wrote: Maybe we could have an ant task that talks to the gump repository to keep (nay, improve on) that functionality. project default=test target name=verify-gump depends=build gump-check project=cocoon/ /target target name=test depends=build,verify-gump /target /project the gump-check task would get a list of requirements from the gump server (ie, what jars should exist, what directories, licenses, ...) and compare that info to the filesystem. It would warn the user of any errors. Like Ozzie, I'm just a dreamer ;) Let's keep dreaming. Gump looks closer to any port-like system that is out there for java stuff. We happen to have a huge amount of metadata and the automatic ability to make sure it remains in synch with it. it would *NOT* take much to do what leo is suggesting and solve the jar distribution thing. worth thinking about! -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Gump-Check task
Isn't LocalCheck (the java Gump) already doing (at least locally on the gump box), but this should be extendable to do remotely. But I guess you were discussing Gumpy :). Mvgr, Martin On Wed, 2004-03-24 at 18:12, Stefano Mazzocchi wrote: Leo Simons wrote: Maybe we could have an ant task that talks to the gump repository to keep (nay, improve on) that functionality. project default=test target name=verify-gump depends=build gump-check project=cocoon/ /target target name=test depends=build,verify-gump /target /project the gump-check task would get a list of requirements from the gump server (ie, what jars should exist, what directories, licenses, ...) and compare that info to the filesystem. It would warn the user of any errors. Like Ozzie, I'm just a dreamer ;) Let's keep dreaming. Gump looks closer to any port-like system that is out there for java stuff. We happen to have a huge amount of metadata and the automatic ability to make sure it remains in synch with it. it would *NOT* take much to do what leo is suggesting and solve the jar distribution thing. worth thinking about! -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump-Check task (was: Re: [RT] href considered harmful)
Stefano Mazzocchi wrote: Leo Simons wrote: I suggest we move to strike and loudly proclaim descriptors not living in gump CVS as harmful. Their use needs to be *strongly* discouraged from now on. Who's with me? I agree with you as a general principle. Too bad that the entire cocoon build system relies on the gump descriptor for its blocks and this is going to be so for a while. If you deprecate href, cocoon will be seriously damaged. who said anything about deprecate? I said its harmful, that's different. I consider the use of static factories in java applications harmful, but its not like static methods will be deprecated anytime soon! :D I think no-one wants to actually disable the ability to use href. Now, I am the one to blame for this, but my rationale was to keep gump and cocoon in synch by making sure that everytime you built cocoon, you were also testing if the gump descriptor was right. Of course, only gump can do the full check, but the cocoon build can help a little bit. hmm. Good point. You want the ability to verify a project state is consistent with what gump expects it to be after a build, but only gump can verify that. Maybe we could have an ant task that talks to the gump repository to keep (nay, improve on) that functionality. project default=test target name=verify-gump depends=build gump-check project=cocoon/ /target target name=test depends=build,verify-gump /target /project the gump-check task would get a list of requirements from the gump server (ie, what jars should exist, what directories, licenses, ...) and compare that info to the filesystem. It would warn the user of any errors. Like Ozzie, I'm just a dreamer ;) -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
