10 Replies Latest reply on Aug 5, 2005 3:48 PM by ruel.loehr

    Repository Structure

      In this thread we can discuss the structure of the repository.

      The files we need to handle in the repository are:
      1) the artifacts (class jar files)
      2) component-info.xml files
      3) licenses
      4) readme's
      5) resources (idl's, property files, deployers files)
      6) source jars
      7) any others?
      As it stands right now the basic structure is:

      repository.jboss.com/
      repository.jboss.com/licenses/
      repository.jboss.com/component name/
      repository.jboss.com/component name/version
      repository.jboss.com/component name/lib
      repository.jboss.com/component name/resources
      repository.jboss.com/component name/src

      licenses folder- contains all of the licenses in the format name.txt

      Component name folder - contains all of the version folders, nothing else

      Version folder - contains component-info.xml, readme's, does not contain licenses

      lib folder - contains class jar files, nothing else

      resources - contains idl files, properties files, things of that nature

      src - source jars if available

      First off, what are everyones thoughts on the above?




        • 1. Re: Repository Structure

          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

            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

              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.xml

              licenseType="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

                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

                   

                  "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

                    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

                      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

                        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

                          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


                            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?