-
1. Re: Repository Structure
adrian.brock Aug 5, 2005 12:07 PM (in response to ruel.loehr)The structure is actually
repository.jboss.com/
repository.jboss.com/licenses/
repository.jboss.com/component name/
repository.jboss.com/component name/version
repository.jboss.com/component name/version/lib
repository.jboss.com/component name/version/resources
repository.jboss.com/component name/version/src -
2. Re: Repository Structure
adrian.brock Aug 5, 2005 12:11 PM (in response to ruel.loehr)I want the structure of each "version" subfolder to be as close as possible
to what is generated from the "output" folder of our source projects.
So it would also contain at least:
repository.jboss.com/component name/version/api
repository.jboss.com/component name/version/docs
That way, you can "checkout" that folder as a replacement for the source project
without too much thought. The new build just needs to do the mapping
source checkout -> binary checkout
component/output -> thirdparty/component -
3. Re: Repository Structure
adrian.brock Aug 5, 2005 12:16 PM (in response to ruel.loehr)OFF TOPIC:
Wouldn't it be a good idea to have the license identifier be the URL where it can
be download from the information supernetweb?
e.g in component-info.xmllicenseType="http://www.gnu.org/copyleft/lesser.html"
or at least the url in the repostitory?licenseType="http://repository.jboss.com/licenses/lgpl.txt"
-
4. Re: Repository Structure
starksm64 Aug 5, 2005 12:30 PM (in response to ruel.loehr)That has the same problem as any namespace element that cannot be reliably used as something it looks like, but in fact is not. So when we move the repository to mirrors.jboss.com, the identifier is still a valid license uri, but cannot be used as a valid url. In the current use, it simply means additional parsing to obtain the key to form the actual url to use for the license.
Using the name as the foreign license location certainly makes no sense as we have no control over their location. -
5. Re: Repository Structure
adrian.brock Aug 5, 2005 12:51 PM (in response to ruel.loehr)"scott.stark@jboss.org" wrote:
Using the name as the foreign license location certainly makes no sense as we have no control over their location.
I would say that validating the url should be a part of the regression testing of cruisecontrol?
This is probably more important for the download urls of thirdparty jars, e.g. this problem
http://jira.jboss.com/jira/browse/JBAS-1885
Anyway, this is getting even more off topic. -
6. Re: Repository Structure
starksm64 Aug 5, 2005 1:38 PM (in response to ruel.loehr)I agree that the src related structure should match the corresponding source module structure so that I can recreate a source view for a tagged release without having to figure out what the version control modules and tags are.
So, I guess this requires?
src/src.zip
src/build.xml -
7. Re: Repository Structure
starksm64 Aug 5, 2005 1:45 PM (in response to ruel.loehr)I don't think we should be validating any of the urls though. It is relevent to this thread in that our repository should be a self-contained collection of the content that we need to support our products. For thirdparty component x that has been integrated into jems, I don't really care if the project falls of the face of the earth tomorrow provided that I have the docs, buildable source code, and license terms.
The project still can be of interest for looking for updates and checking for known bugs, but that is beyond the scope of the repository. -
8. Re: Repository Structure
starksm64 Aug 5, 2005 2:46 PM (in response to ruel.loehr)Going through the creation of the velocity patch illustrates a problem with creating a self sufficient repository. The velocity parser relies on javacc, but it does not include javacc in its source dist. Probably because its not actually needed unless one wants to regenerate the parser source from the grammar file.
The ideal thing would be to create a jbossbuild build.xml with all of the thirdarpty dependencies extracted out so that there is a canonnical module equivalent to any other jboss module. The checked in binary would then be the version generated from our build. -
9. Re: Repository Structure
starksm64 Aug 5, 2005 3:27 PM (in response to ruel.loehr)Another issue brought up here, is that for packages such as velocity, which is purely an implementation detail of the installer, the deployment service, etc. I don't see any reason to no unique its package structure under an org.jboss prefix to ensure isolation.
This has been brought up before in the context of the jarjar tool:
http://sourceforge.net/projects/jarjar -
10. Re: Repository Structure
ruel.loehr Aug 5, 2005 3:48 PM (in response to ruel.loehr)
The structure being discussed makes a lot of sense. We can define it, document it, and clean up the repository to meet it's definititions. If we then walked away from it though I am afraid it would end up in the same state as the thirdparty folder.
Scott brought up a good point in another thread about letting the build check the attributes in the component-info.xml files. If somebody doesn't put in license information in one of the files - the build breaks.
In a "perfect world" situation the same would hold true for something like the source or the javadocs. If no source.zip is present, it's a build error (or warning).
Other than the jar files and component info.xml files is it theasible for us to enforce the population of any other aspects of a repository component?