Re: a few questions on our descriptors
On Sun, 10 Oct 2004, Leo Simons <[EMAIL PROTECTED]> wrote: > I believe the old gump actually had an XSLT snippet which performed > this "macro expansion". No, it has been done in Java. inside of Ant can only specify a single jar while on the outside can depend on more than one - so the code had to keep track of the jar ids involved. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a few questions on our descriptors
On Sun, 10 Oct 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > On Sunday 10 October 2004 01:38, Stefano Mazzocchi wrote: > >> gosh, this is all very confusing, people. > > No shit. AFAIUI, it is something about feeding the ant script with > additional information need to properly build those projects. Uhm, yes. But the information is needed by the build file, not Ant. Most of the time the builds want to copy files referenced by properties and we need to override those properties, that's all. > Personally, I think Gump has the wrong approach. It tries to adopt > to whatever way the project is structured, but still ends up > requiring explicit support in the build system of most projects, I don't think this is true. Most projects build from their build files without doing anything specific in order to make Gump happy. There are a few projects that need to do something special for Gump, most of the time it is in order to break circular dependencies - like the dom4j <-> jaxen problem - or because they require passing JUnit tests before creating a jar but the tests fail in Gump. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a few questions on our descriptors
On Oct 9, 2004, at 6:24 PM, Stefano Mazzocchi wrote: The golden rules of metadata are: 1) should be declerative (procedurality should be inferred) 2) semantics should be absolute and not positional the XML model makes it hard to do 1) and extremely hard to do 2). Gump descriptors are perfect examples of a markup that started as 1), didn't even notice 2) and ended up breaking 1) as a result. Sigh, I guess we have a lot more work to do than I expected :-/ Third golden rule of metadata 3) should minimize semantic redundancy Great, we have found how gump descriptors break all three rules. And yet it has worked all these months ;) I guess it's time to go back to the drawing board. Just don't throw the baby out with the bath in the quest for the perfect metadata. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a few questions on our descriptors
Sam Ruby wrote: Stefano Mazzocchi wrote: There are two places where you can put 1) inside 2) inside jakarta-slide.xml uses both. First of all, what is the rationale behind this? if a project depends on another project, why do we need to specify things further for ant? Think of elements inside of as macros. It expands to a element inside of and a element inside of . [stefano bangs head against the wall] Gump has always needed elements. Sure. Some projects have required the same information (specifically jar paths) to be provided to ant as properties. As noted in the documentation[1], "that has become a common enough practice that it makes sense to introduce this element". The golden rules of metadata are: 1) should be declerative (procedurality should be inferred) 2) semantics should be absolute and not positional the XML model makes it hard to do 1) and extremely hard to do 2). Gump descriptors are perfect examples of a markup that started as 1), didn't even notice 2) and ended up breaking 1) as a result. Also, I don't understand the difference between: and why are they different? and, if so, why are their methods so similar? They are intentionally very similar. A inside of an definition has exactly the same meaning as a inside of an definition PLUS a element inside the project definition (minus the property attribute). And this was introduced to help out, I guess. Sigh, I guess we have a lot more work to do than I expected :-/ Third golden rule of metadata 3) should minimize semantic redundancy Great, we have found how gump descriptors break all three rules. I guess it's time to go back to the drawing board. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: a few questions on our descriptors
Stefano Mazzocchi wrote: There are two places where you can put 1) inside 2) inside jakarta-slide.xml uses both. First of all, what is the rationale behind this? if a project depends on another project, why do we need to specify things further for ant? Think of elements inside of as macros. It expands to a element inside of and a element inside of . Gump has always needed elements. Some projects have required the same information (specifically jar paths) to be provided to ant as properties. As noted in the documentation[1], "that has become a common enough practice that it makes sense to introduce this element". Also, I don't understand the difference between: and why are they different? and, if so, why are their methods so similar? They are intentionally very similar. A inside of an definition has exactly the same meaning as a inside of an definition PLUS a element inside the project definition (minus the property attribute). - Sam Ruby [1] http://gump.apache.org/metadata/builder.html#depend - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a few questions on our descriptors
On Sunday 10 October 2004 01:38, Stefano Mazzocchi wrote: > gosh, this is all very confusing, people. No shit. AFAIUI, it is something about feeding the ant script with additional information need to properly build those projects. Personally, I think Gump has the wrong approach. It tries to adopt to whatever way the project is structured, but still ends up requiring explicit support in the build system of most projects, so why not make Friend-Of-Gump a requirement in those projects. Perhaps not more work, but a hell of lot easier to understand for each project's community. Basically, 1) Gump ask via a script which dependencies the project has. 2) Gump passes those artifacts from its earlier builds, tells the project's script to build. (alternatively, all the artifacts output can be structured as a local Maven repository, and just pass the repository location) 3) That script hands back a list of artifacts that was built. Wouldn't most project communities say, "Hey that is easy. Can do in a day or so."? without involving Gumpmeisters who are a bottleneck. Just my thoughts... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
a few questions on our descriptors
the most important part of the gump descriptors are, without doubts, the dependencies. So, today, I picked one of the failing projects (jakarta-slide) and recognized that it was a missing dependency (commons-logging). So, simply enough, I opened up the jakarta-slide.xml module and then looked at the gump information at http://brutus.apache.org/gump/public/jakarta-slide/jakarta-slide/index.html to understand what to do. There are two places where you can put 1) inside 2) inside jakarta-slide.xml uses both. First of all, what is the rationale behind this? if a project depends on another project, why do we need to specify things further for ant? Also, I don't understand the difference between: and why are they different? and, if so, why are their methods so similar? Also, look at the gump "annotations": it says "unnamed property for [jakarta-slide] in depend on: jakarta-lucene. and this is because without further attributes. But then I look at the jakarta-lucene.xml attributes and find out that there are no properties exposed! so, what does that mean? should I move that gosh, this is all very confusing, people. the vanilla descriptors (jakarta-lucene.xml) for example, are nice, simple and immediate for people to understand, but things like jakarta-slide.xml are not and I suspect it might also the reason why they break down more. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
