|
[
Permlink
| « Hide
]
Aleksander Blomskøld added a comment - 20/Nov/05 02:50 PM
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..
This issue is still present for the 2.0 milestones. Those are also missing the sources (and javadocs).
Lastest poms i've working with
And sources, and javadocs?
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. 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 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. 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....
Does anybody know when this is going to be available on ibiblio (or any other mirror)?
Thanks! 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 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 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.
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?
right, official groupId is org.springframework
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? 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... :-(
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! 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!
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 Attaching proposed updated poms for 1.2.8.
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 :-)
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!
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!
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. The 1.2.8 poms have been uploaded, will be in ibiblio in some hours. Thanks.
What about the sources? 1.2.7 contained sources, 1.2.8 not.
I created a bundle for spring-2.0-rc3 and spring-mock-2.0-rc3: http://jira.codehaus.org/browse/MAVENUPLOAD-1108
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".
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. 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... 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. 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. 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 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.
+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.
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.
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. 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? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Resolved
Minor
Maven 2 support (POMs)
