Re: Unit tests seeing test application context files in their dependencies
> Looking at your terminologies and file snippets: Are you using Spring > in your projects? > Yes > If (I assume so) Spring is involved, this should work, at least I do > have libraries (jar artifacts) wired up with web applications (war > artifacts) right this way. Where is your DependencyTestContext.xml > located? Are you sure this is a maven2 related problem? > I'm not sure if this is a maven2 problem. The test application context in the dependency is located in the /src/test/resources folder in its project (in the project I'm writing the tests for, my app context is in /src/test/resources also). The actual error I'm getting when I use the line is: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath:DependencyTestContext.xml] -- View this message in context: http://www.nabble.com/Unit-tests-seeing-test-application-context-files-in-their-dependencies-tp17881883p17882205.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unit tests seeing test application context files in their dependencies
Hi, I am wondering if it's possible to do the following: My application context uses some beans from a different application context which is located in one of its dependencies. I am now writing unit tests for this project and the dependency as well. So I have my test application context in both these projects, and I would like the one from the dependency to be visible in the other one. Is that possible in any way? I tried this line: but it didn't work - that app context was not visible. Thanks, Papapara Tudu -- View this message in context: http://www.nabble.com/Unit-tests-seeing-test-application-context-files-in-their-dependencies-tp17881883p17881883.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with snapshots
I have identified some more things in my confiaguration, maybe someone will have any other ideas as to what could be wrong? 1. When I deploy my snapshot onto my local repository with this command: mvn install:install-file -Dfile=Project.jar -DgroupId=com.company.project -DartifactId=project -Dversion=2.2-SNAPSHOT -Dpackaging=jar -DgeneratePom=true what happens is that the project-2.2-SNAPSHOT.jar gets overwritten with the new file and then as before, this file is used for the compiled war. 2. I also run automated builds on the same machine where I have the archiva repository. What is strange there is that it always picks up the most recent version of the snapshot for the compiled version. So for some reason my problem only occurs on local builds, and not on the continuous integration build on my build machine. Could that be because there's a difference in the metadata xmls between my internal repo and the local repo? This is my maven-metadata-local.xml file from the com/company/project/project folder: com.company.project project 2.2-SNAPSHOT 2.2-SNAPSHOT 20080312101739 And this is the one from my Archiva repo: com.company.project project 2.2-SNAPSHOT 2.2-SNAPSHOT Now these are the respective files from the com/company/project/project/2.2-SNAPSHOT folder: 1. local repository: com.company.project project 2.2-SNAPSHOT true 20080312101739 2. archiva: com.company.project project 2.2-SNAPSHOT 19 20080311.132319 20080311132319 -- View this message in context: http://www.nabble.com/Problem-with-snapshots-tp15709789s177p16001438.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiping out a dependency from an internal repository
[EMAIL PROTECTED] wrote: > > Do you mean deleting stuff from the ~/.m2/repository directorty on the > same computer you are running maven from? > ... > Maybe you should think carefully about whether you really need to do any > of this though.. > Actually all of this is related to my problem with picking up the correct snapshot which I described in this thread: http://www.nabble.com/Problem-with-snapshots-td15709789s177.html As I still haven't resolved that problem, what I'm going to do is delete the whole snapshot dependency from my local repository (first I thought of deleting it from the internal repository, but now I've noticed it's enogh just to delete it from the local one) at the beginning of the build and then the newest version of the snapshot will be downloaded from the internal repository. It's a brutal workaround, but since I cannot get the common approach to work, I need to restort to this. Cheers, Papapara Tudu -- View this message in context: http://www.nabble.com/Wiping-out-a-dependency-from-an-internal-repository-tp15873175s177p15891117.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wiping out a dependency from an internal repository
Hello, I would like to delete the whole folder that contains a certain dependency from my internal repository by running a Maven command from a dev machine. Is it possible to do that? Thanks, Papapara Tudu -- View this message in context: http://www.nabble.com/Wiping-out-a-dependency-from-an-internal-repository-tp15873175s177p15873175.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with snapshots
amit kumar-18 wrote: > > You mean even from the local repository the maven is not able to pick up > the > latest of the jars? > Yes, that's the problem - I can see that the latest jars are downloaded to my local repository, but they aren't used for the compiled war and ear files. Cheers, Papapara Tudu -- View this message in context: http://www.nabble.com/Problem-with-snapshots-tp15709789s177p15848863.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with snapshots
amit kumar-18 wrote: > > Well I faced a similar problem but configuring my remote repository for > snapshots worked for me. I had to add the below to my repository > > > my-internal-site > file:///192.168.x.x/Repository > > true > always > warn > > > > I started getting latest of the jars present under the project-SNAPSHOT > folder in the repository. > > I tried two configurations: 1. using my local repository both for releases and snapshots 2. having a separate local repo for releases and a separate one for snapshots. Both results were identical though :( Papapara Tudu -- View this message in context: http://www.nabble.com/Problem-with-snapshots-tp15709789s177p15829527.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with snapshots
Jeff MAURY wrote: > > Can you submit your output with -X option ? > > Jeff MAURY > > Maven produced 200 kB of logs, so I'll skip the rest, to me the most relevant seem to be these few lines: [INFO] snapshot com.company.project:project:2.2-SNAPSHOT: checking for updates from myRepository [DEBUG] Skipping disabled repository central [DEBUG] project: resolved to version 2.2-20080304.145740-2 from repository myRepository [DEBUG] com.company.project:project:jar:2.2-SNAPSHOT:compile (selected for compile) So Maven does see and download the new snapshot, but then it still uses the old one for compilation. Shouldn't the new snapshot (project-2.2-20080304.145740-2.jar) instantly replace the old project-2.2-SNAPSHOT.jar file when it's downloaded from Archiva? Papapara Tudu -- View this message in context: http://www.nabble.com/Problem-with-snapshots-tp15709789s177p15829461.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with snapshots
I just wanted to bring this topic up again as I still don't know what the reason for my problem is. Does anyone have any other ideas? Thanks! Cheers, Papapara Tudu -- View this message in context: http://www.nabble.com/Problem-with-snapshots-tp15709789s177p15824504.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Maven + Cargo] java.lang.OutOfMemoryError while remote deploying to Tomcat 5.0
Hello,
I have a web project that gets built into a war file. I am trying to get it
to work with remote deployment to Tomcat, as I've seen other people saying
that this configuration works for them (seen e.g. at
http://www.mail-archive.com/[EMAIL PROTECTED]/msg39920.html)
maven-war-plugin
src/main/webapp/WEB-INF/web.xml
true
lib/
true
org.codehaus.cargo
cargo-maven2-plugin
verify-deploy
install
deployer-deploy
clean-undeploy
pre-clean
deployer-undeploy
tomcat5x
remote
runtime
http://localhost:8080/manager
admin
tomcat
remote
com.company.project
webproject
war
http://localhost:8080/webproject/jsp/default.jsp
However when I try to deploy my war file using e.g. mvn clean install, I get
the java.lang.OutOfMemoryError:
(...)
[INFO] [cargo:deployer-deploy {execution: verify-deploy}]
[INFO] [mcat5xRemoteDeployer] Deploying [here path to the war file]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.OutOfMemoryError
[INFO]
(...)
Any ideas what I could be doing wrong?
Thanks,
Papapara Tudu
--
View this message in context:
http://www.nabble.com/-Maven-%2B-Cargo--java.lang.OutOfMemoryError-while-remote-deploying-to-Tomcat-5.0-tp15741242s177p15741242.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e
Re: Problem with snapshots
Jeff MAURY wrote: > > This is because the file name with the timestamp is something internal to > the repository. When the dependency is resolved to your WAR, the original > file name is restored based on the artifactId and the version you mention > in > your POM. > Maybe if you put Maven in debug mode, you could see that the file > retrieved > from your local repository is the one with the timestamp. > OK but I believe it should still work in the following way: when I build a referencing project, it takes the latest version of the jar (so that will be the project-2.2-20080226.143100-1.jar and not project-2.2-SNAPSHOT.jar) and puts it in the output war file. What it does though is it just takes the project-2.2-SNAPSHOT.jar file and puts it in the output war file. Papapara Tudu -- View this message in context: http://www.nabble.com/Problem-with-snapshots-tp15709789s177p15711493.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with snapshots
[EMAIL PROTECTED] wrote: > > The problem is that maven assumes that the -SNAPSHOT is the newest, not > the oldest version available. > > You obviously have projects that declare dependencies on just -SNAPSHOT, > but want the latest *dated* version to be used. So I suggest you delete > the original -SNAPSHOT version, or rename it to have an appropriate date > suffix. > The problem is that when I install new versions of that jar, they don't get picked up by the build - although the -SNAPHSOT version is NOT the newest anymore then. And this all has to work without deleting anything from the internal or local repositories - otherwise the problem will reoccur whenever new snapshots are created. I believe my understanding is correct: here's a quote from the "Better builds with Maven book: "You'll see that it is treated differently than when it was installed in the local repository. The filename that is used is similar to proficio-api-1.0-20060211.131114-1.jar. In this case, the version used is the time that it was deployed (in the UTC timezone) and the build number. If you were to deploy again, the time stamp would change and the build number would increment to 2. This technique allows you to continue using the latest version by declaring a dependency on 1.0- SNAPSHOT, or to lock down a stable version by declaring the dependency version to be the specific equivalent such as 1.0-20060211.131114-1." Papapara Tudu -- View this message in context: http://www.nabble.com/Problem-with-snapshots-tp15709789s177p15711423.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with snapshots
Hello, maybe I misunderstand something about snapshots, but I have the following problem: 1. I have a non-Maven project which I export into a jar file and then install as a snapshot onto my local repository running on Archiva with this command: mvn deploy:deploy-file -Dfile=Project.jar -DgroupId=com.company.project -DartifactId=project -Dversion=2.2-SNAPSHOT -Dpackaging=jar -DgeneratePom=true -Durl=http://[someip]/archiva/repository/myRepository -DrepositoryId=archiva.default 2. The very first version of that jar that was deployed onto the repository is saved as project-2.2-SNAPSHOT.jar. 3. As expected, any further jars that I deploy onto the local repository get saved as e.g. project-2.2-20080226.143100-1.jar 4. The problem is that when I reference that jar in any other project, when I build the other project, only the project-2.2-SNAPSHOT.jar version (the very first one that was installed) is picked up in the output war and ear files. 5. I can see that the actual snapshots, e.g. project-2.2-20080226.143100-1.jar do get downloaded from the internal repository and installed onto my local repository, but they're never used by referencing projects. 6. I'm using the Maven Plugin for Eclipse and what is strange is that in the Maven Dependencies tree in all referencing projects, I see the project-2.2-SNAPSHOT.jar file, but in the plugin logs on the Console I can see this: project: resolved to version project-2.2-20080226.143100-1 from repository myRepository 7. I reference this jar in other projects as: com.company.project project [2,) (I also tried this configuration: com.company.project project 2.2-SNAPSHOT but it had exactly the same results) 8. My pom.xml config is: myRepository dav:http://[someip]/archiva/repository/myRepository/ myRepository dav:http://[someip]/archiva/repository/myRepository/ myRepository myRepository http://[someip]/archiva/repository/myRepository true true I wonder what I am doing wrong. Thanks in advance for the help. Papapara Tudu -- View this message in context: http://www.nabble.com/Problem-with-snapshots-tp15709789s177p15709789.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Local repository not downloading Eclipse plugins from the internal repository
Wendy Smoak-3 wrote: > > > No ? You'll need to repeat the repository as a > pluginRepository if you want Maven to check it for plugins. > > Also check the repository metadata for the Eclipse plugin. Plugins > won't work unless the metadata contains the 'release' and 'latest' > elements. (Possibly only one of those is necessary, but if both are > missing, it won't work.) > > Hi Wendy, thank you for helping me out again (last time on the Archiva users forum) :) Yes you were right again, it was the missing tag. I guess it worked before because I had some old versions of Eclipse plugins on the machines where I have my local and internal repository which were created earlier, before the project was set up with the internal repo. Thanks, Papapara Tudu -- View this message in context: http://www.nabble.com/Local-repository-not-downloading-Eclipse-plugins-from-the-internal-repository-tp15502970s177p15560496.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Local repository not downloading Eclipse plugins from the internal repository
Wayne Fay wrote: > > What software are you using to run your internal repository? And how > did you get the plugin there (mvn deploy; manual copy of files; > something else)? Make sure the metadata is present for the Eclipse > plugin in your repo. > I'm using Archiva 1.0.1 and Maven 2.0.8. My Maven settings.xml are the default ones, no changes (on both machines). My pom.xml has the following entry: projectrepo dav:http://here.build.machine.ip/archiva/repository/projectrepo/ projectrepo projectreponame http://here.build.machine.ip/archiva/repository/projectrepo/ true true The problem is, I have noticed that even when I run a build on the build machine, where the Archiva repository is located, it also doesn't download any Maven plugins. The only way for me to download and install the Maven plugins both on the build and my local machine is to set a proxy in my settings.xml and comment out the and elements from pom.xml - so when I bypass the internal repository, it works fine. What could be wrong there? Thanks, Papapara Tudu -- View this message in context: http://www.nabble.com/Local-repository-not-downloading-Eclipse-plugins-from-the-internal-repository-tp15502970s177p15547059.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Local repository not downloading Eclipse plugins from the internal repository
Hello, my project is using an internal repository for all dependencies. For some reason I cannot run any of the Eclipse Maven plugins, however all other dependencies get downloaded correctly from the internal repository. For example, when I run mvn eclipse:eclipse, I get the following error: [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found [INFO] I deleted the whole \org\apache\maven\plugins folder from my local repository but that didn't change. I also tested deleting that folder on the internal repository and then running eclipse:eclipse on that machine and it went fine, the plugin got installed correctly. But my local repository doesn't pick up that plugin from the internal repository. Also the Eclipse plugins like eclipse:eclipse and eclipse:clean were definitely working for me before, which I don't understand. I'm using maven 2.0.7. Any ideas why that might be happening? Thanks, Papapara Tudu -- View this message in context: http://www.nabble.com/Local-repository-not-downloading-Eclipse-plugins-from-the-internal-repository-tp15502970s177p15502970.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Archiva getting very slow
Hello, we are running our internal Maven repository on Archiva and have encountered the problem that it starts taking a very long time to download any new project dependencies from it. What could the reasons be for that? Thanks, Papapara Tudu -- View this message in context: http://www.nabble.com/Archiva-getting-very-slow-tp15134139p15134139.html Sent from the archiva-users mailing list archive at Nabble.com.
