Re: [xwiki-devs] [xwiki-notifications] r9369 - xwiki-platform/core/trunk/xwiki-core
thanks for the cleanup, see below On Apr 25, 2008, at 5:22 AM, sdumitriu (SVN) wrote:
Author: sdumitriu Date: 2008-04-25 05:22:47 +0200 (Fri, 25 Apr 2008) New Revision: 9369
Modified: xwiki-platform/core/trunk/xwiki-core/pom.xml Log: XWIKI-2337: Move common dependencies versions to the parent pom dependencyManagement section XWIKI-2338: Upgrade some commons packages Upgrade the core pom
[snip]
<!-- VMA: I'm not sure if we have the right to distribute this jar. It's not on the central repository because of licensing issues. --> + <!-- Sergiu: No, we cannot redistribute it. And we definitely shouldn't put it in our repo. + We can redistribute version 1.1, but we should make users approve their License Agreement. + Can we drop this completely? Why is it needed? -->
it's needed for sending mail. Sun was supposed to provide new redistributable licenses with new releases of their jars. We need to check if it's been done.
+ <!-- TODO: Version 1.1 is available, should we upgrade? -->
that means upgrading mail. Yes we should especially if the license is good now.
<dependency> <groupId>javax.transaction</groupId> <artifactId>jta</artifactId> @@ -136,6 +141,7 @@ <!-- There's only a 2.2.9.1 version of jgroups on the central repository (http://repo1.maven.org/maven2/jgroups/jgroups-all/). Upload a newer version (http://sourceforge.net/project/showfiles.php?group_id=6081&package_id=94868 ). --> + <!-- TODO: 2.4.1 is there now, although 2.6.2 is released on Sourceforge; should we upgrade? -->
This is used by oscache for clustering I think. I'd not upgrade unless you have verified that clustering works fine before, then upgrade then test again. [snip]
+ + <!-- Things that should probably be removed --> + <dependency> + <groupId>org.apache.velocity</groupId> + <artifactId>velocity-tools</artifactId> + <version>1.3</version> + </dependency>
why do you say that? We're using it.
+ <dependency> + <groupId>joda-time</groupId> + <artifactId>joda-time</artifactId> + <version>1.4</version> + </dependency> + <dependency> + <groupId>backport-util-concurrent</groupId> + <artifactId>backport-util-concurrent</artifactId> + <version>3.0</version> + </dependency> </dependencies> <build> <plugins>
Thanks -Vincent
Vincent Massol wrote:
+ + <!-- Things that should probably be removed --> + <dependency> + <groupId>org.apache.velocity</groupId> + <artifactId>velocity-tools</artifactId> + <version>1.3</version> + </dependency>
why do you say that? We're using it.
Then shouldn't it be a dependency for the velocity component? -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Apr 25, 2008, at 11:11 AM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
+ + <!-- Things that should probably be removed --> + <dependency> + <groupId>org.apache.velocity</groupId> + <artifactId>velocity-tools</artifactId> + <version>1.3</version> + </dependency>
why do you say that? We're using it.
Then shouldn't it be a dependency for the velocity component?
there may still be some dep on it in the core I think... not sure, needs to be checked. BTW the build is fully broken. -Vincent
Vincent Massol wrote:
BTW the build is fully broken.
What exactly is broken? I tried to do a build before committing, and it worked. Also, the CI machine doesn't fail (except the already broken distribution tests). -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Apr 25, 2008, at 11:48 AM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
BTW the build is fully broken.
What exactly is broken? I tried to do a build before committing, and it worked. Also, the CI machine doesn't fail (except the already broken distribution tests).
Fore e ex: http://continuum.xwiki.org/continuum/buildResult.action? buildId=14412&projectId=82&projectGroupId=6 It's logical that it fails IMO since xwiki-xmldoc-update needs a compile scope for the servlet api and since you're forced it to provided at the top level all those who need it at compile time will need to specifically mention <scope>compile I think. -Vincent
On Fri, Apr 25, 2008 at 11:48 AM, Sergiu Dumitriu <[email protected]> wrote:
Vincent Massol wrote:
BTW the build is fully broken.
What exactly is broken? I tried to do a build before committing, and it worked. Also, the CI machine doesn't fail (except the already broken distribution tests).
About all the SQLExceptions [1] : it seems that downgrading commons-dbcp to 1.2.1 and commons-pool 1.2 solves the problem. Anyone seeing what might be the problem in : http://commons.apache.org/dbcp/changes-report.html#1.2.2 http://commons.apache.org/pool/release-notes-1.3.html [1] : java.sql.SQLException: Statement is closed -- Jean-Vincent Drean
participants (3)
-
Jean-Vincent Drean -
Sergiu Dumitriu -
Vincent Massol