those are the only two procedural tags that we have in the descriptors. AFAIK, <delete is currently turned off for security reasons and <mkdir is something that gump could easily infer by itself (basically, gump can try to read all the directories that are references in the descriptors and, if not there, they can be built. this would allow us to reduce the problems with the cognitive dissonance created by procedural behavior in metadata descriptors. thoughts? -- Stefano.
On Sun, 10 Oct 2004, sebb <se...@gmail.com> wrote: > Seems to me that the build files run by Gump should automatically > create any directories they need anyway? Or am I missing something? Yes, the directory have to exists before Ant/Maven is started, creating the during the build is too late. This is the "JVM drops CLASSPATH entries that don't exist on startup" problem. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@gump.apache.org For additional commands, e-mail: general-help@gump.apache.org
On Sun, 10 Oct 2004 02:37:06 -0400, Stefano Mazzocchi <st...@apache.org> wrote: > those are the only two procedural tags that we have in the descriptors. > > AFAIK, <delete is currently turned off for security reasons and <mkdir > is something that gump could easily infer by itself (basically, gump can > try to read all the directories that are references in the descriptors > and, if not there, they can be built. > > this would allow us to reduce the problems with the cognitive dissonance > created by procedural behavior in metadata descriptors. > > thoughts? Seems to me that the build files run by Gump should automatically create any directories they need anyway? Or am I missing something? --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@gump.apache.org For additional commands, e-mail: general-help@gump.apache.org
Stefano Mazzocchi wrote:
> those are the only two procedural tags that we have in the descriptors.
<ant/> ?
<maven/> ?
in the future,
<configure/> ?
<make/> ?
gump at some level has to emulate typing stuff in at the console. The
console is procedural. I suggest isolating the procedural bits, maybe
<project name="jo" xmlns="gump">
<input>
<depend name="blah"/>
<basedir name="src"/>
</input>
<build xmlns="gump-build">
<mkdir name="build"/>
<ant target="prep"/>
<ant target="build"/>
<autoconf/>
<make target="all"/>
<make target="install"/>
<ant target="custom">
<project>
<target name="custom">
<rpm script="build-rpm.sh"/><!-- whatever -->
</target>
</project>
</ant>
<script shell="sh">
gpg --detach jo.jar --output jo.asc # whatever
</script>
</build>
<output>
<jar name="jo.jar"/>
<msi name="jo.msi"/>
<rpm name="jo.rpm"/>
</output>
</project>
or something like that. I doubt we'll be able to remove the "commandline
equivalent" from the model.
It is probably possible to remove the <build/> from the model and use
some semantics ("run gump.py" in project dir), but the downside is that
we'll lose the ability to "blame" specific parts of the build process
automatically.
> this would allow us to reduce the problems with the cognitive dissonance
> created by procedural behavior in metadata descriptors.
>
> thoughts?
it ain't just metadata. Currently, there really is procedural stuff that
gump needs to know. It needs to be able to do what programmers do behind
their console.
Maybe best to isolate the procedural bits (use xml namespaces?). But I
doubt they can be removed completely, and I also doubt that we want to
sacrifice their power...
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
> AFAIK, <delete is currently turned off for security reasons > > Is it? > > IIRC I added <delete> to ensure that two different builds inside the > same directory tree didn't affect each other. mockobjects? Yes, I > think so. Basically I was building the same project twice against two > different sets of dependencies. > > Not using <delete> but using to different build directories (or even > separate modules) would have been cleaner. No problem with cleaning > this up - delete can go. It was turned off, until I figured out (i.e. re-read the documentation) that it could be done relative to the project, so not a danger of deleting /. If there were any '..' entries in the path it was rejected. Crude, but hopefully "good enough". So, right now it is enabled. > > and <mkdir is something that gump could easily infer by itself > > (basically, gump can try to read all the directories that are > > references in the descriptors and, if not there, they can be built. > > If Gump does that, fine. Yup, I agree. We ought add it to JIRA. We'd be removing an issue for folks that is quiet obscure, and no new user ought need to know such things. regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@gump.apache.org For additional commands, e-mail: general-help@gump.apache.org
On Sun, 10 Oct 2004, Stefano Mazzocchi <st...@apache.org> wrote: > AFAIK, <delete is currently turned off for security reasons Is it? IIRC I added <delete> to ensure that two different builds inside the same directory tree didn't affect each other. mockobjects? Yes, I think so. Basically I was building the same project twice against two different sets of dependencies. Not using <delete> but using to different build directories (or even separate modules) would have been cleaner. No problem with cleaning this up - delete can go. > and <mkdir is something that gump could easily infer by itself > (basically, gump can try to read all the directories that are > references in the descriptors and, if not there, they can be built. If Gump does that, fine. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@gump.apache.org For additional commands, e-mail: general-help@gump.apache.org