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}?
> 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.
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. 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.
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. 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.
> 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.
> 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.
- Sam Ruby
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
