On 1/16/02 11:46 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> Jason van Zyl wrote:
>>
>> I have a first, very rudimentary auto jar downloader working from the
>> version deps in the project descriptors.
>
> Cool!
>
>> Could we discuss the layout of the jars you produce in the nightly builds?
>> Could we move toward something that could be used by the auto build system
>> so that people can use released versions and the latest nightlies if they
>> wish.
>
> Sure. Can we also expand the discussion to include the layout of jars in
> ${lib.repo}?
By all means, I would also like to bring up the discussion of the
descriptors again themselves ;-)
>> I was thinking that the main JAR archive could be listed by project so the
>> auto downloader can find them a little easier. Possibly just a different
>> view of what you have now using symlinks.
>>
>> Then within the project directory either directories for the different
>> versions if we are going to keep version numbers out of the jars, or we can
>> put the jars all in the same directory if we are going to use version
>> numbers. Basically I would like to combine what's available under
>> http://jakarta.apache.org/builds/ with what Gump produces night to create a
>> unified JAR archive.
>
> FYI, gump produces a number of those things you find in
> jakarta.apache.org/builds. But I am open to discussing any alternate
> layout.
Cool, I have no concrete scenerios that I think will work but many of the
developers who normally couldn't build any of the turbine projects could now
build stratum and turbine-3 without difficulty so they might have some
input. As well the build mode will have to work in such a way that
developers can have mix and match builds using jars and sources. Our
specific case being the core Turbine developers working on
Turbine/Fulcrum/Stratum while using jars for everything else, and part-time
developers only wanting to build say Turbine.
I think in the next couple days some ideas will fall out. I just a little
distressed at the number of people having difficulting building the projects
because I insisted on taking the JARs out of CVS so the task solves the
problem but definitely needs fleshing out.
> What I personally would like to see is a repository layed out like an
> idealized ${lib.repo} would be. You can browse between alternate versions
> of a complete set, looking at such things as stability, outputs of tests
> that were run, etc, and thereby make an informed decision before you
> download.
Not quite sure what you mean here? I was imagining the tool taking defaults
set out by project release managers and that only experienced developers
would override the defaults.
> But once you make your decision, you have the opportunity to
> download a complete and internally consistent set. Once unpacked, you are
> instantly ready to build any project against your own personal repository,
> and the fruits of your own labors are instantly made available to any other
> projects you might happen to build.
>
> As an example of this, take a look at
> http://gump.covalent.net/jars/latest/alljars.zip . At the moment, it may
> be a bit big for some people to swallow, but hopefully in the future some
> people will design profiles which are tailored to specific audiences.
Again, I'm not quite sure what you're driving at.
> FYI: I see the inclusion of version numbers in the names of jars as a minor
> speedbump to this process - users would have to adjust various entries in
> their build.properties files after they download.
I'm not picky about the version numbers, they can go. But I would like it if
the deps are listed (right now in a simple text file as a result of a dvsl
process mostly) in the project descriptor which will be in the project's cvs
and the classpath can be built from that so edits only have to be made in
one place.
> My preferred approach at
> the moment is to have such artifacts be generated based on the project
> descriptors, and tailored to the specifications of their personal
> workspace. Of course, I personally use gump for that.
I'm all for the information coming from the descriptors. I have no problem
with that. I use a mixture of Maven and Gump for most things.
>> Then do you think we could figure out a schedule and strategy for
>> distributing the archive to a number of machines. Maybe the same mirroring
>> strategy used for the apache http products?
>
> What other machines do you have in mind? A simple strategy of rsynch +
> cron should do the trick. I'm a bit concerned about the performance of
> daedalus.apache.org lately.
Rsynch + cron would be good to start but maybe something like cpan does
where it figures out what's closest to you.
>> I'm keep to keep working on the auto downloader and builder. So far only 4-5
>> people have tried to build stratum and they have all been successful. I
>> added simple proxy support so a user behind a firewall also built stratum
>> successfully.
>>
>> I am now very excited! :-)
>
> Don't worry, it will pass. ;-)
>
> As you can plainly see, I have a long term vision that I am executing on.
I'm with you there, though my bent in particular are metrics and the
navigation of project in general. I'm also interested in building but I
think that is only one (granted very important) aspect of a project.
I've only got night time for work for a bit, but once I get turbine 2/3
working with cactus in a testbed format I will go back to Maven as that's
where I would like the auto jar downloader and some other tools that are in
the TDK. And then I would actually like to propose the wholesale removal of
Alexandria and replace it with Maven.
> - Sam Ruby
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
