Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.9
    • Component/s: None
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      Maven 2 POMs with dependencies is missing for Spring. It's a lot of extra job for maven 2 users to find out which dependencies Spring needs, and to have to include them manually.

      1. buildsources.sh
        0.6 kB
        Chris Wood
      2. spring-maven.tgz
        11 kB
        Carlos Sanchez

        Issue Links

          Activity

          Hide
          Aleksander Blomskøld added a comment -

          Doh! Just found that the poms I was looking for were at http://www.ibiblio.org/maven2/org/springframework/ and not http://www.ibiblio.org/maven2/springframework/. Anyway, poms for 1.2.6 seems to be missng..

          Show
          Aleksander Blomskøld added a comment - Doh! Just found that the poms I was looking for were at http://www.ibiblio.org/maven2/org/springframework/ and not http://www.ibiblio.org/maven2/springframework/ . Anyway, poms for 1.2.6 seems to be missng..
          Hide
          Andreas Schildbach added a comment -

          This issue is still present for the 2.0 milestones. Those are also missing the sources (and javadocs).

          Show
          Andreas Schildbach added a comment - This issue is still present for the 2.0 milestones. Those are also missing the sources (and javadocs).
          Hide
          Carlos Sanchez added a comment -

          Lastest poms i've working with

          Show
          Carlos Sanchez added a comment - Lastest poms i've working with
          Hide
          Wesslan added a comment -

          Does someone have POM's for 2.0-RC1 (sp I don't have to make them myself yet?

          Show
          Wesslan added a comment - Does someone have POM's for 2.0-RC1 (sp I don't have to make them myself yet?
          Hide
          Andreas Schildbach added a comment -

          And sources, and javadocs?

          Show
          Andreas Schildbach added a comment - And sources, and javadocs?
          Hide
          Wesslan added a comment -

          Sources and JavaDocs are included in the "official" (IE not snapshots) releases but maybe you already knew that.

          Show
          Wesslan added a comment - Sources and JavaDocs are included in the "official" (IE not snapshots) releases but maybe you already knew that.
          Hide
          Andreas Schildbach added a comment -

          I'm afraid this is not true. See for example Spring 1.2.8

          http://www.ibiblio.org/maven2/org/springframework/spring-beans/1.2.8/

          This also only contains the jars.

          Show
          Andreas Schildbach added a comment - I'm afraid this is not true. See for example Spring 1.2.8 http://www.ibiblio.org/maven2/org/springframework/spring-beans/1.2.8/ This also only contains the jars.
          Hide
          Wesslan added a comment -

          You're certainly right Andreas, my mistake.
          On the other hand, should releases in Ibiblio (or some other Maven-repo) contain sources and docs? I should vote no to that.
          If I want sources and/or docs for a project, I'd go to their site and get it.
          Cheers

          Show
          Wesslan added a comment - You're certainly right Andreas, my mistake. On the other hand, should releases in Ibiblio (or some other Maven-repo) contain sources and docs? I should vote no to that. If I want sources and/or docs for a project, I'd go to their site and get it. Cheers
          Hide
          Andreas Schildbach added a comment -

          I vote for yes, at least the sources (JavaDocs are debatable, as they can be generated from the sources on the fly).

          The reason is that you can do "mvn -DdownloadSources=true eclipse:eclipse" in your project, and the sources of all dependencies (and transitive dependencies) are automatically downloaded and attached to the binary jars. This is extremely convenient and can save hours of work.

          Show
          Andreas Schildbach added a comment - I vote for yes, at least the sources (JavaDocs are debatable, as they can be generated from the sources on the fly). The reason is that you can do "mvn -DdownloadSources=true eclipse:eclipse" in your project, and the sources of all dependencies (and transitive dependencies) are automatically downloaded and attached to the binary jars. This is extremely convenient and can save hours of work.
          Hide
          Arik Kfir added a comment -

          Actually they should contain sources+javadocs, as the maven IDE plugins know to fetch them automatically and create the appropriate IDE project files with links to the downloaded sources/javadocs. This is very useful for maven users, as all you need to do is run "mvn idea" and violla! -> you have a working IDEA project file with spring libraries defined, and linked to the spring binaries....

          Show
          Arik Kfir added a comment - Actually they should contain sources+javadocs, as the maven IDE plugins know to fetch them automatically and create the appropriate IDE project files with links to the downloaded sources/javadocs. This is very useful for maven users, as all you need to do is run "mvn idea" and violla! -> you have a working IDEA project file with spring libraries defined, and linked to the spring binaries....
          Hide
          Wesslan added a comment -

          You convinced me guys.

          Show
          Wesslan added a comment - You convinced me guys.
          Hide
          Nicolas Peeters added a comment -

          Does anybody know when this is going to be available on ibiblio (or any other mirror)?

          Thanks!

          Show
          Nicolas Peeters added a comment - Does anybody know when this is going to be available on ibiblio (or any other mirror)? Thanks!
          Hide
          Colin Sampaleanu added a comment -

          I've checked in the last set of POMs from Carlos.

          I've done a bit of tweaking to get spring-beans building including tests, but at this point there are still issues as early as spring-aop, since there is a cyclical dependency between aop and context at the test class level.

          This will probably only be resolved by moving that code to be tested as part of context. That's not incredibly lean now, but would be even less clean when/if the build is actually properly split up with different projects and source trees.

          Colin

          Show
          Colin Sampaleanu added a comment - I've checked in the last set of POMs from Carlos. I've done a bit of tweaking to get spring-beans building including tests, but at this point there are still issues as early as spring-aop, since there is a cyclical dependency between aop and context at the test class level. This will probably only be resolved by moving that code to be tested as part of context. That's not incredibly lean now, but would be even less clean when/if the build is actually properly split up with different projects and source trees. Colin
          Hide
          Carlos Sanchez added a comment -

          I worked around that issues excluding them in the module they are and including them in a higher level one.
          eg. that aop test can be excluded in spring-aop and included in spring-context

          Show
          Carlos Sanchez added a comment - I worked around that issues excluding them in the module they are and including them in a higher level one. eg. that aop test can be excluded in spring-aop and included in spring-context
          Hide
          Colin Sampaleanu added a comment -

          In this case I've talked to Mark F. and he'll just redo that test to not use the context (it can use an XmlBeanFactory). For sure though for some pieces of code it will just be easier to do some tests as part of another module than what they are theoretically in by area of functionality.

          Show
          Colin Sampaleanu added a comment - In this case I've talked to Mark F. and he'll just redo that test to not use the context (it can use an XmlBeanFactory). For sure though for some pieces of code it will just be easier to do some tests as part of another module than what they are theoretically in by area of functionality.
          Hide
          Matthew T. Adams added a comment -

          What's the latest status of this issue? I noticed that as of today, things still aren't quite up to snuff on ibiblio.org – no POMs for 2.0-rc2, 2.0-rc1, or 2.0-m5. I'm assuming the official groupId is org.springframework now – is that not correct?

          Show
          Matthew T. Adams added a comment - What's the latest status of this issue? I noticed that as of today, things still aren't quite up to snuff on ibiblio.org – no POMs for 2.0-rc2, 2.0-rc1, or 2.0-m5. I'm assuming the official groupId is org.springframework now – is that not correct?
          Hide
          Carlos Sanchez added a comment -

          right, official groupId is org.springframework

          Show
          Carlos Sanchez added a comment - right, official groupId is org.springframework
          Hide
          Jacob Robertson added a comment -

          My team is currently on spring 1.2.5, and we would like to migrate to 1.2.8, but if this issue isn't resolved we may just go up to 1.2.7

          P.S has anyone noticed this issue has been spammed by a sex-bot?

          Show
          Jacob Robertson added a comment - My team is currently on spring 1.2.5, and we would like to migrate to 1.2.8, but if this issue isn't resolved we may just go up to 1.2.7 P.S has anyone noticed this issue has been spammed by a sex-bot?
          Hide
          David J. M. Karlsen added a comment -

          Still a problem, even for the 2.x series. Don't think they'll ever fix it - it's been an outstanding issue for quite some time now...

          Show
          David J. M. Karlsen added a comment - Still a problem, even for the 2.x series. Don't think they'll ever fix it - it's been an outstanding issue for quite some time now...
          Hide
          Julien Dubois added a comment -

          Yes David, one can wonder if this will ever be fixed. I've made some pom.xml at the begining of the 2.x series :

          http://jira.codehaus.org/browse/MEV-339

          http://jira.codehaus.org/browse/MEV-358

          http://jira.codehaus.org/browse/MEV-379

          http://jira.codehaus.org/browse/MEV-407

          http://jira.codehaus.org/browse/MEV-408

          I've been (quite frankly) fed up with this. The easiest way to get Spring working with Maven 2 is to use the "org.springframework:spring" dependency :

          <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring</artifactId>
          <version>2.0-rc2</version>
          <scope>compile</scope>
          </dependency>

          This jars includes all the other Spring jars, excepted the "org.springframework:spring-mock" jar.

          You'll get an error telling you the pom.xml is missing, and you (obviously) won't be able to get any transitive dependency. Welcome back to Maven 1

          But it'll work OK!

          Show
          Julien Dubois added a comment - Yes David, one can wonder if this will ever be fixed. I've made some pom.xml at the begining of the 2.x series : http://jira.codehaus.org/browse/MEV-339 http://jira.codehaus.org/browse/MEV-358 http://jira.codehaus.org/browse/MEV-379 http://jira.codehaus.org/browse/MEV-407 http://jira.codehaus.org/browse/MEV-408 I've been (quite frankly) fed up with this. The easiest way to get Spring working with Maven 2 is to use the "org.springframework:spring" dependency : <dependency> <groupId>org.springframework</groupId> <artifactId>spring</artifactId> <version>2.0-rc2</version> <scope>compile</scope> </dependency> This jars includes all the other Spring jars, excepted the "org.springframework:spring-mock" jar. You'll get an error telling you the pom.xml is missing, and you (obviously) won't be able to get any transitive dependency. Welcome back to Maven 1 But it'll work OK!
          Hide
          Oliver Siegmar added a comment -

          Does this prerelease (spring-maven.tgz) work for rc3? I currently have to use the m4 poms from ibiblio and get more and more problems due to bugs in that version (as well as many others out there, I guess). Couldn't someone put this on ibiblio? An imperfect rc3-version is better than those aged m4 poms!

          Show
          Oliver Siegmar added a comment - Does this prerelease (spring-maven.tgz) work for rc3? I currently have to use the m4 poms from ibiblio and get more and more problems due to bugs in that version (as well as many others out there, I guess). Couldn't someone put this on ibiblio? An imperfect rc3-version is better than those aged m4 poms!
          Hide
          Jared Bunting added a comment -

          Is anyone working on poms for 1.2.8? If not, I'm attaching what I managed to put together. I basically used the zip uploaded here for 1.2.7:
          http://jira.codehaus.org/browse/MEV-363
          which is linked to here:
          http://opensource.atlassian.com/projects/spring/browse/SPR-1810

          I changed all spring version references from 1.2.7 to 1.2.8. As far as other dependencies, I couldn't find a list of the changes, but I compared the 1.2.7 and 1.2.8 "with-dependencies" packages and the only difference I found was an upgrade to the quartz library from 1.5.1 to 1.5.2.

          Carlos, can you upload these to the repository (after any required verification of course.) Also, I'm not sure if maven is still using the subversion repository at https://svn.codehaus.org/maven/repository/org/springframework/ for this, but if so, I'm noticing that 1.2.7 doesn't appear to be there, even though they exist on ibiblio.

          Any issues, or questions, etc, let me know.

          Thanks,
          Jared

          Show
          Jared Bunting added a comment - Is anyone working on poms for 1.2.8? If not, I'm attaching what I managed to put together. I basically used the zip uploaded here for 1.2.7: http://jira.codehaus.org/browse/MEV-363 which is linked to here: http://opensource.atlassian.com/projects/spring/browse/SPR-1810 I changed all spring version references from 1.2.7 to 1.2.8. As far as other dependencies, I couldn't find a list of the changes, but I compared the 1.2.7 and 1.2.8 "with-dependencies" packages and the only difference I found was an upgrade to the quartz library from 1.5.1 to 1.5.2. Carlos, can you upload these to the repository (after any required verification of course.) Also, I'm not sure if maven is still using the subversion repository at https://svn.codehaus.org/maven/repository/org/springframework/ for this, but if so, I'm noticing that 1.2.7 doesn't appear to be there, even though they exist on ibiblio. Any issues, or questions, etc, let me know. Thanks, Jared
          Hide
          Jared Bunting added a comment -

          Attaching proposed updated poms for 1.2.8.

          Show
          Jared Bunting added a comment - Attaching proposed updated poms for 1.2.8.
          Hide
          Brian Topping added a comment -

          Is it too early to commit to a "fix version" on this issue? It would be wonderful if it were a part of the 2.0 release! But any expectation would be helpful for planning

          Show
          Brian Topping added a comment - Is it too early to commit to a "fix version" on this issue? It would be wonderful if it were a part of the 2.0 release! But any expectation would be helpful for planning
          Hide
          Matthew T. Adams added a comment -

          I second the sentiment for this to be part of the 2.0 release. It would be even nicer if the latest 1.2.x release process could also include POMs!

          Show
          Matthew T. Adams added a comment - I second the sentiment for this to be part of the 2.0 release. It would be even nicer if the latest 1.2.x release process could also include POMs!
          Hide
          Tim Meighen added a comment -

          Can someone please comment on when this will be done? We are stuck on 2.0-m5 and want to move to 2.0-rc3 to take advantage of bean scopes. If this isn't going to be fixed soon, I'll have to find some sort of workaround (probably manually install in our local repo). Thanks!

          Show
          Tim Meighen added a comment - Can someone please comment on when this will be done? We are stuck on 2.0-m5 and want to move to 2.0-rc3 to take advantage of bean scopes. If this isn't going to be fixed soon, I'll have to find some sort of workaround (probably manually install in our local repo). Thanks!
          Hide
          Jared Bunting added a comment -

          Is there something else that needs to be done to get poms actually uploaded to ibiblio? If there is something else, please let me know, I'll be happy to do it. A quick comment on whether or not these poms will be uploaded, or if there is something I can do to help speed up the process, would be much appreciated.

          Thanks.

          Show
          Jared Bunting added a comment - Is there something else that needs to be done to get poms actually uploaded to ibiblio? If there is something else, please let me know, I'll be happy to do it. A quick comment on whether or not these poms will be uploaded, or if there is something I can do to help speed up the process, would be much appreciated. Thanks.
          Hide
          Carlos Sanchez added a comment -

          The 1.2.8 poms have been uploaded, will be in ibiblio in some hours. Thanks.

          Show
          Carlos Sanchez added a comment - The 1.2.8 poms have been uploaded, will be in ibiblio in some hours. Thanks.
          Hide
          Jared Bunting added a comment -

          Awesome! Thanks Carlos!

          Show
          Jared Bunting added a comment - Awesome! Thanks Carlos!
          Hide
          Andreas Schildbach added a comment -

          What about the sources? 1.2.7 contained sources, 1.2.8 not.

          Show
          Andreas Schildbach added a comment - What about the sources? 1.2.7 contained sources, 1.2.8 not.
          Hide
          Tan Quach added a comment -

          What needs to be done for the 2.0-rc3 poms? Is this the right JIRA issue for commenting on this?

          Show
          Tan Quach added a comment - What needs to be done for the 2.0-rc3 poms? Is this the right JIRA issue for commenting on this?
          Hide
          Matt Raible added a comment -

          I created a bundle for spring-2.0-rc3 and spring-mock-2.0-rc3: http://jira.codehaus.org/browse/MAVENUPLOAD-1108

          Show
          Matt Raible added a comment - I created a bundle for spring-2.0-rc3 and spring-mock-2.0-rc3: http://jira.codehaus.org/browse/MAVENUPLOAD-1108
          Hide
          Brian Topping added a comment -

          This issue has 5x the votes of the next closest open issue, all the "code" for this is checked in and just needs minor updates, and jeez, what else is there? Maybe someone needs to classify this as "will not fix".

          Show
          Brian Topping added a comment - This issue has 5x the votes of the next closest open issue, all the "code" for this is checked in and just needs minor updates, and jeez, what else is there? Maybe someone needs to classify this as "will not fix".
          Hide
          nebhale added a comment -

          We're not marking it as do not fix because we do plan to fix it. It probably won't be as part of 2.0 (I may be corrected on this) but as part of 2.1. We felt that it would be too big a change to overhaul the build system as part of the 2.0 release.

          In regards to the code being checked in, we've tried what's there. At one point we were going to use the POMs in parallel to our build system, but it wasn't just some minor updates to make it work. In the end we decided that it'd be better to spend the time getting the 2.0 release out and then actually converting the system over to Maven completely.

          Hope this answers some of the questions out there.

          Show
          nebhale added a comment - We're not marking it as do not fix because we do plan to fix it. It probably won't be as part of 2.0 (I may be corrected on this) but as part of 2.1. We felt that it would be too big a change to overhaul the build system as part of the 2.0 release. In regards to the code being checked in, we've tried what's there. At one point we were going to use the POMs in parallel to our build system, but it wasn't just some minor updates to make it work. In the end we decided that it'd be better to spend the time getting the 2.0 release out and then actually converting the system over to Maven completely. Hope this answers some of the questions out there.
          Hide
          Colin Sampaleanu added a comment -

          All the code for this is not checked in. What we have right now is a Maven build (in a subdirectory) which produces a (quite) different set of jar files (and related poms) than the main build system via ant.

          Short of doing some radical surgey on the existing source code structure and existing 1800+ line ant build script, it's not like we can use this Maven build right now, we can't put out one set of jars from ant, and a completely different set and POMs, from Maven.

          The Maven build is very important to us. There is a large amount of interest in it, it is needed for the OSGI work as well, but we also need to get Spring 2.0 out, which is already a cupel of months past the original due date. There is no free lunch here, and as for any feature, we need to prioritize...

          Show
          Colin Sampaleanu added a comment - All the code for this is not checked in. What we have right now is a Maven build (in a subdirectory) which produces a (quite) different set of jar files (and related poms) than the main build system via ant. Short of doing some radical surgey on the existing source code structure and existing 1800+ line ant build script, it's not like we can use this Maven build right now, we can't put out one set of jars from ant, and a completely different set and POMs, from Maven. The Maven build is very important to us. There is a large amount of interest in it, it is needed for the OSGI work as well, but we also need to get Spring 2.0 out, which is already a cupel of months past the original due date. There is no free lunch here, and as for any feature, we need to prioritize...
          Hide
          Geoffrey De Smet added a comment -

          Good to hear you're recognize the issue.

          Are there plans to make upload bundles for the 2.0 release that:

          • seperate a pom for each module (the 2.0-RC3 upload currently is only the full blown spring jar)
          • use <optional> where needed
            ?
            That would make our lives a lot easier.
          Show
          Geoffrey De Smet added a comment - Good to hear you're recognize the issue. Are there plans to make upload bundles for the 2.0 release that: seperate a pom for each module (the 2.0-RC3 upload currently is only the full blown spring jar) use <optional> where needed ? That would make our lives a lot easier.
          Hide
          nebhale added a comment -

          Yup, in fact I've got a task to update the POMs a bit this week. I don't think we'll be putting up bundles for 2.0-rc4, but for the final 2.0 release I'll probably create the POMs by hand and upload them. If you've taken a look at the source tree and the build.xml for Spring, you'll notice that it isn't very Maven friendly. The POMs that are in source control, for various reasons, don't quite make the same jars that the build.xml does. So... I'll probably take the 2.0 final jars, hand craft some POMs and that'll be that. After 2.0 (in the 2.1 timeframe) we're aiming to convert the whole spring structure to a maven build and then the problem will simply be solved for everyone.

          I've had these tickets for a while and probably should have posted an update before. I'll try and keep everyone up to date more on this as time goes on.

          Show
          nebhale added a comment - Yup, in fact I've got a task to update the POMs a bit this week. I don't think we'll be putting up bundles for 2.0-rc4, but for the final 2.0 release I'll probably create the POMs by hand and upload them. If you've taken a look at the source tree and the build.xml for Spring, you'll notice that it isn't very Maven friendly. The POMs that are in source control, for various reasons, don't quite make the same jars that the build.xml does. So... I'll probably take the 2.0 final jars, hand craft some POMs and that'll be that. After 2.0 (in the 2.1 timeframe) we're aiming to convert the whole spring structure to a maven build and then the problem will simply be solved for everyone. I've had these tickets for a while and probably should have posted an update before. I'll try and keep everyone up to date more on this as time goes on.
          Hide
          Olle Hallin added a comment -

          You don't have to build with Maven2 in order to make it usable for us Maven2 users!

          Just uploading the proper POMs describing the transitive dependencies would be a tremendous help! The actual jars could be produced with the current build system.

          Of course, if the build system is converted to Maven2, producing the poms is no extra work. Before conversion, it is.

          I would guess that it takes less than an hour to produce minimal poms only containing a <dependency> section.

          Just my 2c...

          Olle

          Show
          Olle Hallin added a comment - You don't have to build with Maven2 in order to make it usable for us Maven2 users! Just uploading the proper POMs describing the transitive dependencies would be a tremendous help! The actual jars could be produced with the current build system. Of course, if the build system is converted to Maven2, producing the poms is no extra work. Before conversion, it is. I would guess that it takes less than an hour to produce minimal poms only containing a <dependency> section. Just my 2c... Olle
          Hide
          nebhale added a comment -

          Not quite less than an hour (there are a bunch of dependencies that require <optional> that I need to setup) but the point is taken.

          Show
          nebhale added a comment - Not quite less than an hour (there are a bunch of dependencies that require <optional> that I need to setup) but the point is taken.
          Hide
          nebhale added a comment -

          For anyone out there still lurking on this issue: Is there any demand for a POM for the full spring jar? Specifically you'd end up with a POM that had all optional dependencies (except commons-logging). This would be in addition to all of the modularized jar POMs.

          Show
          nebhale added a comment - For anyone out there still lurking on this issue: Is there any demand for a POM for the full spring jar? Specifically you'd end up with a POM that had all optional dependencies (except commons-logging). This would be in addition to all of the modularized jar POMs.
          Hide
          Matt Raible added a comment -

          +1 for a POM for the full spring jar. I use this in my applications because it allows a project to grow and use more and more Spring features w/o adding new dependencies.

          Show
          Matt Raible added a comment - +1 for a POM for the full spring jar. I use this in my applications because it allows a project to grow and use more and more Spring features w/o adding new dependencies.
          Hide
          Carlos Sanchez added a comment -

          In the current poms there was somewhere how to define all versions in a pom (spring-parent IIRC) and extent it from spring and other poms to avoid repeating the versions.

          Show
          Carlos Sanchez added a comment - In the current poms there was somewhere how to define all versions in a pom (spring-parent IIRC) and extent it from spring and other poms to avoid repeating the versions.
          Hide
          Geoffrey De Smet added a comment -

          At spring-rich-c.sf.net we depend on the modules and use a
          <properties>
          <spring.version>1.2.8</spring.version>
          </properties>

          <dependency>
          ...
          <artifactId>spring-core</artifactId>
          <version>$

          {spring.version}

          </version>
          </dependency>

          to avoid repeating the overall used spring version.

          Show
          Geoffrey De Smet added a comment - At spring-rich-c.sf.net we depend on the modules and use a <properties> <spring.version>1.2.8</spring.version> </properties> <dependency> ... <artifactId>spring-core</artifactId> <version>$ {spring.version} </version> </dependency> to avoid repeating the overall used spring version.
          Hide
          nebhale added a comment -

          This is actually aimed mostly at Matt, but everyone feel free to chime in. Where my hesitancy is that I'm marking every single dependency in a spring-full (not an official name BTW) POM as optional. So you'd be able to use more Spring features without adding more Spring dependencies, but those features may require they're own dependencies. In addition to that, you'd essentially have to parse the POM file by hand to determine what to include explicitly in your own POM.

          Matt (and everyone else), is that useful still even with those kind of restrictions?

          Show
          nebhale added a comment - This is actually aimed mostly at Matt, but everyone feel free to chime in. Where my hesitancy is that I'm marking every single dependency in a spring-full (not an official name BTW) POM as optional. So you'd be able to use more Spring features without adding more Spring dependencies, but those features may require they're own dependencies. In addition to that, you'd essentially have to parse the POM file by hand to determine what to include explicitly in your own POM. Matt (and everyone else), is that useful still even with those kind of restrictions?
          Hide
          Matt Raible added a comment -

          That's fine with me - you could even remove all the "optional" dependency listings if you like.

          I tend to think of Spring as a library+another library. For example, Spring + Hibernate instead of simply Spring that brings in Hibernate. Since the 2nd dependency often has a different release cycle than Spring, it's nice to explicitly specify it as a dependency (as well as its version).

          Show
          Matt Raible added a comment - That's fine with me - you could even remove all the "optional" dependency listings if you like. I tend to think of Spring as a library+another library. For example, Spring + Hibernate instead of simply Spring that brings in Hibernate. Since the 2nd dependency often has a different release cycle than Spring, it's nice to explicitly specify it as a dependency (as well as its version).
          Hide
          Thomas Van de Velde added a comment -

          I disgree. Optional dependencies should not be removed. For traceability it is good to know versions of the compile dependencies for Spring. Anyways, I don't recommend using spring-full. It's better to use specialized packages such as spring-hibernate. If not, you're loosing all the value of transitive dependencies.

          Show
          Thomas Van de Velde added a comment - I disgree. Optional dependencies should not be removed. For traceability it is good to know versions of the compile dependencies for Spring. Anyways, I don't recommend using spring-full. It's better to use specialized packages such as spring-hibernate. If not, you're loosing all the value of transitive dependencies.
          Hide
          Jared Bunting added a comment -

          I have to agree with Thomas - Optional dependencies should not be removed. However, I see no issue with making MOST of the dependencies in a spring-full jar optional. However, things that spring inherently requires (perhaps commons-lang, commons-collections, i'm not 100% sure of how Spring uses these) should not be optional. But then again, I also agree with Thomas on using specialized packages - I don't see the point of packaging Spring's ORM code with my application if I'm not using it at all - and if I suddenly decide to start using Spring ORM facilities, I want to explicitly declare that I want to use it.

          Show
          Jared Bunting added a comment - I have to agree with Thomas - Optional dependencies should not be removed. However, I see no issue with making MOST of the dependencies in a spring-full jar optional. However, things that spring inherently requires (perhaps commons-lang, commons-collections, i'm not 100% sure of how Spring uses these) should not be optional. But then again, I also agree with Thomas on using specialized packages - I don't see the point of packaging Spring's ORM code with my application if I'm not using it at all - and if I suddenly decide to start using Spring ORM facilities, I want to explicitly declare that I want to use it.
          Hide
          nebhale added a comment -

          Let me clarify a bit. I'm not removing any of the optional dependencies from the full spring POM, but since they're marked as optional, you won't get them transitively. That of course leads to my question about whether the full jar is still useful when there is one required dependency and 50 optional ones. Matt has answered my question and I will be creating a full Spring POM as well.

          That said, I realize that the finer jars are the preferred way to go and they're almost ready for testing. I was just checking on whether anyone wanted the full jar or not.

          Show
          nebhale added a comment - Let me clarify a bit. I'm not removing any of the optional dependencies from the full spring POM, but since they're marked as optional, you won't get them transitively. That of course leads to my question about whether the full jar is still useful when there is one required dependency and 50 optional ones. Matt has answered my question and I will be creating a full Spring POM as well. That said, I realize that the finer jars are the preferred way to go and they're almost ready for testing. I was just checking on whether anyone wanted the full jar or not.
          Hide
          nebhale added a comment -

          I just wanted to let everyone know that I've got a set of test POMs posted up at the Spring private Maven repository. The POMs should not be used for production at this time, but I'd love to have some help testing them. The repository is located at 'https://svn.sourceforge.net/svnroot/springframework/repos/repo-snapshots/' and should have all of the module jars as well as the full spring jar.

          It should be noted that some of Spring's dependencies do not exist in the main maven repo. Some of these will never exist there due to their licensing restrictions, others just haven't been updated to the versions that Spring depends on. I'll include the list at the bottom of this comment, but if you need these dependencies, just go ahead and install them locally via the standard maven mechanisms.

          If the testing goes well, this should pave the way for a rapid release of the POMs in the maven Ibiblio repository shortly after the release of Spring 2.0.

          Dependencies missing from Ibiblio:
          com.ibatis/ibatis2-common/2.2.0.638
          com.oracle/toplink-essentials/2.16
          com.oracle/oc4j/1.0
          hessian/hessian/3.0.20
          java.transaction/jta/1.0.1B (POM only)
          jexcelapi/jxl/2.5.7
          org.hibernate/hibernate-entitymanager/3.2.0.cr2
          tomcat/catalina/5.5.17

          Show
          nebhale added a comment - I just wanted to let everyone know that I've got a set of test POMs posted up at the Spring private Maven repository. The POMs should not be used for production at this time, but I'd love to have some help testing them. The repository is located at 'https://svn.sourceforge.net/svnroot/springframework/repos/repo-snapshots/' and should have all of the module jars as well as the full spring jar. It should be noted that some of Spring's dependencies do not exist in the main maven repo. Some of these will never exist there due to their licensing restrictions, others just haven't been updated to the versions that Spring depends on. I'll include the list at the bottom of this comment, but if you need these dependencies, just go ahead and install them locally via the standard maven mechanisms. If the testing goes well, this should pave the way for a rapid release of the POMs in the maven Ibiblio repository shortly after the release of Spring 2.0. Dependencies missing from Ibiblio: com.ibatis/ibatis2-common/2.2.0.638 com.oracle/toplink-essentials/2.16 com.oracle/oc4j/1.0 hessian/hessian/3.0.20 java.transaction/jta/1.0.1B (POM only) jexcelapi/jxl/2.5.7 org.hibernate/hibernate-entitymanager/3.2.0.cr2 tomcat/catalina/5.5.17
          Hide
          Ismael Juma added a comment -

          I tried the module jars in my project and they worked fine as soon as I added the asm/asm-commons dependency manually. Is this intentional? The module dependencies I set in my pom were: spring-core, spring-context, spring-beans, spring-aop, spring-aspects, spring-dao, spring-jpa, spring-agent, spring-mock.

          Also, regarding com.oracle/toplink-essentials, I wonder what the correct name is. Ibiblio has it with the name javax/persistence/toplink-essentials.bak, while the java.net repository[1] has it with name javax/persistence/toplink-essentials. Both only have version 1.0 though.

          [1] https://maven-repository.dev.java.net/repository/

          Show
          Ismael Juma added a comment - I tried the module jars in my project and they worked fine as soon as I added the asm/asm-commons dependency manually. Is this intentional? The module dependencies I set in my pom were: spring-core, spring-context, spring-beans, spring-aop, spring-aspects, spring-dao, spring-jpa, spring-agent, spring-mock. Also, regarding com.oracle/toplink-essentials, I wonder what the correct name is. Ibiblio has it with the name javax/persistence/toplink-essentials.bak, while the java.net repository [1] has it with name javax/persistence/toplink-essentials. Both only have version 1.0 though. [1] https://maven-repository.dev.java.net/repository/
          Hide
          nebhale added a comment -

          Ismael, the asm jars are listed as optional dependencies for spring-core. Therefore if you're using a configuration that requires them, yes you should have to put them in manually. What I would like confirmation of is whether they're actually optional. My understanding is that asm is optional unless you're using an AspectJ based AOP proxy where you are doing argument binding based on the debug metadata for names of arguments. Is there any chance that you're using this setup causing your dependency on asm?

          Show
          nebhale added a comment - Ismael, the asm jars are listed as optional dependencies for spring-core. Therefore if you're using a configuration that requires them, yes you should have to put them in manually. What I would like confirmation of is whether they're actually optional. My understanding is that asm is optional unless you're using an AspectJ based AOP proxy where you are doing argument binding based on the debug metadata for names of arguments. Is there any chance that you're using this setup causing your dependency on asm?
          Hide
          Ismael Juma added a comment -

          I am not totally sure, so I will describe the situation and hopefully you will be able to arrive at a conclusion. I have something like the following (based on section 6.3.3.3 of the reference manual):

          <aop:config>
          <aop:aspect id="methodSecurityExceptionTranslationAspect"
          ref="methodSecurityExceptionTranslator">
          <aop:after-throwing
          pointcut="execution(* com.mycompany.service..(..))"
          method="translateException" throwing="exception"/>
          </aop:aspect>
          </aop:config>

          <bean id="methodSecurityExceptionTranslator"
          class="com.mycompany.web.security.MethodSecurityExceptionTranslator">
          </bean>

          In the reference manual, it does not mention that debug metadata is required for this to work, but when debugging an exception sometime ago, it did seem that ASM was being used to match the argument name in the throwing attribute. To test whether debug metadata was required, I configured eclipse not to include it and everything still worked as expected.

          Show
          Ismael Juma added a comment - I am not totally sure, so I will describe the situation and hopefully you will be able to arrive at a conclusion. I have something like the following (based on section 6.3.3.3 of the reference manual): <aop:config> <aop:aspect id="methodSecurityExceptionTranslationAspect" ref="methodSecurityExceptionTranslator"> <aop:after-throwing pointcut="execution(* com.mycompany.service. . (..))" method="translateException" throwing="exception"/> </aop:aspect> </aop:config> <bean id="methodSecurityExceptionTranslator" class="com.mycompany.web.security.MethodSecurityExceptionTranslator"> </bean> In the reference manual, it does not mention that debug metadata is required for this to work, but when debugging an exception sometime ago, it did seem that ASM was being used to match the argument name in the throwing attribute. To test whether debug metadata was required, I configured eclipse not to include it and everything still worked as expected.
          Hide
          nebhale added a comment -

          The use of the AspectJ pointcut that binds the exception to the 'exception' argument is where you're getting the need for ASM. It appears that the POM is working as expected for this case. If you run into any other problems, go ahead and leave a comment on this issue.

          Show
          nebhale added a comment - The use of the AspectJ pointcut that binds the exception to the 'exception' argument is where you're getting the need for ASM. It appears that the POM is working as expected for this case. If you run into any other problems, go ahead and leave a comment on this issue.
          Hide
          nebhale added a comment -

          I'm pleased to announce that the 2.0 final POMs have been uploaded to the Spring private repository. They are located at 'https://svn.sourceforge.net/svnroot/springframework/repos/repo/' and I hope to have the main and snapshot repositories syncing with the main ibiblio repository in the next couple of days.

          Show
          nebhale added a comment - I'm pleased to announce that the 2.0 final POMs have been uploaded to the Spring private repository. They are located at 'https://svn.sourceforge.net/svnroot/springframework/repos/repo/' and I hope to have the main and snapshot repositories syncing with the main ibiblio repository in the next couple of days.
          Hide
          Chris Wood added a comment -

          Is there any chance that the javadocs and sources for the component jars could be uploaded as well?

          Generating the sources jar should be pretty straightforward, I'm gonna do this right now by writing a little shell script, I'll attach it in a few mins.

          Show
          Chris Wood added a comment - Is there any chance that the javadocs and sources for the component jars could be uploaded as well? Generating the sources jar should be pretty straightforward, I'm gonna do this right now by writing a little shell script, I'll attach it in a few mins.
          Hide
          nebhale added a comment -

          The source and javadoc jars may not be out for a little while. We need to actually build them out of a couple of trees in the source code and Juergen is going to have to update the build script to do that. If we can get them for 2.0, we'll try but it may be like 2.0.1 before we see the builds generating those files.

          Show
          nebhale added a comment - The source and javadoc jars may not be out for a little while. We need to actually build them out of a couple of trees in the source code and Juergen is going to have to update the build script to do that. If we can get them for 2.0, we'll try but it may be like 2.0.1 before we see the builds generating those files.
          Hide
          Chris Wood added a comment -

          No need to add to your build process, this batch script that I just attached will build and checksum all the requisite sources files for the repository. This is sufficient to get source display out of eclipse + either the eclipse plugin, or the "mvn eclipse:eclipse -DdownloadSources=true" command.

          Just CD to the repository directory, and then run it.

          It works for all the jars, except for spring-aspects which doesn't have matching sources in the spring core jar, you might want to build that one by hand

          Show
          Chris Wood added a comment - No need to add to your build process, this batch script that I just attached will build and checksum all the requisite sources files for the repository. This is sufficient to get source display out of eclipse + either the eclipse plugin, or the "mvn eclipse:eclipse -DdownloadSources=true" command. Just CD to the repository directory, and then run it. It works for all the jars, except for spring-aspects which doesn't have matching sources in the spring core jar, you might want to build that one by hand
          Hide
          Jim Moore added a comment -

          Is there some reason the standard "source" plugin wouldn't work?

          <plugin>
          <artifactId>maven-source-plugin</artifactId>
          <executions>
          <execution>
          <phase>package</phase>
          <goals>
          <goal>jar</goal>
          </goals>
          </execution>
          </executions>
          </plugin>

          That way it's also automaticly added to the list of things to deploy when copying out to the server.

          Show
          Jim Moore added a comment - Is there some reason the standard "source" plugin wouldn't work? <plugin> <artifactId>maven-source-plugin</artifactId> <executions> <execution> <phase>package</phase> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> That way it's also automaticly added to the list of things to deploy when copying out to the server.
          Hide
          Johannes Brodwall added a comment -

          It would be nice to have the POMs be a little less aggressive with their dependencies. Especially:

          Spring-Mock should have optional dependencies on pretty much everything (using it for just AbstractTransactionalSpringContextTests should not require spring-webmvc, which requires struts , which requires the world).

          Spring-Webmvc should not require Struts (?!)

          Spring-Hibernate should use a release version of Hibernate. Or even better: How about a version range?

          Show
          Johannes Brodwall added a comment - It would be nice to have the POMs be a little less aggressive with their dependencies. Especially: Spring-Mock should have optional dependencies on pretty much everything (using it for just AbstractTransactionalSpringContextTests should not require spring-webmvc, which requires struts , which requires the world). Spring-Webmvc should not require Struts (?!) Spring-Hibernate should use a release version of Hibernate. Or even better: How about a version range?
          Hide
          nebhale added a comment -

          The reason that the source plugin isn't going to work for us (right now) is that we don't actually build with Maven. We craft these POMs by hand to ensure such high quality. Wait, that last part wasn't quite right. We do create the POMs by hand, and we don't build with Maven directly. That may or may not change in the future, but as of right now we build with ant.

          Show
          nebhale added a comment - The reason that the source plugin isn't going to work for us (right now) is that we don't actually build with Maven. We craft these POMs by hand to ensure such high quality. Wait, that last part wasn't quite right. We do create the POMs by hand, and we don't build with Maven directly. That may or may not change in the future, but as of right now we build with ant.
          Hide
          nebhale added a comment -

          Johannes, you're dead on about the mock jar. It was my mistake with the Spring dependencies. They should have all been optional (I got all the rest of them correct though). I can't remember the details about why the Struts jar was required, but I think I had a reason. We'll try to get that cleaned up for the next release in a couple of weeks as well as the mocks and that'll remove the struts dependency. It didn't seem like many people tested the 2.0-rc4 POMs while they were up, so keep checking and let me know if there are any more issues that come up. Thanks for the input.

          Show
          nebhale added a comment - Johannes, you're dead on about the mock jar. It was my mistake with the Spring dependencies. They should have all been optional (I got all the rest of them correct though). I can't remember the details about why the Struts jar was required, but I think I had a reason. We'll try to get that cleaned up for the next release in a couple of weeks as well as the mocks and that'll remove the struts dependency. It didn't seem like many people tested the 2.0-rc4 POMs while they were up, so keep checking and let me know if there are any more issues that come up. Thanks for the input.
          Hide
          Matt Raible added a comment -

          Ben - first of all, thanks for taking the time to do this. Secondly, can't the spring-mock.pom be fixed for the 2.0 release? There's nothing set in stone that says the POMs can only be uploaded once. They get modified all the time to remove invalid dependencies and such.

          Thanks,

          Matt

          Show
          Matt Raible added a comment - Ben - first of all, thanks for taking the time to do this. Secondly, can't the spring-mock.pom be fixed for the 2.0 release? There's nothing set in stone that says the POMs can only be uploaded once. They get modified all the time to remove invalid dependencies and such. Thanks, Matt
          Hide
          Colin Sampaleanu added a comment -

          Matt, are you sure? There are lots of broken POMs up there, and stuff like commons-logging 1.1 which has a comment in there saying they know it's broken, but they won't fix it because it might break stuff that depends on it. And I just saw a comment from Carlos saying that stuff only gets put on there once, so it needs to be right the first time...

          Show
          Colin Sampaleanu added a comment - Matt, are you sure? There are lots of broken POMs up there, and stuff like commons-logging 1.1 which has a comment in there saying they know it's broken, but they won't fix it because it might break stuff that depends on it. And I just saw a comment from Carlos saying that stuff only gets put on there once, so it needs to be right the first time...
          Hide
          Michael Pilquist added a comment -

          Another note about aggressive dependencies – Jakarta Commons Logging 1.1 has non-optional dependencies on the Avalon Framework, servlet API, logkit, and log4j. There is a JIRA issue for this problem at http://jira.codehaus.org/browse/MEV-392.

          In lieu of the JCL POM getting fixed, it may be worth adding exclusions for each of these dependencies to the JCL dependency. Otherwise, Spring users are forced to either add the exclusions to each Spring dependency or depend directly on JCL and add the exclusions to it.

          Show
          Michael Pilquist added a comment - Another note about aggressive dependencies – Jakarta Commons Logging 1.1 has non-optional dependencies on the Avalon Framework, servlet API, logkit, and log4j. There is a JIRA issue for this problem at http://jira.codehaus.org/browse/MEV-392 . In lieu of the JCL POM getting fixed, it may be worth adding exclusions for each of these dependencies to the JCL dependency. Otherwise, Spring users are forced to either add the exclusions to each Spring dependency or depend directly on JCL and add the exclusions to it.
          Hide
          Andreas Schildbach added a comment -

          Regarding updating POMs: As far as I know, on a non-snapshot dependency, Maven regularly checks for the POM but will never again download the artifact itself (.jar), unless you delete it from the local repo.

          Ergo: Feel free to update the POM, but get the JAR right on the first time!

          Show
          Andreas Schildbach added a comment - Regarding updating POMs: As far as I know, on a non-snapshot dependency, Maven regularly checks for the POM but will never again download the artifact itself (.jar), unless you delete it from the local repo. Ergo: Feel free to update the POM, but get the JAR right on the first time!
          Hide
          Matt Raible added a comment -

          Colin - I'm certain. I've submitted many bugs against invalid POMs (http://jira.codehaus.org/browse/MEV) and had them fixed. Andreas is correct though - end users will need to "rm -r ~/.m2/repository/org/springframework/spring-mock/2.0/spring-mock-2.0.pom" in order to get the updated POM.

          Show
          Matt Raible added a comment - Colin - I'm certain. I've submitted many bugs against invalid POMs ( http://jira.codehaus.org/browse/MEV ) and had them fixed. Andreas is correct though - end users will need to "rm -r ~/.m2/repository/org/springframework/spring-mock/2.0/spring-mock-2.0.pom" in order to get the updated POM.
          Hide
          Stephen Duncan Jr added a comment -

          Matt: that is no longer the case. Updates to POMs that have made it into the repository are not allowed. See: http://www.nabble.com/Repository-Policy-tf2306302.html

          The current policy is that a new version must be made for a new POM.

          Show
          Stephen Duncan Jr added a comment - Matt: that is no longer the case. Updates to POMs that have made it into the repository are not allowed. See: http://www.nabble.com/Repository-Policy-tf2306302.html The current policy is that a new version must be made for a new POM.
          Hide
          Matt Raible added a comment -

          That sucks they changed the policy. I guess I'll go with the following until the next version:

          <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-mock</artifactId>
          <version>$

          {spring.version}</version>
          <scope>test</scope>
          <exclusions>
          <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-beans</artifactId>
          </exclusion>
          <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-context</artifactId>
          </exclusion>
          <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-core</artifactId>
          </exclusion>
          <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-core</artifactId>
          </exclusion>
          <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-jdbc</artifactId>
          </exclusion>
          <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-jpa</artifactId>
          </exclusion>
          <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-webmvc</artifactId>
          </exclusion>
          </exclusions>
          </dependency>

          Too bad it's not possible to do wildcards:

          <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-mock</artifactId>
          <version>${spring.version}

          </version>
          <scope>test</scope>
          <exclusions>
          <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-*</artifactId>
          </exclusion>
          </exclusions>
          </dependency>

          Show
          Matt Raible added a comment - That sucks they changed the policy. I guess I'll go with the following until the next version: <dependency> <groupId>org.springframework</groupId> <artifactId>spring-mock</artifactId> <version>$ {spring.version}</version> <scope>test</scope> <exclusions> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-jpa</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> </exclusion> </exclusions> </dependency> Too bad it's not possible to do wildcards: <dependency> <groupId>org.springframework</groupId> <artifactId>spring-mock</artifactId> <version>${spring.version} </version> <scope>test</scope> <exclusions> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-*</artifactId> </exclusion> </exclusions> </dependency>
          Hide
          Oliver Siegmar added a comment -

          What about making the commons-logging dependency optional? I prefer using slf4j (simple logging facade for java) and its "commons-logging-bridge".

          Show
          Oliver Siegmar added a comment - What about making the commons-logging dependency optional? I prefer using slf4j (simple logging facade for java) and its "commons-logging-bridge".
          Hide
          Carlos Sanchez added a comment -

          No pom updates. You don't republish a jar changing it, right? you don't know how many people already has it or how many mirrors.

          re: commons-logging vs. slf4j and related issues, Spring guys are providing the poms they "use" which means they use commons-logging and for they it's not optional. If you want to use another implementation, cool, exclude commons-logging and and yours.
          Same for versions of dependencies, if they have tested hibernate x and you want to use hibernate y, just add it to your pom, they are providing you the "official" version they have used to build/test the release.
          Don't expect them to provide all possible combinations of dependencies.

          Show
          Carlos Sanchez added a comment - No pom updates. You don't republish a jar changing it, right? you don't know how many people already has it or how many mirrors. re: commons-logging vs. slf4j and related issues, Spring guys are providing the poms they "use" which means they use commons-logging and for they it's not optional. If you want to use another implementation, cool, exclude commons-logging and and yours. Same for versions of dependencies, if they have tested hibernate x and you want to use hibernate y, just add it to your pom, they are providing you the "official" version they have used to build/test the release. Don't expect them to provide all possible combinations of dependencies.
          Hide
          Sébastien Cesbron added a comment -

          I am using spring-remoting to do remoting but to configure it I need DispatcherServlet. This class is in spring-webmvc but spring-remoting does not depends on spring-webmvc. Althought I don't want to depend on spring-webmvc because it also depends on struts that I don't need and I also don't need mvc framework.
          Would it be possible to add DispatcherServlet inside spring-web instead of spring-webmvc ?

          Show
          Sébastien Cesbron added a comment - I am using spring-remoting to do remoting but to configure it I need DispatcherServlet. This class is in spring-webmvc but spring-remoting does not depends on spring-webmvc. Althought I don't want to depend on spring-webmvc because it also depends on struts that I don't need and I also don't need mvc framework. Would it be possible to add DispatcherServlet inside spring-web instead of spring-webmvc ?
          Hide
          Juergen Hoeller added a comment -

          Note that spring-webmvc does not depend on Struts itself; only spring-struts does. spring-webmvc just happens to include Tiles support, which in turn happens to be shipped as part of Struts. spring-webmvc essentially includes Spring's DispatcherServlet plus supporting classes (like for specific view technologies), just like spring-portlet includes Spring's DispatcherPortlet plus supporting classes. As a consequence, spring-webmvc has a lot of optional dependencies, which you can happily ignore unless you want to use the respective third-party technology.

          Note that Spring's notion of web MVC is much more general than that of other frameworks. Spring builds on a generic dispatching infrastructure there, with HTML pages essentially being a specific use case only: The infrastructure itself is generic enough to handle for example the generation of binary reports as well as the generation of protocol responses. The latter is what happens in case of HTTP-based remoting: It's simply Spring's dispatching infrastructure used to expose HTTP request handlers that happen to process a specific remoting protocol.

          Hence, I would argue that it is perfectly fine if you include spring-webmvc in your application, even if just for handling remoting protocols. Think about it as HTTP request dispatching infrastructure, which you use for processing a specific form of HTTP request. This is an intended use case that comes without any disadvantages, other than having a few further classes on the classpath.

          That said, there is actually an alternative in Spring 2.0: You can use Spring's HttpRequestHandlerServlet; check out its javadoc. Since all of Spring's remoting protocol handlers are HttpRequestHandlers, you can simply define them in your main application context and export them through corresponding HttpRequestHandlerServlet definitions (with the servlet-name matching the target bean name) in your web.xml. This is another way of exposing an HTTP request handler, as alternative to using the DispatcherServlet. HttpRequestHandlerServlet is in spring-web, not in spring-webmvc, so has less dependencies.

          Juergen

          Show
          Juergen Hoeller added a comment - Note that spring-webmvc does not depend on Struts itself; only spring-struts does. spring-webmvc just happens to include Tiles support, which in turn happens to be shipped as part of Struts. spring-webmvc essentially includes Spring's DispatcherServlet plus supporting classes (like for specific view technologies), just like spring-portlet includes Spring's DispatcherPortlet plus supporting classes. As a consequence, spring-webmvc has a lot of optional dependencies, which you can happily ignore unless you want to use the respective third-party technology. Note that Spring's notion of web MVC is much more general than that of other frameworks. Spring builds on a generic dispatching infrastructure there, with HTML pages essentially being a specific use case only: The infrastructure itself is generic enough to handle for example the generation of binary reports as well as the generation of protocol responses. The latter is what happens in case of HTTP-based remoting: It's simply Spring's dispatching infrastructure used to expose HTTP request handlers that happen to process a specific remoting protocol. Hence, I would argue that it is perfectly fine if you include spring-webmvc in your application, even if just for handling remoting protocols. Think about it as HTTP request dispatching infrastructure, which you use for processing a specific form of HTTP request. This is an intended use case that comes without any disadvantages, other than having a few further classes on the classpath. That said, there is actually an alternative in Spring 2.0: You can use Spring's HttpRequestHandlerServlet; check out its javadoc. Since all of Spring's remoting protocol handlers are HttpRequestHandlers, you can simply define them in your main application context and export them through corresponding HttpRequestHandlerServlet definitions (with the servlet-name matching the target bean name) in your web.xml. This is another way of exposing an HTTP request handler, as alternative to using the DispatcherServlet. HttpRequestHandlerServlet is in spring-web, not in spring-webmvc, so has less dependencies. Juergen
          Hide
          Johannes Brodwall added a comment -

          Ben, thanks for the responses and for the good work so far. While waiting for official Spring 2.0 source jars, I built my own. I am not certain that they all are correct (I used jar.exe instead of the source-plugin), but if you'd like them as a stop-gap measure, you can get the full set of source jars from my web site at: http://brodwall.com/johannes/dist/maven-src.zip

          I think the lesson learned from Matt is that it is better to have too many things be optional (in the beginning) than too few. As a maven user, I accept adding more dependencies much better than having to exclude them.

          Show
          Johannes Brodwall added a comment - Ben, thanks for the responses and for the good work so far. While waiting for official Spring 2.0 source jars, I built my own. I am not certain that they all are correct (I used jar.exe instead of the source-plugin), but if you'd like them as a stop-gap measure, you can get the full set of source jars from my web site at: http://brodwall.com/johannes/dist/maven-src.zip I think the lesson learned from Matt is that it is better to have too many things be optional (in the beginning) than too few. As a maven user, I accept adding more dependencies much better than having to exclude them.
          Hide
          Dave Brondsema added a comment -

          The spring-portlet dependency on spring-webmvc should be optional.

          Could "subreleases" (or whatever you want to call them) be made that only modify the pom files? E.g. spring-portlet-2.0-r1.pom

          Show
          Dave Brondsema added a comment - The spring-portlet dependency on spring-webmvc should be optional. Could "subreleases" (or whatever you want to call them) be made that only modify the pom files? E.g. spring-portlet-2.0-r1.pom
          Hide
          nebhale added a comment -

          POMs and jars uploaded for Spring 1.2.9. Please create new issues for any further POM related issues. Take note that at this time there is no plan to create javadoc and source jars for each spring module. That effort will be worked in the 2.0.x branch.

          Show
          nebhale added a comment - POMs and jars uploaded for Spring 1.2.9. Please create new issues for any further POM related issues. Take note that at this time there is no plan to create javadoc and source jars for each spring module. That effort will be worked in the 2.0.x branch.

            People

            • Assignee:
              nebhale
              Reporter:
              Aleksander Blomskøld
              Last updater:
              Trevor Marshall
            • Votes:
              121 Vote for this issue
              Watchers:
              60 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                7 years, 7 weeks, 6 days ago