11 Replies Latest reply on Feb 10, 2010 5:08 PM by jnorris10

    Repositories baked into the POMs

    alrubinger

      The Arquillian Build Parent POM has repository configurations in place; the problem this presents is that one we cut/tag releases, the external repositories must remain in their noted locations forever.  If any of them move without proper proxying, we won't be able to build them anymore.

       

      Sonatype guys typically recommend that this build configuration is a part of ~/.m2/settings.xml (or some other custom settings.xml which you can specify at the command-line with "-s").

       

      How do you guys feel about moving these out and updating the Arquillian build instructions to reference the requisite repos?  Note this is what we do in ShrinkWrap | Development and Contribution.

       

      S,

      ALR

        • 1. Re: Repositories baked into the POMs
          jaikiran

          ALRubinger wrote:

           

          The Arquillian Build Parent POM has repository configurations in place; the problem this presents is that one we cut/tag releases, the external repositories must remain in their noted locations forever.  If any of them move without proper proxying, we won't be able to build them anymore.

           

          I am not sure if that would be the case. My understanding is that the repositories specified in the pom.xml just forms part of the entire set of repositories (which is a combination of pom.xml repos + settings.xml repos). So if the repos specified in the pom.xml are moved to some other location without proper proxying, users can still build them by adding the new set of repos in their settings.xml.

           

          The advantage that i have seen with repos specified in pom.xml, is for new developers/contributors who just want to download the project from svn and do  a mvn clean install. Having the repos in pom.xml makes it easier for such contributors to quickly submit a patch instead of having to setup the repos separately in their local settings.xml.

          • 2. Re: Repositories baked into the POMs
            alrubinger

            Nice point.  User settings are additive to the stuff in the POM.

             

            Though I'm sure I've heard it's a best practice not to but this stuff in there.  Let me double-check the reasons and if we're covered, let's leave as-is.  And then I'll probably even put required repos into ShrinkWrap too.

             

            S,

            ALR

            • 3. Re: Repositories baked into the POMs
              jnorris10

              I asked a question on stackoverflow and got some interesting responses.  Overall, it looks like in the POM is best in this case (with some caveats).

              • 4. Re: Repositories baked into the POMs
                alrubinger

                StackOverflow, cool.  Ah yes - this was the article I'd read awhile ago:

                 

                http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/

                 

                We're actually moving to a repository manager sooner than later; in fact I've been testing it these past couple weeks in preparation for its launch.  Under this arrangement we'll have one repo proxy everything for us.

                 

                So I think looking forward, we should:

                 

                • Bake the repository manager into our POMs
                • Use it as the single point of control for all other repos

                 

                WDTY?

                 

                S,

                ALR

                • 5. Re: Repositories baked into the POMs
                  aslak

                  Who are 'we' ? I presume JBoss.. Will it be a openly controlled Repository Manager or do you need help from internal people to add stuff to it?

                  • 6. Re: Repositories baked into the POMs
                    dan.j.allen

                    Like coding conventions, it's just a matter of time before a project team gets to the discussion of Maven repository dependencies Here we are.

                     

                    When I cut my lip on Maven, I used to adhere very strictly to putting all repositories in the ~/.m2/settings.xml file and keeping them out of the project. Even when my former company moved to a repository manager (Artifactory), we still kept that single proxy repository in the ~/.m2/settings.xml. That was "the Maven way".

                     

                    When we brought on new developers, we would have to sit with them to setup ~/.m2/settings.xml (actually, I gave them a script, but that's the same as sitting) before they could build. That would be the experience we would be dumping on our participating community (early adopters, contributors, curious folks). I'll return to that thought.

                     

                    There is a huge hole in the ~/.m2/settings.xml dogma, however. If the user is building another Maven project on the machine that uses a different set of repositories, they've created a local repository which is now totally unique. It's like having a frame in a house that is out of square. Nothing in the rest of the house will be true.

                     

                    Some projects have gotten around this by enforcing the rule that they will only depend on Maven central, so the repository is not specified in pom.xml, but it also isn't specified in ~/.m2/settings.xml. Everyone has the central artifacts.

                     

                    Since it's a completely false guarantee to use ~/.m2/settings.xml (because Maven is basically broken...I'll explain it to you over a beer), I think we should depend on Maven Central only. If we have to depend on jboss.org in the short run, that's okay, as long as our long term goal is to depend on Maven Central. This is the path we have followed in Weld.

                     

                    We should immediately move forward with creating Sonatype OSS hosting accounts for ShrinkWrap and Arquillian so that we can release the projects' artifacts to the Maven central repository as described in this guide. We do this for Weld, so we have in house knowledge (in fact, I have done it).

                    • 7. Re: Repositories baked into the POMs
                      jaikiran

                      I like the idea of releasing the projects to Maven central. Especially for projects like Shrinkwrap and Arquillian, which do not have any jboss specific dependencies.

                      • 8. Re: Repositories baked into the POMs
                        aslak
                        Arquillian has dependencies all over the place. JBoss, Glassfish, Weld, (OpenEJB, Jetty). In time these might be moved over to the respective project, but for now.. Same is true for ShrinkWrap with its new GlassFish/OpenEJB extensions.
                        • 9. Re: Repositories baked into the POMs
                          dan.j.allen

                          aslak wrote:

                           

                          Arquillian has dependencies all over the place. JBoss, Glassfish, Weld, (OpenEJB, Jetty). In time these might be moved over to the respective project, but for now.. Same is true for ShrinkWrap with its new GlassFish/OpenEJB extensions.

                           

                          Yes, this goal cannot be realized overnight. Understand that the Sonatype OSS hosting is relatively new and it's going to take some time for projects to publish to Maven Central correctly (if for the first time). Sun (now the division of Oracle) has been a particular PITA about not publishing to Maven Central and we are on them about that. That GlassFish repository irks the hell out of me.

                           

                          In the near term, we are going to have to depend on non-central repositories. I would like to be able to put that behind the jboss.org repository manager URL and just limit it to one. That repository manager should give access to project admins to control its contents. I'm not sure about the exact policy, I'm just speculating...it happens to be the same software that Sonatype uses for the OSS hosting...correct ALR?

                           

                          Regardless of what the short term looks like, the long term must be to depend on Maven Central. If that just isn't possible, then we depend on "our" central, which is the JBoss.org repository.

                          • 10. Re: Repositories baked into the POMs
                            alrubinger

                            dan.j.allen wrote:

                            In the near term, we are going to have to depend on non-central repositories. I would like to be able to put that behind the jboss.org repository manager URL and just limit it to one. That repository manager should give access to project admins to control its contents. I'm not sure about the exact policy, I'm just speculating...it happens to be the same software that Sonatype uses for the OSS hosting...correct ALR?

                             

                            Yep.  In essense the JBoss.org repo relationship to Central becomes analagous to RPMForge::Fedora Updates.  And yeah, Sonatype's repo manager; there's a login and fine-grained permissions, though I'm not yet familiar with any policy controls.

                             

                            S,

                            ALR

                            • 11. Re: Repositories baked into the POMs
                              jnorris10

                              dan.j.allen wrote:

                               

                               

                              There is a huge hole in the ~/.m2/settings.xml dogma, however. If the user is building another Maven project on the machine that uses a different set of repositories, they've created a local repository which is now totally unique. It's like having a frame in a house that is out of square. Nothing in the rest of the house will be true.

                               

                              I'm not a big fan of ~/.m2/settings.xml either, however I would hope this is a theoretical problem and not one in practice .  Even though people can create custom repositories, the groupId/artifactId/version should be treated as a global namespace regardless of where their artifacts end up.  Therefore, this will only be a problem if someone pushes up the same artifact (groupId/artifactId/version) that has different contents than the artifact on central (ie: a truly evil scenario ).