On 8/5/01 6:46 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
Sorry for taking so long to respond. I was at the beach getting sunburned
:-)
> Jason van Zyl wrote:
>>
>> 1) Could we make the whole process an Ant task?
>
> http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/antgump/
>
>> 2) Project descriptors need to be normalized, the project file is really a
>> set of targets. Right now there is a top level project and nested projects
>> in a project XML descriptor. I would like to be able to readily convert the
>> XML descriptors into java objects and this makes it difficult. So the
>> project XML descriptor should actually look more like the build.xml file for
>> a project. Maybe we could eventually move toward using a projects build.xml
>> file for the descriptor if we got a little more standard.
>
> The are not just targets, often they have their own dependencies, and quite
> often completely different build.xml files. In many cases
> (jakarta-commons), they essentially *ARE* multiple projects in the same cvs
> repository.
Ok, my main point is that they should be normalized.
> I don't see how this makes conversion into java objects harder.
I think the mapping is less obvious with projects at the top level of the
document and there being nested projects. The digester rules would be much
simpler for an XML file where all projects were nested. I'm not even sure I
could make a digester for the XML files as they are. I imagine it probably
takes into account exceptional mappings.
> And if it
> helps, the current gen.java code already unnests and flattens this into a
> list of independent projects already. Perhaps you could use that as your
> starting point? If you run the "gen" script, this intermediate result is
> output in the work directory as "merge.xml".
I would prefer to use the digester to process the XML to create a set of
java objects and use the dependeny engine that geir wrote. But I'll be using
Gump in it's current form to provide more feedback and get the harness for
the TDK going. I can probably provide more useful feedback as I am trying
things with the TDK.
>> 3) Allow a directory with overriding repository descriptors, so that your
>> customized configuration matches the form of the anonymous access repository
>> descriptors. Again so that it's easier to convert the XML to a Java object.
>
> I don't know what you intend by "a directory" of overriding repository
> descriptors. What I was thinking of was a simple "tag" attribute on a
> project definition which would override the tag attribute on the cvs line.
> This would allow the default version to be defined at the project level,
> and optionally overridden at the profile or workspace level.
What I meant was a set of files that look just the files that are in CVS for
gump. If gump sees a repository descriptor that is used by a project that
has been overriden it would use that instead of the default. So it would use
my jakarta account to retrieve the source instead of using anonymous access.
> In fact, I just committed the code. I'm sorry that this is in the section
> which has not been converted to java yet, but it is functional; and all
> things in good time.
No problem.
>> 4) Use ${lib.repo} as defined in ~/build.properties as the place to look for
>> external jar files so that we can remove that info from the workspace.
>
> I already made the suggestion that I should have default directory defined
> in the workspace (and that you can certainly generate a workspace on the
> fly from a properties file, if that is your desire); but I sense that there
> is a more fundamental disconnect here.
>
> If I understand your proposal correctly, this would be a flat directory
> into which one places all of the jars that one might depend on.
Yes, basically a repository of binaries.
> What I was
> envisioning was a directory in which one unpacks - into subdirectories -
> each of the things one might "install", such as JAAS, JDBC, JMS, ... or
> perhaps even Ant. These installations are likely to have an internal
> directory structure.
>
>> 5) Make it so that updating the gump repository doesn't affect a local setup
>> so that I can get any new dependency information and just build again.
>
> Either I don't follow, or this is already possible today. I can certainly
> do a cvs update of gump, gen, and build of the project desired without
> requiring anything in that project to be updated.
If I remember it was the external JAR references that were throwing me off.
But I will try again with the TDK so I can give some difinitive responses.
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
