RE: Using 3rd party jar with surefire
I noticed this thread from a while back but there was never a resolution. We are trying to get our parasoft jtest generated test cases to run under Maven 2 and the surefire plugin with not much success. It looks like parasoft itself it spinning up its own classloader with the incorrect classpath. Has anyone had any luck getting jtest unit cases to run under Maven 2 and the surefire plugin? Scott Ryan When I moved the dependencies to be only under the durefire plugin, the [compiler:testCompile] goal failed with compile errors, so I left them both at the top level of the POM, and added them as dependencies to the surefire plugin. I figure that can't hurt. Alas, the result is the same as before. -Original Message- From: Kieran Brady [mailto:[EMAIL PROTECTED] Sent: Thu 6/8/2006 10:19 AM To: Maven Users List Subject: Re: Using 3rd party jar with surefire Something I would try would be adding those as dependencies to the surefire plugin. HTH - Original Message - From: "Brown, Charles" <[EMAIL PROTECTED]> To: "Maven Users List" ; "Maven Users List" Sent: Thursday, June 08, 2006 3:09 PM Subject: RE: Using 3rd party jar with surefire Yes, but I also add the parasoft jtest and junit jars, and the junit-addons, as below; junit junit 3.8.1 test parasoft.com jtest 7.5.43 test parasoft.com junit 7.5.43 test junit-addons junit-addons 1.4 test -Original Message- From: Thorsten Heit [mailto:[EMAIL PROTECTED] Sent: Thu 6/8/2006 9:59 AM To: Maven Users List Subject: Re: Using 3rd party jar with surefire -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Charles, > We use Parasoft JTest to generate JUnit based unit tests. Afterward, > I am able to run them in eclipse using "Run As -> JUnit Test", and > they work fine. So, I think I should be able to run them using > surefire, as long as I have the parasoft jars on the classpath, but I > get the errors below. Is there a reason this should not work, or is > there something I can do to make it work? Do you have JUnit in your class path? In my pom.xml I have the following dependency for the unit tests: ... junit junit 3.8.1 test ... - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cvs compression unsupported when using mvn release:prepare on linux.
We are trying to do a release:prepare using maven 2 and cvs. We are getting the following error message: [INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/als_source/src -n -q update -d [INFO] Working directory: /local/0/scm/dev_release/schema-framework [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to check for local modifications Provider message: The cvs command failed. Command output: cvs update: inflate: unknown compression method cvs [update aborted]: reading from server: Input/output error It looks like our versions of everything are ok. There are many suggestions on the web but none seem to work. Is there any way to disable the compression when doing a release:prepare. Scott D. Ryan Senior Java Developer/Architect Aurora Loan Services 10350 Park Meadows Drive Littleton, Co. 80124 Office: (720) 945-5328 Cell:(303) 263-3044 [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Health Report woes
WE have seen those issues as well as issues that occur cross repository. For example if there are 3 managed repositories in the Archiva system and all required jars are in the repositories but spread across multiple repositories it reports issues. This seems to indicate that multiple repositories are not encouraged. We divide up our repositories by license type for security reasons so for example if Hibernate is in one and commons-logging is in the other the health report complains that the proper jars are not present. This might be expected behavior but kind of limits you to one big repository for health reasons. Scott D. Ryan Senior Java Developer/Architect Aurora Loan Services 10350 Park Meadows Drive Littleton, Co. 80124 Office: (720) 945-5328 Cell:(303) 263-3044 [EMAIL PROTECTED] -Original Message- From: Max Bowsher [mailto:[EMAIL PROTECTED] Sent: Thursday, December 14, 2006 1:36 PM To: archiva-users@maven.apache.org Subject: Health Report woes I'm trying to use the archiva health report, but it is lying to me. It claims that metadata has no lastUpdated, when if you look in the XML file, it clearly does. It also claims that versions are not listed in the metadata, when, again, manual inspection shows that they are listed. Has anyone experienced these problems? Any thoughts on possible causes? Max. -- This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
Trunk build does not run in either plexus or tomcat
I get the following stack trace when trying to access Archiva for the first time when pulling new code from the trunk. It looks like some sort of configuration I missed. Can someone point me to the file I need to configure? Thanks jvm 1| [INFO] The appserver server has started. jvm 1| 2006-11-09 17:40:00,103 [SocketListener0-1] ERROR ObjectFactory:plexu s - Unable look up com.opensymphony.xwork.interceptor.Interceptor:pssF orceAdminUserInterceptor due to plexus misconfiguration. jvm 1| org.codehaus.plexus.xwork.ComponentCreationException: Unable look up com.opensymphony.xwork.interceptor.Interceptor:pssForceAdminUserIntercep tor due to plexus misconfiguration. jvm 1| at org.codehaus.plexus.xwork.PlexusObjectFactory.lookup(PlexusOb jectFactory.java:399) jvm 1| at org.codehaus.plexus.xwork.PlexusObjectFactory.loadComponentWi thPlexus(PlexusObjectFactory.java:346) jvm 1| at org.codehaus.plexus.xwork.PlexusObjectFactory.lookup(PlexusOb jectFactory.java:326) jvm 1| at org.codehaus.plexus.xwork.PlexusObjectFactory.buildBean(Plexu sObjectFactory.java:170) jvm 1| at org.codehaus.plexus.xwork.PlexusObjectFactory.buildIntercepto r(PlexusObjectFactory.java:99) jvm 1| at com.opensymphony.xwork.config.providers.InterceptorBuilder.co nstructInterceptorReference(InterceptorBuilder.java:48) jvm 1| at com.opensymphony.xwork.config.providers.XmlConfigurationProvi der.lookupInterceptorReference(XmlConfigurationProvider.java:702) jvm 1| at com.opensymphony.xwork.config.providers.XmlConfigurationProvi der.loadInterceptorStack(XmlConfigurationProvider.java:569) jvm 1| at com.opensymphony.xwork.config.providers.XmlConfigurationProvi der.loadInterceptorStacks(XmlConfigurationProvider.java:582) jvm 1| at com.opensymphony.xwork.config.providers.XmlConfigurationProvi der.loadInterceptors(XmlConfigurationProvider.java:603) jvm 1| at com.opensymphony.xwork.config.providers.XmlConfigurationProvi der.addPackage(XmlConfigurationProvider.java:204) jvm 1| at com.opensymphony.xwork.config.providers.XmlConfigurationProvi der.loadConfigurationFile(XmlConfigurationProvider.java:676) jvm 1| at com.opensymphony.xwork.config.providers.XmlConfigurationProvi der.loadConfigurationFile(XmlConfigurationProvider.java:679) jvm 1| at com.opensymphony.xwork.config.providers.XmlConfigurationProvi der.init(XmlConfigurationProvider.java:91) jvm 1| at com.opensymphony.xwork.config.impl.DefaultConfiguration.reloa d(DefaultConfiguration.java:85) jvm 1| at com.opensymphony.xwork.config.ConfigurationManager.getConfigu ration(ConfigurationManager.java:54) jvm 1| at com.opensymphony.xwork.DefaultActionProxy.(DefaultActio nProxy.java:57) jvm 1| at com.opensymphony.xwork.DefaultActionProxyFactory.createAction Proxy(DefaultActionProxyFactory.java:46) jvm 1| at com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAc tion(DispatcherUtils.java:216) jvm 1| at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter (FilterDispatcher.java:202) jvm 1| at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.d oFilter(WebApplicationHandler.java:821) jvm 1| at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage( PageFilter.java:118) jvm 1| at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(P ageFilter.java:52) jvm 1| at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.d oFilter(WebApplicationHandler.java:821) jvm 1| at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFi lter(ActionContextCleanUp.java:88) jvm 1| at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.d oFilter(WebApplicationHandler.java:821) jvm 1| at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebA pplicationHandler.java:471) jvm 1| at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandle r.java:568) jvm 1| at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) jvm 1| at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApp licationContext.java:633) jvm 1| at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) jvm 1| at org.mortbay.http.HttpServer.service(HttpServer.java:909) jvm 1| at org.mortbay.http.HttpConnection.service(HttpConnection.java:8 16) jvm 1| at org.mortbay.http.HttpConnection.handleNext(HttpConnection.jav a:982) jvm 1| at org.mortbay.http.HttpConnection.handle(HttpConnection.java:83 3) jvm 1| at org.mortbay.http.SocketListener.handleConnection(SocketListen er.java:244) jvm 1| at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:35 7) jvm 1| at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:53 4) jvm 1| Caused by: org.codehaus.plexus.component.repository.exception.Compone ntLookupException: Unable to l
RE: download artefacts from managed repositories
I will give the line 187 thing a shot and see how it works although with the latest build it seems to be working again and all repositories are accessed via the proxy. This has shown me that I really need some way to control what is accessed via the proxy and the order so it looks like I have to make all my accesses via a repoid. I have not had any luck with the repoid but let me try again. I want to avoid getting artifacts from the wrong repo. We actually package our ears with different build plans and properties for different environments so we actually need to keep copies of the artifacts for the various environments. Also for different environments various people have access to different repositories. For example dev cannot access the Qa, stage, or prod artifacts. Other groups can see some and not others. In reviewing the security overview that was implemented it seemed to indicate there might be a way to secure repositories from update based on the framework. I would think this would require you to do deployments via the archiva url. Maybe this is coming in the future. Any way lets keep up this discussion and it will ferret out some of the needs for the offering and we can document a complex enterprise usecase for others to benefit from. I will make the fix and see how it works then I can clarify my actual final implementation of repositories. Another thing I am struggling with is how to separate the artifacts during the build phase. In maven 1 I used a property to dynamically change the local repo based on the build profile. For example for dev builds I used c:mavenrepodev and for stage c:mavenrepostage. Since maven 2 does not allow you to do much with properties inside the pom I can't seem to find a solution. I tried using the group id and changing it based on a property but that is not working. For example if my group id was Scott I might use dev.scott for dev and qa.scott for qa etc. I am still trying to find a way to separate the artifacts based on build environment. It is pretty easy to change the remote repositories based on a profile however I cannot figure out how to change the local repository or the artifact name to insure I am always using consistent artifacts. For example if artifact 1 relies on artifact 2 I want to make sure when I build for dev I get the two artifacts that were built with the dev profile and qa etc. This discussion is useful and I look forward to more information coming onto this list and getting more of the functionality worked out and some best practices documented. So to clarify my current repo layout I have the following repos: Oss - proxied to the maven repos Snapshot oss - proxied to maven snapshot repos Internal - Internally developed libraries that are not built by our group Licensed - Licensed software jars OtherOss - jars not available via proxy like jta and mail Dev - dev artifacts that we build from our source Qa - qa artifacts that we build from our source Stage - stage artifacts that we build from our source Prod - production artifacts we build from our source I will probabaly create a snapshot repo to use for our continuum and cruise control builds so I can delete artifacts and manage the size. That is a good I idea I had not thought of that you suggest. I am still struggling with the checksum issue when downloading up to 30% of my artifacts from the proxy. Another issue I am seeing is that many of my artifacts are not being indexed. I wonder if this is because not all the related artifacts are stored in the archiva repository due to the checksum issue or just do to the checksum issue itself. I will look in to the logs more to see what is going on. Thanks for the dialog!! Scott D. Ryan Senior Java Developer/Architect -Original Message- From: Mohni, Daniel [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 12:00 AM To: archiva-users@maven.apache.org Subject: RE: download artefacts from managed repositories Hi Scott Answers inline... > I am having a similar issue. I have defined several managed > repositories but the only ones that are consulted for artifacts are > those that have proxies defined. I got around that by creating dummy > managed repositories and proxying them out to the real ones but that > is not a very secure solution. if you remove line 187 of the 'DefaultProxyManager' you can access all managed repositories without the use of dummies. This was the way it was handled a few revisions earlier... -> the download button on the web-app will not work anymore, but this only works if you have only 1 repository... > Here are some questions that I would love to understand when setting > up my repos. > > > Can I push artifacts to specific managed repositories via the proxy > url. > (ie. http://localhost:8080/archiva/proxy//) As far as I know you currently can not publish tru archiva > Can I download artifacts from only certain repositories if desired > (ie. > http://localho
RE: [archiva] disabling the checksum policy
That is an ongoing discussion that everyone is having with the current repos. There was a suggested fix proposed on the mailing list earlier this week but no details or description of when or how to get it into the source tree. It seems like if you cannot download most of the maven base plugins people must be using this project in some different manner. I am more than happy to make the change locally if I can get some direction. If not I will run through the source tonight to see if I can come up with a fix. If any one has any suggestions I would welcome them. Scott D. Ryan Senior Java Developer/Architect Aurora Loan Services 10350 Park Meadows Drive Littleton, Co. 80124 Office: (720) 945-5328 Cell:(303) 263-3044 [EMAIL PROTECTED] -Original Message- From: Raphaël Piéroni [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 6:07 AM To: archiva-users@maven.apache.org Subject: [archiva] disabling the checksum policy Hi, I have configured some proxies (central, mergere, java.net) into a repository. I also have configured my settings.xml to use my archiva proxy instead of the central repository (using the mirror element) When i try to deploy a project (with pom packaging) it fails saying the deploy plugin is not found. When i disable my mirroring, it finds the plugin with warning on checksum. When i 'tail -f' the archiva logs (and using the mirror) it also complains on checksum but also says it don't use the deploy plugin because of that checksum. My question is : how to configure archiva not to perform checksum failures on certains proxied repositories (if it could be fine grained,...) Many thanks for any help. Regards, Raphaël -- This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
RE: How to configure a checksumPolicy ?
Any status on this one? I would love to make the change or use the change. It appears that about 25-30% of what I need has bad checksums including most of the native plugins such as clean, deploy etc. This means that I can't do much without being able to turn off the checksum feature. Any ideas would be appreciated. Is there a way to turn this off temporarily so I can at least move forward with some testing by manually modifying the XML files? Thanks Scott D. Ryan Senior Java Developer/Architect -Original Message- From: Nicolas DE LOOF [mailto:[EMAIL PROTECTED] Sent: Monday, October 23, 2006 6:57 AM To: archiva-users@maven.apache.org Subject: Re: How to configure a checksumPolicy ? I have something that may work but can't build archiva for now due to network errors accessing http://people.apache.org/repo/m2-snapshot-repository My patch will require to add a boolean attribute to ProxiedRepositoryConfiguration, that is generated by modelo. Is there some design / formatting rules to know for editing mdo files, or can I consider them "just" beeing XML files ? Nico. Brett Porter a écrit : > We could add it to the proxy configuration page. Did you want to take > a look at providing a patch? Should be quite straightforward. > > On 20/10/2006, at 10:13 PM, Nicolas DE LOOF wrote: > >> >> I have errors using archiva as a proxy due to bad checksums on ibiblio. >> Is there any way to set the checksumPolicy to WARNING in archiva ? >> >> Nico. >> >> >> This message contains information that may be privileged or >> confidential and is the property of the Capgemini Group. It is >> intended only for the person to whom it is addressed. If you are not >> the intended recipient, you are not authorized to read, print, >> retain, copy, disseminate, distribute, or use this message or any >> part thereof. If you receive this message in error, please notify >> the sender immediately and delete all copies of this message. > This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
RE: download artefacts from managed repositories
I am having a similar issue. I have defined several managed repositories but the only ones that are consulted for artifacts are those that have proxies defined. I got around that by creating dummy managed repositories and proxying them out to the real ones but that is not a very secure solution. Here are some questions that I would love to understand when setting up my repos. Can I push artifacts to specific managed repositories via the proxy url. (ie. http://localhost:8080/archiva/proxy//) Can I download artifacts from only certain repositories if desired (ie. http://localhost:8080/archiva/proxy//) Can I access specific repositories by name rather than all of them. For example I have a repository that I push artifacts to for dev, qa, stage and prod. When I build I want to only upload and download to those repositories and some of my open source repos. This allows me to build using profiles for all of my environments without risk of intermixing artifacts from different environments. It would really help to clarify a set of use cases for how to set up a group of proxied and managed repositories for a complex enterprise. Once I understand how this all works I am more than happy to write a section for inclusion in the user guide. Scott D. Ryan Senior Java Developer/Architect Aurora Loan Services 10350 Park Meadows Drive Littleton, Co. 80124 Office: (720) 945-5328 Cell:(303) 263-3044 [EMAIL PROTECTED] -Original Message- From: Mohni, Daniel [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 9:42 AM To: archiva-users@maven.apache.org Subject: download artefacts from managed repositories Hello I was checking the daily build for archiva today and I configured 2 repositories, one proxied to ibiblio and one without proxy. Browsing the repository I can only download artefacts from proxied repositories. Artefacts in managed repositories are not handled. I checked the code and found the problem in DefaultProxyManager.getProxyGroups() Only Proxied Repositories are added to the group, and therefore only managed repositories will be searched for a requested artefact. If I comment line 178 // if ( !proxiedRepositories.isEmpty() ) then I can only download artefacts when I add the repoId in the url for the download http://localhost:8080/archiva/proxy//... now all artefacts are accessible... Is this the way it should work, or should this be changed ? if only 1 proxied repository is defined, then the downloads will work, because it is hendled like the default repo (Line 187-190). -> as soon as you have more than on proxied repository (release, snapshot) you will get problems. If the indexer would add the repository_id to the model, the url could be modified to contain the repo_id now, I can have a closer look, if this is the way to go... - Daniel -- This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
Help with multiple Repositories
I am trying to set up a fairly complex set of repositories and am running into some challenges. I think most of it is my understanding of the details of how Archiva is structured. Once I get a better understanding I hope to help provide feedback in the user guide to help other users. So I have set up 4 managed repositories OpenSource SpecialOpenSource Internal LicensedInternal I have created 2 proxied repositories. When I run index I am able to see all the artifacts from all the managed repositories. When I access the repositories using my settings.xml I am not able to located any of the artifacts within the managed repositories. I am using http://localhost:8080/archiva/proxy as the repository location. Is there something special I have to do to get it to download artifacts from the managed repositories. I am getting the artifacts from the proxied repositories and I am assuming that those proxied artifacts are then stored in one of my managed repositories so I can run reports against them. 1) How do I get the managed repositories to be accessed to look for artifacts? 2) Can I use the above URL to gain access to artifacts from all managed repositories or do I need to access them in some other way 3) Is there a way to upload(deploy) via the proxy or through archiva to the managed repositories and how do I determine which repository to upload to 4) Are the artifacts downloaded from the proxied repositories stored in one of the managed repositories and how do I determine which managed repository they are stored in. I apologize if these are basic questions but I have been working with Archiva all weekend and am excited about the possibilities but just need to get some basic understanding of how it works. I fully intend to document all that I learn and send it to the developers if that would be useful in the user guide. Scott D. Ryan Senior Java Developer/Architect Aurora Loan Services 10350 Park Meadows Drive Littleton, Co. 80124 Office: (720) 945-5328 Cell:(303) 263-3044 [EMAIL PROTECTED] -- This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
RE: Upgrade from 1.0.2 to 1.0.3 causes build.properties substitution to cease
Thanks for the information.
The problem is that our SCM URL's contain a generic user name ${maven.username}
so that every user can gain access independently to the CVS system. I can
substitute the user name in continuum to get it to build once but the next time
the project.xml is pulled down from CVS it is overlaid with the substitution
parameter. I can't put a user name in the URL within CVS because then every
user that uses Maven would use that user name (Bad thing). Is there any way to
build an SCM url that allows me to substitute a user name at retrieve time so
that I don't have to check in a user name in my project.xml? Is there a way to
use a system property or a -D flag on the command to get the proper name into
the build? Is this also the case for Maven 2.0? This would present a huge
security issue for us if we allowed user names on the URL's inside our cvs
system.
Scott D. Ryan
Senior Java Developer/Architect
Aurora Loan Services
10350 Park Meadows Drive
Littleton, Co. 80124
Office: (720) 945-5328
Cell:(303) 263-3044
[EMAIL PROTECTED]
-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 5:50 PM
To: continuum-users@maven.apache.org
Subject: Re: Upgrade from 1.0.2 to 1.0.3 causes build.properties substitution
to cease
This feature doesn't exist in continuum 1.0.3 (and it wasn't in continuum 1.0.2
too) because it isn't implemented. Continuum doesn't read build.properties
file, only maven1 use it.
So you need to add the real scm url in your pom without parameters (same for
the name, artifactId, groupId, version), for other part, you can use parameters
if they aren't use by continuum but only by maven1
Emmanuel
Ryan, Scott D a écrit :
> I recently upgraded from Continuum 1.0.2 to 1.0.3 using a Maven 1
> project.xml and I was using parameter substitution from my
> build.properties file to fill in a parameter on my SCM URL string.
> The current string is as follows:
>
> scm:cvs:pserver:[EMAIL PROTECTED]:/somedirectory/src:modul
> en
> ame
>
> I am relying on the maven.username to be filled in from the
> build.properties file but it looks like that does not work with
> version 1.0.3. I also tried to add a command line parameter
> -Dmaven.username=someuserid and that was not picked up either. If I
> fill in the name manually everything seems to run ok however then next
> time a build happens the project.xml is replaced and my substitution
> is broken again.
>
> Scott D. Ryan
> Senior Java Developer/Architect
> Aurora Loan Services
> 10350 Park Meadows Drive
> Littleton, Co. 80124
> Office: (720) 945-5328
> Cell:(303) 263-3044
> [EMAIL PROTECTED]
>
> --
> This message is intended only for the personal and
> confidential use of the designated recipient(s) named. If you are not the
> intended recipient of this message, you are hereby notified that any review,
> dissemination, distribution or copying of this message is strictly
> prohibited. This communication is for information purposes only and should
> not be regarded as an offer to sell or as a solicitation of an offer to buy
> any financial product, an official confirmation of any transaction, or as an
> official statement of Aurora Loan Services. Email transmission cannot be
> guaranteed to be secure or error-free. Therefore, we do not represent that
> this information is complete or accurate and it should not be relied upon as
> such. All information is subject to change without notice.
>
>
>
>
--
This message is intended only for the personal and confidential use of the
designated recipient(s) named. If you are not the intended recipient of this
message, you are hereby notified that any review, dissemination, distribution
or copying of this message is strictly prohibited. This communication is for
information purposes only and should not be regarded as an offer to sell or as
a solicitation of an offer to buy any financial product, an official
confirmation of any transaction, or as an official statement of Aurora Loan
Services. Email transmission cannot be guaranteed to be secure or error-free.
Therefore, we do not represent that this information is complete or accurate
and it should not be relied upon as such. All information is subject to change
without notice.
ConcurrentModificationException when building with maven 1, CVS and Windows
I noticed a posting on JIRA for this issue but no activity since November. We were getting this problem on some of our projects but it seems now that non of our projects will build due to this error. Has anyone found a cause or workaround for this issue. java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448) at java.util.AbstractList$Itr.next(AbstractList.java:419) at org.apache.maven.continuum.execution.maven.m1.DefaultMavenOneMetadataHel per.mapMetadata(DefaultMavenOneMetadataHelper.java:288) at org.apache.maven.continuum.execution.maven.m1.MavenOneBuildExecutor.upda teProjectFromCheckOut(MavenOneBuildExecutor.java:108) at org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectory ContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction .java:62) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build( DefaultBuildController.java:169) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.exec uteTask(BuildProjectTaskExecutor.java:53) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:534) http://jira.codehaus.org/browse/CONTINUUM-441 Scott D. Ryan -- This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
