Spring Framework Maven Artifacts

Posted on November 26th, 2007 by Ben Hale in Builds, Spring.

Ben Hale

By popular demand, the Spring Framework Maven artifacts are now being uploaded to the Spring Snapshot Maven Repository. You can find details about all of the Spring Portfolio Maven repositories in my previous post but I'll reprint the details for the Spring snapshot repository here.

The Spring Snapshot Maven Repository is located at http://s3.amazonaws.com/maven.springframework.org/snapshot. Using this repository requires you to add an entry to the <repositories/> element in your POM. It should look like this:

<repository>
    <id>spring-snapshot</id>
    <name>Spring Portfolio Snapshot Repository</name>
    <url>http://s3.amazonaws.com/maven.springframework.org/snapshot</url>
</repository>

The artifacts in this repository do not follow expected repository behaviors and will be removed regularly. At least the last 10 snapshot builds for a given artifact will be retained. If an artifact is removed from a distribution its snapshot builds will be removed immediately. On the release of a milestone or a final release, all snapshots for an artifact will be removed and a new snapshot for the next release created.

Similar Posts

Share this Post
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • DZone
  • LinkedIn
  • Slashdot
  • Technorati
  • TwitThis
 

7 responses

  1. Martin Bengl says:

    Added on November 26th, 2007 at 4:41 am

    Hi Alex,

    could you please update the spring-2.5-sources.jar at http://repo1.maven.org/maven2/org/springframework/spring/2.5/.
    It currently contains just the source for spring aop.

    Thanks!

    Martin

  2. Ben Hale (blog author) says:

    Added on November 26th, 2007 at 8:12 am

    Once an artifact is uploaded to repo1, it can never be changed. The more granular artifacts are fine, so you could use those until the 2.5.1 release which is coming shortly. As well, you can just use the current snapshots that this post talks about.

  3. Martin Bengl says:

    Added on November 26th, 2007 at 10:35 am

    "somebody" found a way to change the spring-2.5-sources.jar at repo1. :-) Thanks for that!

  4. Blair says:

    Added on November 26th, 2007 at 3:44 pm

    I've noticed spring richclient isn't there, will it be put there?

    What (if anything) is happening with that project?

  5. Matt T says:

    Added on February 4th, 2008 at 6:01 am

    I was just wondering how you found your transition from your previous build system to using Maven. I have seens lots of discussion about use of ANT Ivy instead of Maven, and was wondering what your position was? I am currently implementing the building of all my companies products in Maven, but was challenged by a colleague as to why I am not using the ANT Ivy combination instead. I didn't really have an answer, which is partly the reason for me posting here. The articles I have read however were over a year old, so, my personal opinion is that Maven has come on a lot over that time. It has transitive dependencies now, which it did not have in earlier incarnations… etc, etc.

    Any thoughts would be greatly appreciated.

  6. Ben Hale (blog author) says:

    Added on February 4th, 2008 at 6:17 am

    Actually haven't moved our build systems over, we only create Maven artifacts. There are a couple of projects in the Spring Portfolio that use Maven, but not all of them do. Going forward the new portfolio projects are using a build system that is based on ANT and Ivy. Maven certainly has come on a bit, but there are still enough issues with it, that we feel a unified build system based on ANT and Ivy is more useful to us. However, each situation is different and I encourage you to evaluate based on your own projects.

  7. Jean Louis Boudart says:

    Added on February 3rd, 2009 at 11:38 am

    Hi,

    I'm currently working on a new open source build system named EasyAnt.
    Easyant is a toolbox focusing on easing project build processes.
    It's based on Apache Ant and Apache Ivy, and allows for maximum flexibily, improved integration in existing build systems and provides conventions and guidelines.

    Our goals are :

    * to simplify build process by providing a set of ready to use build scripts (or modules) to ease the implementation of build system.
    * to provide conventions and guidelines
    * to leverage your ant knowledge (no need to learn another language)
    * to remain adaptable :
    o what about conventions ? : Even if Easyant comes with a lot of conventions, we never lock you in.
    o what about modules ? : You can easily adapt it to your projects. The architecture of Easyant allows you to easily extends existing modules and to provide your own one.
    o what if you already have an existing project ? Since Easyant is fully based on top of ant, you can keep your existing project along with the "old school" ant scripts. This should ease the migration to Easyant.

    Any feedback would be really appreciated, i'm sure you can give us good idea of what a good and flexible build system must implement.

    Cheers,
    Jean Louis Boudart

Leave a Reply