Announcement Announcement Module
Collapse

JavaConfig forum decommissioned in favor of Core Container

As described at

http://static.springsource.org/sprin...fig/README.TXT

key features of the Spring JavaConfig project have been migrated into the core Spring Framework as of version 3.0.

Please see the Spring 3.0 documentation on @Configuration and @Bean support:

http://static.springsource.org/sprin...tml#beans-java

For any questions related to @Configuration classes and @Bean methods in Spring 3.0, please post in the dedicated 'Core Container' forum at

http://forum.springsource.org/forumdisplay.php?f=26
See more
See less
Access to m4 snapshot via maven? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Access to m4 snapshot via maven?

    Hi,

    is there a way to access the m4 snapshot via maven? I've tried various combinations such as 1.0.0.m4-SNAPSHOT, 1.0.0-SNAPSHOT, 1.0-SNAPSHOT and the like in my pom.xml with no success. 1.0.0.m3 works fine (as far as maven's concerned in any case).

    I have added the Spring S3 maven repository to the list.

    Thanks,

    M.

  • #2
    Hi M.,

    This is documented http://springframework.org/javaconfig, specifically http://springframework.org/node/740.

    The snapshot version is actually labeled 1.0.0.BUILD-SNAPSHOT. That will probably resolve your issue.

    Comment


    • #3
      Hi,

      thank you for your reply. I don't know how I managed to miss that given that I was looking at that very page to configure m3.

      Thanks again.

      Comment


      • #4
        Chris, this used to work for m3 but with m4 the artifactIds have changed and now projects that refer to the non-namespaced spring dependencies break all over the place. Apparently this is because the pom is autogenerated by ivy and uses the OSGi bundle names as artifactIds, not the logical name. Is this a bug in the pom generation or intentional? This split between namespaced and non-namespaced artifacts makes them effectively useless for maven.

        Thanks for any insights.
        -h

        Comment


        • #5
          Holger,

          Just so we're on the same page, are you using the very latest instructions for Maven, per the M4 documentation?

          http://static.springframework.org/sp...ne-build-maven

          If so, and you're still experiencing the problem, please spell out your scenario in a bit more depth and I'll look into it. Ideally, if you can provide a simple Maven project that demonstrates the problem, I'll be able to address it very quickly. Feel free to create a new JIRA issue and attach such a project.

          Comment


          • #6
            Thanks for the reply -

            Originally posted by Chris Beams View Post
            Holger,
            Just so we're on the same page, are you using the very latest instructions for Maven, per the M4 documentation?
            Yes, precisely. Tried to update from m3 to m4, had to add the new repositories etc. to my pom and then noticed that it also tried to get the namespaced dependencies of spring-beans/core/etc. even though I already had them defined in the pom, but by the traditional artifactId.

            You can simply look at the deployed M4 pom and see in its dependencies that it refers to e.g. org.springframework.beans, not spring-beans. Essentially this creates a new hierarchy and leads to all sorts of inconsistencies with transitive dependencies, since maven matches by groupId/artifactId.

            If all Spring dependencies are now supposed to be in the namespaced form (to accommodate the SS OSGi repo), then it might be best not to publish the non-namespaced version at all or only redirections (sort of like http redirect but for pom artifacts). This would need to be done across the entire Spring ecosystem, not just javaconfig - and it would affect every other project that uses Spring, including customers. For obvious reasons the existing groupId/artifactId names would cause the least chaos.

            I hope that explained the problem better.

            thanks!
            Holger

            Comment


            • #7
              I can confirm that this issue does indeed exist. Basically, all the spring jars (those that are also used by javaconfig) are duplicated, appearing once as i.e. spring-core-2.5.6 and a second time as org.springframework.core-2.5.6.

              The problem occurs if you declare spring as a dependency in pom using the traditional group id of org.springframework and articact id of spring-core, and then also include javaconfig (either M4 or BUILD_SNAPSHOT) as described in the documentation, which then as its own dependency pulls in the org.springframework.core-2.5.6 etc. stuff, essentially duplicating them.

              Comment


              • #8
                Wherever possible, the best plan is to always fetch dependencies out of the SpringSource repository. artifactIds, etc are always internally consistent within. I realize this can be a bit of a pain at first. I've directed our build team to take a look at this thread and add any additional comments.

                Can this issue be solved for both of you by updating your poms to retrieve everything from our repository? If so, is that an acceptable solution? If not, please detail why (either way it's useful feedback for us).

                Thanks,

                - C

                Comment


                • #9
                  I guess reconfiguring my poms to use the Spring Enterprise Repositories and their naming scheme did work for me, though it took me several hours to figure out what I should use as the new artifact and group ids (it doesn't seem the mapping from the old to the new naming system is one-to-one in all cases, or even consistent. For example, what used to be spring-webmvc is now split up into org.springframework.web and org.springframework.web.servlet at the least).

                  I suspect this is exactly what some people might be trying to avoid and why this duplication thing might be a problem for them.

                  Other than that, looks like javaconfig m4 is working great. I just dropped my last bootstrap xml config file in favor of the @AnnotationDrivenConfig and @ComponentScan annotations. Great work guys!

                  Comment


                  • #10
                    Glad to hear you're liking what you see in M4.

                    Regarding the time it took to figure out the artifactIds - were you using http://springsource.com/repository to search for them?

                    Comment


                    • #11
                      Originally posted by Chris Beams View Post
                      Regarding the time it took to figure out the artifactIds - were you using ...
                      I did eventually find that site, but as I said, it's not entirely obvious how to map the old names to the new ones in all cases even with the repository open in front of you. I figured it out eventually, so no problem there.

                      Still, I suspect some users might not be able to do so as easily due to certain restrictions. In the worst case scenario they may not even notice for some time that javaconfig pulled in the duplicates - my application worked just fine with the duplicated jars being deployed onto the web server, I only noticed it after looking at the maven dependency graph.

                      Comment


                      • #12
                        Transient dependencies in JavaConfig M4 maven release

                        Bear with me if I'm misunderstanding something here, but it appears that the artifact IDs of dependencies in javaconfig's pom.xml isn't following the common practice. For example, the AOP dependency is expressed as follows:

                        Code:
                            <dependency>
                              <groupId>org.springframework</groupId>
                              <artifactId>org.springframework.aop</artifactId>
                              <version>2.5.6</version>
                              <optional>true</optional>
                            </dependency>
                        The dependency syntax used other places (for example spring-ws) is the following:
                        Code:
                           <dependency>
                              <groupId>org.springframework</groupId>
                              <artifactId>spring-aop</artifactId>
                           </dependency>
                        The consequence of these different practices is that all transient dependencies shared between javaconfig and other libraries are duplicated on the classpath by maven.

                        Comment


                        • #13
                          Hi jlillesand,

                          You're quite right to point out what you're seeing. It's an unfortunate growing pain as we move each of the Spring portfolio projects from Maven Central to the SpringSource Enterprise Bundle Repository - some have updated and some have not. I've spoken with Arjen (author of spring-ws) about this, and he says he'll update the POM accordingly in the 1.5.6 timeline.

                          I've also created an issue to track this - you may want to add yourself as a watcher and/or vote for it: http://jira.springframework.org/browse/SWS-451

                          In the meantime, as you've probably figured out, everything should still work for you, you'll just be stuck with an irritating duplicate dependency (or a few) on the classpath. All Spring projects going forward will be using the artifactId nomenclature that JavaConfig M4 is currently using, so this problem will go away over time.

                          Thanks,

                          - Chris

                          Comment


                          • #14
                            Thanks for your response, Chris. As you correctly point out, everything works fine. I've both voted and added myself as a watcher, and hopefully we'll see this rectified in the future. Thanks for your help and your efforts with JC.

                            Comment


                            • #15
                              Originally posted by Chris Beams View Post
                              You're quite right to point out what you're seeing. It's an unfortunate growing pain as we move each of the Spring portfolio projects from Maven Central to the SpringSource Enterprise Bundle Repository - some have updated and some have not. I've spoken with Arjen (author of spring-ws) about this, and he says he'll update the POM accordingly in the 1.5.6 timeline.
                              Stupid question here. Does that mean all artifacts going forward (in the maven2 central repos etc.) will be using this syntax:
                              Code:
                                      <dependency>
                                          <groupId>org.springframework</groupId>
                                          <artifactId>org.springframework.context.support</artifactId>
                                      </dependency>
                              or this syntax?
                              Code:
                                      <dependency>
                                          <groupId>org.springframework</groupId>
                                          <artifactId>context-support</artifactId>
                                      </dependency>
                              Or are we talking about using seperate artifactIds in the different repos?

                              Also, just to be slightly argumentative this format seems to break from the one used by pretty much everyone else (as shown on the maven2 site). Is there a reason for this change? (just point me to a faq or whatever if I am being dense)
                              Code:
                              <project>
                                <groupId>com.mycompany.app</groupId>
                                <artifactId>my-module</artifactId>
                                <version>1</version>
                              </project>
                              Thanks :-)

                              Comment

                              Working...
                              X