1 2 3 4 5 Previous Next 73 Replies Latest reply on Aug 14, 2006 6:02 PM by Ruel Loehr Go to original post
      • 30. Re: Breaking up common in jboss-head
        Alexey Loubyansky Master


        "scott.stark@jboss.org" wrote:
        jbossxb: includes the org.apache.* and org.jboss.xb.* packages.

        org.apache can and should be dropped.

        • 31. Re: Breaking up common in jboss-head
          Scott Stark Master

          To do this the org.jboss.xb.binding.parser.xni.XniJBossXBParser needs to be dropped as well. I guess this is obsolete then?

          • 32. Re: Breaking up common in jboss-head
            Alexey Loubyansky Master

            I see you've already removed it. Yes, that's ok. It was critical for one of the xb prototypes. It became obsolete with SchemaBinding.

            • 33. Re: Breaking up common in jboss-head
              Ruel Loehr Novice

              I'll seperate XB into it's own project first. I'm going to create a new cvs module (jbossxb). Then I'll make a build file and move the source over.

              • 34. Re: Breaking up common in jboss-head
                Adrian Brock Master

                Make sure you don't lose all the cvs history.

                • 35. Re: Breaking up common in jboss-head
                  Ruel Loehr Novice

                  Let's sync back up on this. The last plan was here:


                  Regarding the moving of XB into its own project:

                  From dev list:

                  Fine with me. So we need to import the current cvs contents for the common module into an svn repo.

                  I'm missing something here. Why would we put just the common module in SVN? I thought the desire was to split out XB in jboss-head.

                  • 36. Re: Breaking up common in jboss-head
                    Scott Stark Master

                    jbossxb should be a seperate project producing a binary that is included as a binary into jboss-head. Therefore, its existence as a cvs module is not relevant. This is true of all the common module contents. The point of breaking this out was to allow reuse across projects as a binary.

                    • 37. Re: Breaking up common in jboss-head
                      Ruel Loehr Novice

                      Got it. That makes sense, and also makes life easier in general. I'll work with Damon to get this into subversion, get it all setup, and publish a binary.

                      • 38. Re: Breaking up common in jboss-head
                        ryan.campbell Expert

                        The build should be 100% maven. No build.xml

                        • 39. Re: Breaking up common in jboss-head
                          Damon Sicore Novice

                          The import of a single module into a svn repo is possible to do with history; however, if you are planning to import another cvs module into the subversion repo, at a later time, then you have to do something that is called interleaving.

                          Questions we need to answer:

                          Do we want a separate repository instance for each module that is contained in CVS now (i.e., common, clustering, varia, iiop, etc.)? To answer this question you have to determine whether or not you want to keep history of files, as they relate to other files in your repository, and at what time those files related. However, this may not be relevant as I think with our cvs repo, we've been moving histories via hacking the cvs files in the repo when we move between modules. This means that history, for what it's worth, will be maintained on import of that single module. If we import modules piecemeal, we have have to interleave and "change history" for the other modules that already exist in the targe repo. This is directly related to the global revision IDs.

                          If we are worried about how files were related to each other, historically, i.e., what did file X look like in varia, when file Y in commons was at GLOBAL revision n?, then it is better to have multiple top level projects in a single repository. If we don't care about how one file in a top level project relates to another file in another top level project at a specific revision, then we can have separate repos for each project.

                          Remember: Separate repos look like this:


                          By separate repos, I mean, each repo has their own global revision id. One revision id in one repo doesn't directly map to another.

                          The counter to this is all projects in a single repo:


                          Here all projects are in a single repo. This does not preclude, however, the ability of each of those projects to be top level projects--each have their own set of branches, trunk, and labels. We'll get into this more in the Branching Policy as I'm incorporating changes requested from everyone (i.e., branches/tags/trunk under each project rather than at the top level).

                          So, as Adrian said, it's better to do this refactoring in svn as there is no loss of history. This means, import everything at once (a single cutover for all users) and then refactor. This would mean no interleaving of any modules into a single repository (assuming we take the single repository path instead of one repository per module). If a module needs to be in its own repository (i.e., it relates in a non-critical way to other files contained in top level jbossas projects), then it is a simple process to extract it. However, importing with history, piecemeal, is more complicated and will leave people in strange states if they are working on nodes in the repository who magically have their history changed on them--a byproduct of interleaving.


                          • 40. Re: Breaking up common in jboss-head
                            Scott Stark Master

                            The history has to correlate with the jbossas releases it was part of. However, we were not planning on moving all jbossas/jboss-head modules to svn at this pont in time so I don't see how we can have one global svn repo.

                            • 41. Re: Breaking up common in jboss-head
                              Ruel Loehr Novice

                              We can go ahead and do the import of common into it's own repo (for testing purposes). Once it's in there, we can take a look at the history and make sure everything is okay. Damon has requested some additional space from IT for doing this. I'll followup once the source is in place.

                              • 42. Re: Breaking up common in jboss-head
                                Ruel Loehr Novice

                                Scott, I'm looking at the output from when you did your build of common using maven. It shows you compiling the common-core first. You also noted that "
                                I included all the org.jbos.util.* excluding logging in core for now. "

                                Did you just comment out the logging references for classes such as org.jboss.util.Base64?

                                Assuming you did.......

                                When we move xb out into its own project on svn, it will need to have as a dependency, logging. Logging classes need util classes and util classes need logging. We're not currently able to split up logging and util due to the cyclical dependency there. In this case I would build a jar from common, put it in the repo and let xb build against it?

                                • 43. Re: Breaking up common in jboss-head
                                  Scott Stark Master

                                  No, there is no cycle because the common module is broken up into the following:

                                  common-core depends on common-logging-spi
                                  common-logging-jdk depends on common-logging-spi, common-core
                                  common-logging-log4j depends on common-logging-spi, common-core
                                  jbossxb depends on common-logging-spi, common-core

                                  I have sent you the common project breakout that I used.

                                  • 44. Re: Breaking up common in jboss-head
                                    Ruel Loehr Novice

                                    Ok, that clears it up and I was able to break everything up in that fashion. The only piece that I don't see addressed is org.jboss.logging.util.* .

                                    These 6 classes only depend on external dependencies (e.g. log4j). My gut feeling is that these should either be a seperate logging proj or better yet be included in with the rest of the util classes in the common-core.