Archiva freeze because of down site ?
Hello, Today, archiva was (again freezed) but restart didn't solve the problem. Looking in the logs, I saw that one of our remote repositories was dead; removing it solved the problem. Archiva do not cache information about unavailable site to not calling it for each artifact ? Could be a useful improvement ? PS: I didn't have any answer about my mail Cannot use archiva browse function after 2 days running; we still have to restart archiva every one, two or three days because it freezes. Please, help would be very welcome; thanks. This morning, Archiva was freezed again; here's the top on the server : PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ 25619 archiva 19 0 209m 186m 103m R 17.0 21.1 53:14.14 25751 archiva 20 0 209m 186m 103m R 16.8 21.1 47:34.28 28163 archiva 14 0 209m 186m 103m S 16.6 21.1 40:42.57 28124 archiva 14 0 209m 186m 103m S 16.4 21.1 41:44.36 26348 archiva 19 0 209m 186m 103m R 15.7 21.1 43:01.91 -- Julien CARSIQUE, Nuxeo (Paris, France) Open Source Enterprise Content Management - http://www.nuxeo.org/ Nuxeo EP 5: extensible, Java EE and standards based ECM Platform http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
Re: maven-eclipse-plugin in online mode with downloadSources=true
mvn eclipse:clean eclipse:eclipse has just finished [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 134 minutes 34 seconds [INFO] Finished at: Thu Dec 20 18:14:35 CET 2007 [INFO] Final Memory: 66M/254M 134 minutes to download sources against 1min30 with -DdownloadSources=false Why this crazy difference ? It could be useful to download javadoc too but I fear having to wait for 3 more hours :-( Any help would be appreciated, thanks Julien Julien CARSIQUE a écrit : Hi, Does anyone use maven-eclipse:plugin, mvn eclipse:eclipse in online mode with downloadSources=true ? In offline, it takes about 1min30; online, with downloadSources=true, it takes several hours (when it finishes, as archiva often freeze on too long tasks) ! I have this configuration in the parent pom.xml : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.4/version configuration downloadSourcestrue/downloadSources /configuration /plugin If this can be a workaround, is it possible to store the sources' status cache, outside the target dir ? Enables/disables the downloading of source attachments. Defaults to false. When this flag is |true| remote repositories are checked for sources: in order to avoid repeated check for unavailable source archives, a status cache is mantained into the target dir of the root project. Run |mvn:clean| or delete the file |mvn-eclipse-cache.properties| in order to reset this cache.
Re: Archiva freeze because of down site ?
Cache failure option is supposed (AFAIK) to enable such caching, and avoid requesting again and again the same repository, where 404 or timeout occurs. Reading the code, (DefaultRepositoryProxyConnectors) seems the cache is not used before requesting a proxyConnector for an artifact. 404 also are not cached, and IMHO they should for performance consideration (exemple : many artifact have no -sources.jar, but are requested by IDE plugins). The cache configuration is also hardcoded in archiva-policies. Not sure it will fit the requirements for all users and use-cases (missing artifact, network connection borken ...). I'll look at this tomorow, could you please fill an issue in Jira ? Nico. 2007/12/20, Julien CARSIQUE [EMAIL PROTECTED]: Hello, Today, archiva was (again freezed) but restart didn't solve the problem. Looking in the logs, I saw that one of our remote repositories was dead; removing it solved the problem. Archiva do not cache information about unavailable site to not calling it for each artifact ? Could be a useful improvement ? PS: I didn't have any answer about my mail Cannot use archiva browse function after 2 days running; we still have to restart archiva every one, two or three days because it freezes. Please, help would be very welcome; thanks. This morning, Archiva was freezed again; here's the top on the server : PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ 25619 archiva 19 0 209m 186m 103m R 17.0 21.1 53:14.14 25751 archiva 20 0 209m 186m 103m R 16.8 21.1 47:34.28 28163 archiva 14 0 209m 186m 103m S 16.6 21.1 40:42.57 28124 archiva 14 0 209m 186m 103m S 16.4 21.1 41:44.36 26348 archiva 19 0 209m 186m 103m R 15.7 21.1 43:01.91 -- Julien CARSIQUE, Nuxeo (Paris, France) Open Source Enterprise Content Management - http://www.nuxeo.org/ Nuxeo EP 5: extensible, Java EE and standards based ECM Platform http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
Re: Archiva freeze because of down site ?
Yeah, improvements to the caching should certainly be filed as a feature request - and we should run through the plan on the dev@ list if possible. As far s your original freezing problem goes - I assigned it to the 1.0.1 version yesterday. I've seen another report too and they are helping to diagnose what the cause is. I had a suspicion it might be because of remote repository connections - I think this evidence is starting to confirm that. - Brett On 21/12/2007, nicolas de loof [EMAIL PROTECTED] wrote: Cache failure option is supposed (AFAIK) to enable such caching, and avoid requesting again and again the same repository, where 404 or timeout occurs. Reading the code, (DefaultRepositoryProxyConnectors) seems the cache is not used before requesting a proxyConnector for an artifact. 404 also are not cached, and IMHO they should for performance consideration (exemple : many artifact have no -sources.jar, but are requested by IDE plugins). The cache configuration is also hardcoded in archiva-policies. Not sure it will fit the requirements for all users and use-cases (missing artifact, network connection borken ...). I'll look at this tomorow, could you please fill an issue in Jira ? Nico. 2007/12/20, Julien CARSIQUE [EMAIL PROTECTED]: Hello, Today, archiva was (again freezed) but restart didn't solve the problem. Looking in the logs, I saw that one of our remote repositories was dead; removing it solved the problem. Archiva do not cache information about unavailable site to not calling it for each artifact ? Could be a useful improvement ? PS: I didn't have any answer about my mail Cannot use archiva browse function after 2 days running; we still have to restart archiva every one, two or three days because it freezes. Please, help would be very welcome; thanks. This morning, Archiva was freezed again; here's the top on the server : PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ 25619 archiva 19 0 209m 186m 103m R 17.0 21.1 53:14.14 25751 archiva 20 0 209m 186m 103m R 16.8 21.1 47:34.28 28163 archiva 14 0 209m 186m 103m S 16.6 21.1 40:42.57 28124 archiva 14 0 209m 186m 103m S 16.4 21.1 41:44.36 26348 archiva 19 0 209m 186m 103m R 15.7 21.1 43:01.91 -- Julien CARSIQUE, Nuxeo (Paris, France) Open Source Enterprise Content Management - http://www.nuxeo.org/ Nuxeo EP 5: extensible, Java EE and standards based ECM Platform http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87 -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/
how to bind archiva to a ip?
My server has 2 ip, one inner and one outer, we just don't want the people not in our company to access the archiva, so we want to bind the archiva to the inner ip. It really confused me for one day, I tried to search the answer in google, but nothing can help, I just find out jetty it self can do it by config it in jetty.xml, but archiva seems not provide such config file, could anybody help me please?
Re: Problem to send email (Validation user) with Continuum 1.1 final
I found in wiki: http://docs.codehaus.org/display/CONTINUUMUSER/Deploying The config of /path/to/continuum/conf/security.properties. In this file there is: # # Email Settings # All emails sent by the system will be from the following user name (used in conjunction with address) [EMAIL PROTECTED] email.from.name=Continuum Admin Username # The subject line for the email message. email.validation.subject=Welcome to Maven Continuum I looked for this file in Continuum 1.1 final, but I did´nt find security.properties in /path/to/continuum/conf/ Using grep I found the file security.properties in /path/to/continuum/apps/continuum/webapp/WEB-INF/classes/org/apache/maven/continuum/security.properties I added in this file this lines: [EMAIL PROTECTED] email.from.name=Continuum This config resolved my problem (with com.sun.mail.smtp.SMTPSendFailedException: 553 5.5.4 [EMAIL PROTECTED]... Real domain name required for sender address) Bye - Original Message - From: Claudio R [EMAIL PROTECTED] To: continuum-users@maven.apache.org Sent: Wednesday, December 19, 2007 9:39 PM Subject: Problem to send email (Validation user) with Continuum 1.1 final Hi, I configured the CONTINUUM_HOME/conf/plexus.xml as: resource namemail/Session/name typejavax.mail.Session/type properties property namemail.smtp.host/name valuexxx.xxx.com.br/value /property property namemail.smtp.port/name value25/value /property !-- property namemail.smtp.auth/name valuetrue/value /property property namemail.smtp.user/name valueyour_login/value /property property namepassword/name valueyour_password/value /property property namemail.smtp.debug/name valuetrue/value /property property namemail.smtp.starttls.enable/name valuetrue/value /property property namemail.smtp.socketFactory.class/name valuejavax.net.ssl.SSLSocketFactory/value /property -- /properties /resource But when I add a new user and I click in Resend Validation, I get in continuum.log org.codehaus.plexus.mailsender.MailSenderException: Error while sending the message. at org.codehaus.plexus.mailsender.javamail.AbstractJavamailMailSender.send(AbstractJavamailMailSender.java:221) at org.codehaus.plexus.redback.xwork.mail.Mailer.sendMessage(Mailer.java:145) at org.codehaus.plexus.redback.xwork.mail.Mailer.sendAccountValidationEmail(Mailer.java:70) at org.codehaus.plexus.redback.xwork.action.RegisterAction.resendRegistrationEmail(RegisterAction.java:207) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:358) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192) at org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:114) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:149) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.AutoLoginInterceptor.intercept(AutoLoginInterceptor.java:156) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.ForceAdminUserInterceptor.intercept(ForceAdminUserInterceptor.java:76) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.EnvironmentCheckInterceptor.intercept(EnvironmentCheckInterceptor.java:122) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) at
last committers with ant?
Hi, is it possible to use send email to last committers with ANT as build tool? How can i add developers? Cheers, Ingo -- CRM Products Development - EIM Tel: +49 721 / 9638-255 CAS Software AG Well informed. Always and everywhere. www.cas.de CAS Software AG - Wilhelm-Schickard-Straße 10-12 - 76131 Karlsruhe - Telefon +49 721 9638-0 - www.cas.de - Impressum und AGB Vorstand: Martin Hubschneider (Vorsitz) - Ludwig Neer - Frank Widmayer Aufsichtsrat: Dr. Dr. Jörg Maurer (Vorsitz) - Prof. Dr. Peter Lockemann - Dr. habil. Karl Schlagenhauf Amtsgericht Mannheim - Handelsregister-Nr.: HRB 108751 - UID Nr.: DE143593148
Re: last committers with ant?
Hi, Currently not possible. It's possible with maven because the pom contains informations in the developpers section to match committer id with an email/name. -- Olivier 2007/12/20, Ingo Siebert [EMAIL PROTECTED]: Hi, is it possible to use send email to last committers with ANT as build tool? How can i add developers? Cheers, Ingo -- CRM Products Development - EIM Tel: +49 721 / 9638-255 CAS Software AG Well informed. Always and everywhere. www.cas.de CAS Software AG - Wilhelm-Schickard-Straße 10-12 - 76131 Karlsruhe - Telefon +49 721 9638-0 - www.cas.de - Impressum und AGB Vorstand: Martin Hubschneider (Vorsitz) - Ludwig Neer - Frank Widmayer Aufsichtsrat: Dr. Dr. Jörg Maurer (Vorsitz) - Prof. Dr. Peter Lockemann - Dr. habil. Karl Schlagenhauf Amtsgericht Mannheim - Handelsregister-Nr.: HRB 108751 - UID Nr.: DE143593148
[c-1.1] ORA-00910: specified length too long for its datatype
*I have looked at:* http://jira.codehaus.org/browse/CONTINUUM-1189 *And I have the same error, but I can't find a resolution for version 1.1NOT 1.1 alpha:* 2007-12-20 16:50:27,549 [main] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager:default - Build executors: 2007-12-20 16:50:27,550 [main] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager:default - ant 2007-12-20 16:50:27,550 [main] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager:default - maven-1 2007-12-20 16:50:27,551 [main] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager:default - maven2 2007-12-20 16:50:27,551 [main] INFO org.apache.maven.continuum.execution.manager.BuildExecutorManager:default - shell 2007-12-20 16:50:27,615 [main] INFO org.apache.maven.continuum.Continuum:default - Initializing Continuum. 2007-12-20 16:50:27,616 [main] INFO org.apache.maven.continuum.Continuum:default - Showing all projects: 2007-12-20 16:50:27,884 [main] ERROR JPOX.RDBMS - Error thrown executing CREATE TABLE CHANGESET ( CHANGESET_ID NUMBER NOT NULL, AUTHOR VARCHAR2(255) NULL, CHANGECOMMENT VARCHAR2(8192) NULL, CHANGEDATE NUMBER NOT NULL, ID VARCHAR2(255) NULL, MODEL_ENCODING VARCHAR2(255) NULL, CHANGES_SCMRESULT_ID_OID NUMBER NULL, CHANGES_INTEGER_IDX NUMBER(10) NULL ) : ORA-00910: specified length too long for its datatype java.sql.SQLException: ORA-00910: specified length too long for its datatype at oracle.jdbc.driver.DatabaseError.throwSqlException( DatabaseError.java:158) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:316) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:282) at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:639) at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:113) at oracle.jdbc.driver.T4CStatement.execute_for_rows( T4CStatement.java:703) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout( OracleStatement.java:1196) at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java :1804) at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.execute( DelegatingStatement.java:264) at org.jpox.store.rdbms.table.AbstractTable.executeDdlStatement( AbstractTable.java:614) at org.jpox.store.rdbms.table.AbstractTable.executeDdlStatementList( AbstractTable.java:570) at org.jpox.store.rdbms.table.AbstractTable.create( AbstractTable.java:297) at org.jpox.store.rdbms.table.AbstractTable.exists( AbstractTable.java:341) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation( RDBMSManager.java:3052) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate( RDBMSManager.java:3313) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.run( RDBMSManager.java:2554) at org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute( RDBMSManager.java:2406) at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java :821) at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:835) at org.jpox.store.StoreManager.getDatastoreClass(StoreManager.java :1161) at org.jpox.store.rdbms.RDBMSManager.getExtent(RDBMSManager.java :1354) at org.jpox.AbstractPersistenceManager.getExtent( AbstractPersistenceManager.java:2312) at org.codehaus.plexus.jdo.PlexusJdoUtils.getAllObjectsDetached( PlexusJdoUtils.java:358) at org.codehaus.plexus.jdo.PlexusJdoUtils.getAllObjectsDetached( PlexusJdoUtils.java:342) at org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached( JdoContinuumStore.java:1936) at org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached( JdoContinuumStore.java:1921) at org.apache.maven.continuum.store.JdoContinuumStore.getAllProjectsByNameWithBuildDetails (JdoContinuumStore.java:1128) at org.apache.maven.continuum.DefaultContinuum.initialize( DefaultContinuum.java:2648) at org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute (InitializePhase.java:33) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start( AbstractLifecycleHandler.java:128) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle (AbstractComponentManager.java:142) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance (AbstractComponentManager.java:132) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent (ClassicSingletonComponentManager.java:90) at org.codehaus.plexus.DefaultComponentLookupManager.lookup( DefaultComponentLookupManager.java:147) at org.codehaus.plexus.DefaultPlexusContainer.lookup( DefaultPlexusContainer.java:327) at org.codehaus.plexus.container.initialization.StartLoadOnStartComponentsPhase.execute
Problem adding a maven 2 project to continuum 1.1
Dear all, I am trying to use Continuum for regression testing of a multi-module maven 2 project. I'm running Continuum 1.1 (final) on a Linux 2.6.18 box, Java 1.6, Maven 2.0.8. At the Add Maven 2.0+ Project page, I typed the correct SVN repository link: scm:svn:https://dev.ruready.utah.edu/svn/ruready/trunk/applications/ruready But I get this error in the UI: The specified resource cannot be accessed. Please try again later or contact your administrator. Tomcat log: 2007-12-20 22:50:36,662 [http-8080-2] WARN com.opensymphony.webwork.dispatcher.mu ltipart.MultiPartRequest - Item is a file upload of 0 size, ignoring I tried everything -- e.g. tweaking webworks.properties to make sure the temp directory is writable. Indeed, I see that the web app wrote three files to start downloading the pom: -rw-rw-r-- 1 ruready ruready 10 Dec 20 22:55 upload__6d2fdca1_116fa628faf__8000_0021.tmp -rw-rw-r-- 1 ruready ruready 7 Dec 20 22:55 upload__6d2fdca1_116fa628faf__8000_0020.tmp -rw-rw-r-- 1 ruready ruready 83 Dec 20 22:55 upload__6d2fdca1_116fa628faf__8000_0019.tmp (containing the requested URL, SVN user name and password), but the file is not downloaded. Is there a solution or a workaround to this bug? It's bounding me from using Continuum for now. Thanks so much in advance, Oren -- === PERSISTENT, adj. Remaining infective for a relatively long time in a vector after an initial period of incubation. -- Meriam-Webster Dictionary --- Oren Livne, Ph.D. RUReady Software Architect Academic Outreach and Continuing Education, 1901 E South Campus Dr. Room 2197-D, University of Utah, Salt Lake City, UT 84112-9399 Tel : (801) 581-6831 Cell: (801) 631-3885 Fax: (801) 585-5414 Email: [EMAIL PROTECTED] Web: http://ruready.net/oren ===
Re: Problem adding a maven 2 project to continuum 1.1
Dear Mick, Thanks so much. Works like magic. I also added an scm enty to my parent pom -- but is that really needed? Thanks, Oren Mick Knutson wrote: If you are importing, in the pom form entry, you need to add something like: https://dev.ruready.utah.edu/svn/ruready/trunk/applications/ruready/pom.xml
Maven-antrun-plugin ignores tasks attributes
Hi all
My maven-antrun-plugin (version 1.1) ignores tasks attributes.
This exaple does not work
http://maven.apache.org/plugins/maven-antrun-plugin/examples/tasksAttributes.html
I have tried many combinations using
tasks unless=maven.test.skip
tasks if=maven.test.skip
tasks unless=${maven.test.skip}
tasks if=${maven.test.skip}
another phases, etc.
but the plugin ignores all the attributes of tasks section.
Does anybody has the same problem?
How can I solve it?
Thanks.
--
View this message in context:
http://www.nabble.com/Maven-antrun-plugin-ignores-%3Ctasks%3E-attributes-tp14432424s177p14432424.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: Maven-antrun-plugin ignores tasks attributes
Solved :)
This in new feature, it is implemented in version 1.2-SNAPSHOT.
When new version of plugin will be available on
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-antrun-plugin/
?
vetalok wrote:
Hi all
My maven-antrun-plugin (version 1.1) ignores tasks attributes.
This exaple does not work
http://maven.apache.org/plugins/maven-antrun-plugin/examples/tasksAttributes.html
I have tried many combinations using
tasks unless=maven.test.skip
tasks if=maven.test.skip
tasks unless=${maven.test.skip}
tasks if=${maven.test.skip}
another phases, etc.
but the plugin ignores all the attributes of tasks section.
Does anybody has the same problem?
How can I solve it?
Thanks.
--
View this message in context:
http://www.nabble.com/Maven-antrun-plugin-ignores-%3Ctasks%3E-attributes-tp14432424s177p14432835.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: How to deploy corporate-pom?
this would be perfect, because now i did how it was recommended, but: 1. modified the parent trunk to snapshot. 2. did a release of the company pom. Released highest version is now 1.1 3. modified the first child in the chain: parent groupIdeds/groupId artifactIdeds/artifactId versionLATEST/version --- changed, LASTEST is 1.1 (currently highest version number of parent) /parent modelVersion4.0.0/modelVersion groupIdeds.tweb/groupId artifactIdtweb/artifactId packagingpom/packaging version1.1-SNAPSHOT/version nametweb/name 4. install/deploy or release-prepare are all failing with following error: [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: eds.tweb:tweb:pom:1.1-SNAPSHOT Reason: Cannot find parent: eds:eds for project: eds.tweb:tweb:pom:1.1-SNAPSHOT for project eds.tweb:tweb:pom:1.1-SNAPSHOT In this case i would expect that it would take version 1.1 of the parent pom. brgds Dominique -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 11:21 PM To: Maven Users List Subject: Re: How to deploy corporate-pom? I was also thinking, that you could write a custom rule for the enforcer plugin, which checks that the topmost parent is the latest in the available repositories. Maybe I will write it tomorrow, if you are interested. Hth, Nick Stolwijk [EMAIL PROTECTED] wrote: Couldn't you put the version of the parent (corporate-pom) to LATEST instead of a version number. AFAIK, when you do a release it is changed into the current latest version. So tags won't change when you update your corporate pom. Hth, Nick Stolwijk -Original Message- From: Boeckli, Dominique [mailto:[EMAIL PROTECTED] Sent: Wed 12/19/2007 5:04 PM To: Maven Users List Subject: RE: How to deploy corporate-pom? the problem is that things get forgotten: Assuming i start working on Project Y and i forget to check if there's a new company pom. After a few changes in my code in this project, it is builded on wrong dependencies succesfully and deployed on the test server. Deployment failes and i spent a lot of time debugging it, searching the problem in my own code. Half of the other developers doing the same error, loosing a lot of time. The script you mentioned is a solution for this problem. Does anybody have such a script? P.S. removing stuff from their local repo was not really another problem, it is only a other way to handle the same problem. In this way i don't use any snapshot version, i work and edit directly on released versions (eg 1.0). When i think the company pom is ok, i deploy it and advice my collegues to delete this versions from their local repo. In this way, they are forced to get the new parent from the intranet repo. The point is, that the version allway remains the same for the company pom. This way is ugly but it causes not more work and problems than the official way. I am not happy with it, neither, and this is the reason why i ask here around what other people are doing. brgds Dominique -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 04:16 PM To: Maven Users List; Maven Users List Subject: RE: How to deploy corporate-pom? I thought the problem was with developers having to remove stuff from their local repository. Now you present another problem. In my vision, they should certainly not change automatically. At least not the tags, then you can have two builds of the same tag with different parent information, based on when it's build. So should they change all, then you could write a script which replaced it in the trunks and branches. Or should they only change, when the projects get alive again. I guess you can compare it to mavens own corporate pom. There are a few versions of that, and plugins, modules and projects only update, when they think it is necessary and when it is completely tested. The parent of project is also a dependency, which after changing, should be tested whether it broke anything or not. So let me rephrase it, why would you want to change projects nobody is working on? Maybe it is easier to have it as one of the steps when reviving a project. Check whether the parent should be updated and test it if has to. Hth, Nick Stolwijk -Original Message- From: Boeckli, Dominique [mailto:[EMAIL PROTECTED] Sent: Wed 12/19/2007 4:05 PM To: Maven Users List Subject: RE: How to deploy corporate-pom? yes, i understand, but good-way-example is based on 2 projects. But, my example is the following: Project A same. Project B same. no comes the difference 200 more projects, currently nobody working on it, some were
Re: Maven 1.1 + tomcat plugin
Hi, [EMAIL PROTECTED] wrote: Hi, I just updated from Maven 1.0.2 to Maven 1.1. In Maven 1.02 I used the tomcat plugin from codezar: maven-tomcat-plugin-1.1.jar. Using Maven 1.1, I typed in: maven tomcat:deploy This gave me the error: --- Error parsing project.xml 'MAVEN-HOME\cache\maven-tomcat-plugin-1.1\project.xml' ParseError at [row,col]:[44,11] Message: Unrecognised tag: 'id' As noted on the compat page (http://maven.apache.org/maven-1.x/reference/backwards-compatibility.html), Maven 1.1 is much less tolerant of invalid project.xml files, so this plugin seems to be broken in m11. --- So I went to the codezar website and updated the maven dependency to version 1.2. However, now, when calling maven tomcat:deploy --- Where did you get this plugin version? The link we have on our plugins page (http://www.codeczar.com/products/maven-tomcat-plugin/) is not valid anymore. Unable to obtain goal [tomcat:_jspc] org.apache.jasper.JasperException: file:MY-SOURCE-FOLDER/MY_JSP_FILE.jsp(1,1) The absolute uri: http ://jakarta.apache.org/struts/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application file:MY-SOURCE- FOLDER/MY_JSP_FILE.jsp(1,1) The absolute uri:http://jakarta.apache.org/ struts/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application --- BUILD FAILED Can't help you with this one (at least they fixed the plugin pom... :) ), but a quick google search suggests that it's a more general problem, not maven related. The file it complains about just contains the tag library definitions: %@ taglib prefix=tiles uri=http://jakarta.apache.org/struts/tags-tiles; % %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % %@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; % %@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; % The URI http://jakarta.apache.org/struts/tags-tiles doesn't exist anymore, have they moved somewhere else? I did some research on Google, and found out this error could have something to do with servlet api 2.3 vs 2.4 - however as far as I know I am using 2.4 in my web.xml. Any ideas what's wrong, and what I could do to fix it? (I am not allowed to move to Maven2, and I was told it wasn't so good anyway) Damn right! :p Cheers, -Lukas Thanks in advance, Christine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1 + tomcat plugin
Hi Lukas, Now I changed to the latest (and last) version of the codeczar tomcat plugin, maven-tomcat-plugin.1.2.1.jar, which I got from this url: http://www.codeczar.com/maven/codeczar-tomcat/plugins/maven-tomcat-plugin-1.2.1.jar I've read here: http://masterdev.dyndns.dk/dev/14.html That in order to properly use it, you had to update to Tomcat 5.5.12, which I also did. Now when calling maven tomcat:deploy It gives me this error: test:test: war:webapp: --- Unable to obtain goal [war:webapp] Error parsing project.xml 'MY_MAVEN_HOME\cache\maven-java-plugin-1.6.1\project.xml' com.bea.xml.stream.MXParserFactory --- BUILD FAILED --- This is all really weird, plz help. Thanks in advance, Christine Original-Nachricht Datum: Thu, 20 Dec 2007 10:48:07 +0100 Von: Lukas Theussl [EMAIL PROTECTED] An: Maven Users List users@maven.apache.org Betreff: Re: Maven 1.1 + tomcat plugin Hi, [EMAIL PROTECTED] wrote: Hi, I just updated from Maven 1.0.2 to Maven 1.1. In Maven 1.02 I used the tomcat plugin from codezar: maven-tomcat-plugin-1.1.jar. Using Maven 1.1, I typed in: maven tomcat:deploy This gave me the error: --- Error parsing project.xml 'MAVEN-HOME\cache\maven-tomcat-plugin-1.1\project.xml' ParseError at [row,col]:[44,11] Message: Unrecognised tag: 'id' As noted on the compat page (http://maven.apache.org/maven-1.x/reference/backwards-compatibility.html), Maven 1.1 is much less tolerant of invalid project.xml files, so this plugin seems to be broken in m11. --- So I went to the codezar website and updated the maven dependency to version 1.2. However, now, when calling maven tomcat:deploy --- Where did you get this plugin version? The link we have on our plugins page (http://www.codeczar.com/products/maven-tomcat-plugin/) is not valid anymore. Unable to obtain goal [tomcat:_jspc] org.apache.jasper.JasperException: file:MY-SOURCE-FOLDER/MY_JSP_FILE.jsp(1,1) The absolute uri: http ://jakarta.apache.org/struts/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application file:MY-SOURCE- FOLDER/MY_JSP_FILE.jsp(1,1) The absolute uri:http://jakarta.apache.org/ struts/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application --- BUILD FAILED Can't help you with this one (at least they fixed the plugin pom... :) ), but a quick google search suggests that it's a more general problem, not maven related. The file it complains about just contains the tag library definitions: %@ taglib prefix=tiles uri=http://jakarta.apache.org/struts/tags-tiles; % %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % %@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; % %@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; % The URI http://jakarta.apache.org/struts/tags-tiles doesn't exist anymore, have they moved somewhere else? I did some research on Google, and found out this error could have something to do with servlet api 2.3 vs 2.4 - however as far as I know I am using 2.4 in my web.xml. Any ideas what's wrong, and what I could do to fix it? (I am not allowed to move to Maven2, and I was told it wasn't so good anyway) Damn right! :p Cheers, -Lukas Thanks in advance, Christine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1 + tomcat plugin
Try running with -e to get more info, the error message seems misleading. Also try to clear your local cache, that sometimes helps. Can you run the war:webapp goal by itself? -Lukas [EMAIL PROTECTED] wrote: Hi Lukas, Now I changed to the latest (and last) version of the codeczar tomcat plugin, maven-tomcat-plugin.1.2.1.jar, which I got from this url: http://www.codeczar.com/maven/codeczar-tomcat/plugins/maven-tomcat-plugin-1.2.1.jar I've read here: http://masterdev.dyndns.dk/dev/14.html That in order to properly use it, you had to update to Tomcat 5.5.12, which I also did. Now when calling maven tomcat:deploy It gives me this error: test:test: war:webapp: --- Unable to obtain goal [war:webapp] Error parsing project.xml 'MY_MAVEN_HOME\cache\maven-java-plugin-1.6.1\project.xml' com.bea.xml.stream.MXParserFactory --- BUILD FAILED --- This is all really weird, plz help. Thanks in advance, Christine Original-Nachricht Datum: Thu, 20 Dec 2007 10:48:07 +0100 Von: Lukas Theussl [EMAIL PROTECTED] An: Maven Users List users@maven.apache.org Betreff: Re: Maven 1.1 + tomcat plugin Hi, [EMAIL PROTECTED] wrote: Hi, I just updated from Maven 1.0.2 to Maven 1.1. In Maven 1.02 I used the tomcat plugin from codezar: maven-tomcat-plugin-1.1.jar. Using Maven 1.1, I typed in: maven tomcat:deploy This gave me the error: --- Error parsing project.xml 'MAVEN-HOME\cache\maven-tomcat-plugin-1.1\project.xml' ParseError at [row,col]:[44,11] Message: Unrecognised tag: 'id' As noted on the compat page (http://maven.apache.org/maven-1.x/reference/backwards-compatibility.html), Maven 1.1 is much less tolerant of invalid project.xml files, so this plugin seems to be broken in m11. --- So I went to the codezar website and updated the maven dependency to version 1.2. However, now, when calling maven tomcat:deploy --- Where did you get this plugin version? The link we have on our plugins page (http://www.codeczar.com/products/maven-tomcat-plugin/) is not valid anymore. Unable to obtain goal [tomcat:_jspc] org.apache.jasper.JasperException: file:MY-SOURCE-FOLDER/MY_JSP_FILE.jsp(1,1) The absolute uri: http ://jakarta.apache.org/struts/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application file:MY-SOURCE- FOLDER/MY_JSP_FILE.jsp(1,1) The absolute uri:http://jakarta.apache.org/ struts/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application --- BUILD FAILED Can't help you with this one (at least they fixed the plugin pom... :) ), but a quick google search suggests that it's a more general problem, not maven related. The file it complains about just contains the tag library definitions: %@ taglib prefix=tiles uri=http://jakarta.apache.org/struts/tags-tiles; % %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % %@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; % %@ taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions; % The URI http://jakarta.apache.org/struts/tags-tiles doesn't exist anymore, have they moved somewhere else? I did some research on Google, and found out this error could have something to do with servlet api 2.3 vs 2.4 - however as far as I know I am using 2.4 in my web.xml. Any ideas what's wrong, and what I could do to fix it? (I am not allowed to move to Maven2, and I was told it wasn't so good anyway) Damn right! :p Cheers, -Lukas Thanks in advance, Christine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generated sources convention
Hi, Use the *build* *helper* *plugin* to add additional source paths http://mojo.codehaus.org/*build*-*helper*-maven-*plugin*/http://mojo.codehaus.org/build-helper-maven-plugin/ cf. http://www.nabble.com/Second-source-directory-for-generated-code-to6446457s177.html#a6446995 Rémy
Re: generated sources convention
Thanks guys. I've already got it working with the build helper plugin, but was hoping there was some convention i could use to avoid it. Hopefully the maven guys move to add one eventually. On Dec 20, 2007 8:15 AM, Rémy Sanlaville [EMAIL PROTECTED] wrote: Hi, Use the *build* *helper* *plugin* to add additional source paths http://mojo.codehaus.org/*build*-*helper*-maven-*plugin*/ http://mojo.codehaus.org/build-helper-maven-plugin/ cf. http://www.nabble.com/Second-source-directory-for-generated-code-to6446457s177.html#a6446995 Rémy
Re: generated sources convention
The convention is useful for the IDE integration that can check that target/generated-sources subfolders and add them to source path without actually requiring to build the project. Milos On Dec 20, 2007 2:43 PM, Kallin Nagelberg [EMAIL PROTECTED] wrote: Thanks guys. I've already got it working with the build helper plugin, but was hoping there was some convention i could use to avoid it. Hopefully the maven guys move to add one eventually. On Dec 20, 2007 8:15 AM, Rémy Sanlaville [EMAIL PROTECTED] wrote: Hi, Use the *build* *helper* *plugin* to add additional source paths http://mojo.codehaus.org/*build*-*helper*-maven-*plugin*/ http://mojo.codehaus.org/build-helper-maven-plugin/ cf. http://www.nabble.com/Second-source-directory-for-generated-code-to6446457s177.html#a6446995 Rémy
Re: Unit test strategy for testing a java.io.File in maven2?
Thanks for the info about basedir property, I was not sure of this. REgards, -- Arnaud Bailly, PhD OQube - Software Engineering http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generated sources convention
The eclipse plugin (not sure other IDE-plugins do same) will run a pre-build (generate-resources phase) to let all code-generator declare compileSourceRoots. This also aplies to maven-helper-plugin. Based on this you MAY use whatever generate folder you like. The convention is to use target/generated-sources/generator-name, as it was required with maven1 IDE plugins to detect generated source folders. Nico. 2007/12/20, Milos Kleint [EMAIL PROTECTED]: The convention is useful for the IDE integration that can check that target/generated-sources subfolders and add them to source path without actually requiring to build the project. Milos On Dec 20, 2007 2:43 PM, Kallin Nagelberg [EMAIL PROTECTED] wrote: Thanks guys. I've already got it working with the build helper plugin, but was hoping there was some convention i could use to avoid it. Hopefully the maven guys move to add one eventually. On Dec 20, 2007 8:15 AM, Rémy Sanlaville [EMAIL PROTECTED] wrote: Hi, Use the *build* *helper* *plugin* to add additional source paths http://mojo.codehaus.org/*build*-*helper*-maven-*plugin*/ http://mojo.codehaus.org/build-helper-maven-plugin/ cf. http://www.nabble.com/Second-source-directory-for-generated-code-to6446457s177.html#a6446995 Rémy
maven-eclipse-plugin in online mode with downloadSources=true
Hi, Does anyone use maven-eclipse:plugin, mvn eclipse:eclipse in online mode with downloadSources=true ? In offline, it takes about 1min30; online, with downloadSources=true, it takes several hours (when it finishes, as archiva often freeze on too long tasks) ! I have this configuration in the parent pom.xml : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.4/version configuration downloadSourcestrue/downloadSources /configuration /plugin If this can be a workaround, is it possible to store the sources' status cache, outside the target dir ? Enables/disables the downloading of source attachments. Defaults to false. When this flag is |true| remote repositories are checked for sources: in order to avoid repeated check for unavailable source archives, a status cache is mantained into the target dir of the root project. Run |mvn:clean| or delete the file |mvn-eclipse-cache.properties| in order to reset this cache. -- Julien CARSIQUE, Nuxeo (Paris, France) Open Source Enterprise Content Management - http://www.nuxeo.org/ Nuxeo EP 5: extensible, Java EE and standards based ECM Platform http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
Re: generated sources convention
at least the netbeans ide plugin will not run any phases when opening a project. it relies solely on the convention. Ideally the plugin description would include a marker on mojo parameters that make a generated source root directory. That way one can check the actual location without running the build. Milos On Dec 20, 2007 3:14 PM, nicolas de loof [EMAIL PROTECTED] wrote: The eclipse plugin (not sure other IDE-plugins do same) will run a pre-build (generate-resources phase) to let all code-generator declare compileSourceRoots. This also aplies to maven-helper-plugin. Based on this you MAY use whatever generate folder you like. The convention is to use target/generated-sources/generator-name, as it was required with maven1 IDE plugins to detect generated source folders. Nico. 2007/12/20, Milos Kleint [EMAIL PROTECTED]: The convention is useful for the IDE integration that can check that target/generated-sources subfolders and add them to source path without actually requiring to build the project. Milos On Dec 20, 2007 2:43 PM, Kallin Nagelberg [EMAIL PROTECTED] wrote: Thanks guys. I've already got it working with the build helper plugin, but was hoping there was some convention i could use to avoid it. Hopefully the maven guys move to add one eventually. On Dec 20, 2007 8:15 AM, Rémy Sanlaville [EMAIL PROTECTED] wrote: Hi, Use the *build* *helper* *plugin* to add additional source paths http://mojo.codehaus.org/*build*-*helper*-maven-*plugin*/ http://mojo.codehaus.org/build-helper-maven-plugin/ cf. http://www.nabble.com/Second-source-directory-for-generated-code-to6446457s177.html#a6446995 Rémy
Re: Maven2 strange issue
Hi Trasca, is it possible that maven was searching for plugin updates? By policy this is done after a certain interval. AFAIK maven checks every week for updates. Cheers Francois am Donnerstag, 20. Dezember 2007 um 06:39 schrieben Sie: Hi, I have a new build with maven2 which used to work correctly and quick. But today when I did the sample compile which worked so many times maven2 started to go to repositories and download all kind of dependencies which I never heard about and stayed so much time that I got bored waiting. What is different from when it was working correctly is that I added build.xml near pom.xml(as I want also ant build) , I added a dist folder(for the output of ant) and I added a lib folder( for keeping jar dependencies needed by ant). But I don't see why this should change maven2 behavior. new maven2 build took 24 minutes and a lot ofs strange downloads but used to take only 8 seconds!!. I am doing something wrong? Thank you, Virgil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shared dependencies deployment to Tomcat 5.5 or 6.0 + other servers
Hi all, I am in the process of converting a rather complex project from Maven 1 to Maven 2, and despite my best attempts at googling for these answers, I have only been able to go so far. I've also been looking at some projects, like Jetspeed 2, that seems to be doing some rather advanced stuff with Maven 2. Anyway, in our existing Maven 1 project, we use Jelly scripts to perform deployment of common resources to our Tomcat server. The problem is that Tomcat has been moving around things in the latest versions, and deployment of common resources is different between Tomcat 5.5 and 6. In Tomcat 5.5 we would copy the required dependencies manually to tomcat/shared/lib, but I didn't really think this was the cleanest way of doing this. As I am re-organizing our project structure for Maven 2, I was building a common sub-project with all the dependencies, which is cleaner than what we use to do, but I know have no idea how best to deploy these, especially based on the different locations for different Tomcat versions. Should I use the tomcat-maven-plugin ? Should I use Cargo ? Which one of the two has the biggest community ? If I should build my own Mojo, is there a recommended way to build deployment plugins, using maybe profiles to make it as server independent as possible ? Lots of questions as you can see :) I really hope someone out there can help, because I can't believe I'm the only one having this issue :) cheers, Serge...
Re: generated sources convention
I'm working on such a mojo API extension (or anything else) to fix this issue with the eclipse plugin. @see my post on [EMAIL PROTECTED] Nico. 2007/12/20, Milos Kleint [EMAIL PROTECTED]: at least the netbeans ide plugin will not run any phases when opening a project. it relies solely on the convention. Ideally the plugin description would include a marker on mojo parameters that make a generated source root directory. That way one can check the actual location without running the build. Milos On Dec 20, 2007 3:14 PM, nicolas de loof [EMAIL PROTECTED] wrote: The eclipse plugin (not sure other IDE-plugins do same) will run a pre-build (generate-resources phase) to let all code-generator declare compileSourceRoots. This also aplies to maven-helper-plugin. Based on this you MAY use whatever generate folder you like. The convention is to use target/generated-sources/generator-name, as it was required with maven1 IDE plugins to detect generated source folders. Nico. 2007/12/20, Milos Kleint [EMAIL PROTECTED]: The convention is useful for the IDE integration that can check that target/generated-sources subfolders and add them to source path without actually requiring to build the project. Milos On Dec 20, 2007 2:43 PM, Kallin Nagelberg [EMAIL PROTECTED] wrote: Thanks guys. I've already got it working with the build helper plugin, but was hoping there was some convention i could use to avoid it. Hopefully the maven guys move to add one eventually. On Dec 20, 2007 8:15 AM, Rémy Sanlaville [EMAIL PROTECTED] wrote: Hi, Use the *build* *helper* *plugin* to add additional source paths http://mojo.codehaus.org/*build*-*helper*-maven-*plugin*/ http://mojo.codehaus.org/build-helper-maven-plugin/ cf. http://www.nabble.com/Second-source-directory-for-generated-code-to6446457s177.html#a6446995 Rémy
Shared dependencies deployment to Tomcat 5.5 or 6.0 + other servers
Hi all, I am in the process of converting a rather complex project from Maven 1 to Maven 2, and despite my best attempts at googling for these answers, I have only been able to go so far. I've also been looking at some projects, like Jetspeed 2, that seems to be doing some rather advanced stuff with Maven 2. Anyway, in our existing Maven 1 project, we use Jelly scripts to perform deployment of common resources to our Tomcat server. The problem is that Tomcat has been moving around things in the latest versions, and deployment of common resources is different between Tomcat 5.5 and 6. In Tomcat 5.5 we would copy the required dependencies manually to tomcat/shared/lib, but I didn't really think this was the cleanest way of doing this. As I am re-organizing our project structure for Maven 2, I was building a common sub-project with all the dependencies, which is cleaner than what we use to do, but I know have no idea how best to deploy these, especially based on the different locations for different Tomcat versions. Should I use the tomcat-maven-plugin ? Should I use Cargo ? Which one of the two has the biggest community ? If I should build my own Mojo, is there a recommended way to build deployment plugins, using maybe profiles to make it as server independent as possible ? Lots of questions as you can see :) I really hope someone out there can help, because I can't believe I'm the only one having this issue :) cheers, Serge...
Re: Maven 1.1 + tomcat plugin
Try running with -e to get more info, the error message seems misleading. Also try to clear your local cache, that sometimes helps. Can you run the war:webapp goal by itself? -Lukas Ok, now I found out, it must be the precompile goal - When I edit my project.properties file and set: maven.tomcat.jsp.precompile=false Everything works fine. But when I set: maven.tomcat.jsp.precompile=true It does not. To track down the error, I just started the jspc goal: maven -e tomcat:jspc Which results in: build:start: war:init: tomcat:init: [echo] Found context file C:\MYFOLDER\MYPROJECT\trunk/src/war/META-IN F/context.xml [echo] found / in context file war:war-resources: [copy] Copying 265 files to C:\MYFOLDER\MYPROJECT\trunk\target\MYPROJECT [copy] Copying 1 file to C:\MYFOLDER\MYPROJECT\trunk\target\MYPROJECT tomcat:_jspc: [echo] excluding jsps [delete] Deleting 43 files from C:\MYFOLDER\MYPROJECT\trunk\target\ info11-MYPROJECT test:test: war:webapp: --- Errors stack : Unable to obtain goal [war:webapp] File.. file:/C:/MYFOLDER/Maven1.1/cache/maven-war-plugin-1.6.3/plugin.jelly Element... attainGoal Line.. 202 Column 42 Error parsing project.xml 'C:\MYFOLDER\Maven1.1\cache\maven-java-plugin-1.6.1\pro ject.xml' com.bea.xml.stream.MXParserFactory Exception stack traces : org.apache.maven.werkz.UnattainableGoalException: Unable to obtain goal [war:web app] at org.apache.maven.werkz.Goal.fire(Goal.java:698) at org.apache.maven.werkz.Goal.attain(Goal.java:623) at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:526) at org.apache.maven.werkz.Goal.attain(Goal.java:621) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 712) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:265) at org.apache.maven.cli.App.doMain(App.java:307) at org.apache.maven.cli.App.main(App.java:217) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: org.apache.commons.jelly.JellyTagException: file:/C:/MYFOLDER/Maven1.1/ca che/maven-war-plugin-1.6.3/plugin.jelly:202:42: attainGoal Error parsing proje ct.xml 'C:\MYFOLDER\Maven1.1\cache\maven-java-plugin-1.6.1\project.xml' at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttai nGoalTag.java:113) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:42) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa g.java:83) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor mAction(MavenGoalTag.java:116) at org.apache.maven.werkz.Goal.fire(Goal.java:691) ... 13 more Caused by: org.apache.maven.MavenException: Error parsing project.xml 'C:\MYFOLDER\M aven1.1\cache\maven-java-plugin-1.6.1\project.xml' at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:202) at org.apache.maven.MavenUtils.getProject(MavenUtils.java:129) at org.apache.maven.plugin.JellyScriptHousing.getProject(JellyScriptHous ing.java:108) at org.apache.maven.plugin.PluginManager.initialiseHousingPluginContext( PluginManager.java:775) at org.apache.maven.plugin.PluginManager.prepAttainGoal(PluginManager.ja va:767) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttai nGoalTag.java:109) ... 22 more Caused by: java.lang.ClassCastException: com.bea.xml.stream.MXParserFactory at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136 ) at org.apache.maven.project.io.stax.MavenStaxReader.read(MavenStaxReader .java:2321) at org.apache.maven.project.io.stax.MavenStaxReader.read(MavenStaxReader .java:2337) at org.apache.maven.project.Project.init(Project.java:152) at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:198) ... 27 more --- BUILD FAILED --- On the page:
Re: maven2 and jboss wsconsume -- examples?
jsolderitsch wrote: jsolderitsch wrote: I am looking for some directions, or some example pom text, to show how the jboss wsconsume operation can be integrated into a maven2 workflow. wsconsume will generate Java code based on a wsdl spec. For example, one of our developers uses the following in a Windows bat file to execute this step: set JBOSS_HOME=C:\jboss-4.2.2.GA %JBOSS_HOME%\bin\wsconsume -v -k -p com.gestalt.sgs.sgsdif -w WEB-INF/wsdl/uob.wsdl -s src/main/java -o target/classes src/main/webapp/WEB-INF/wsdl/uob.wsdl I am looking for an example of how to wrap this (or the equivalent ant-based method) into the pom as part of the ear generation workflow. I did some searching on this forum and didn't find anything directly relevant. I hope this is easy and I am just ignorant of some maven basics. Related to this -- what is the relationship of wsimport to wsconsume? There is a JAXWS maven plugin that has wsimport support: https://jax-ws-commons.dev.java.net/jaxws-maven-plugin/usage.html Anyone have experience comparing say what JBoss' wsconsume tool does vs. wsimport? OK, now things are getting weird. I am trying to run the jaxws maven plugin that I found at the above site. I get Bad version number in .class file errors as documented at: http://forums.java.net/jive/thread.jspa?threadID=34567tstart=0 I have a wsdl file that works with wsconsume that I moved into the right directory structure (I thought) for wsimport. Update a colleague informs me that setting a specific version for the plugin (1.8) makes this error go away But this might be useful info for some of us -- View this message in context: http://www.nabble.com/maven2-and-jboss-wsconsumeexamples--tp14421784s177p14438454.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]
TestListeners with Surefire
TestNG has the concept of a TestListener that gets notified
before/after each test run. JUnit has the same thing I believe.
(http://testng.org/javadocs/org/testng/TestNG.html)
I have tried everything I could to pass the listener class into
Surefire to no avail. I tried
* adding listener property in my profile
* adding entry to surefire plugin config
* adding -Dlistener=Foo when running Maven
None of these work as of Surefire 2.4. I checked out the Surefire
sourcecode and found this code:
TestNGExecutor.java
public static void run( List suiteFiles, String testSourceDirectory,
Map options, ArtifactVersion version,
String classifier, ReporterManager
reportManager, SurefireTestSuite suite, File reportsDirectory )
throws TestSetFailedException
{
TestNG testng = new TestNG( false );
Configurator configurator = getConfigurator( version );
configurator.configure( testng, options );
postConfigure( testng, testSourceDirectory, (String)
options.get(listener), classifier, reportManager, suite,
reportsDirectory );
testng.setTestSuites( suiteFiles );
testng.run();
}
TestNGExecutor looks for a listener entry in the options map (which
then actually attaches the listener further on) but from what I can
tell, the class that calls the executor, SurefirePlugin.java, never
puts that key in the map:
http://svn.apache.org/viewvc/maven/surefire/trunk/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java?revision=605713view=markup
Look specifically at #convertTestNGParameters()
Is this a bug? Or has anyone ever configured a TestNG TestListener
class through Surefire?
Thanks,
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coverage report of web application integration test with cobertura-maven-plugin
Hi guys, Any more news on this? This is a really important feature. We've been battling on this one for a week ate work. Any workarrounds, any news? Thanks, On Dec 13, 2007 3:34 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Thus you'll have my help ;-) On Dec 13, 2007 4:29 PM, Jeff MAURY [EMAIL PROTECTED] wrote: I would prefer extending the current one. Jeff On Dec 13, 2007 4:26 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: another cobertura plugin or an extension of the current one ? otherwise you have my +1 to have the possibility to include integration tests in reports Arnaud On Dec 13, 2007 3:58 PM, Jeff MAURY [EMAIL PROTECTED] wrote: Richard, I have the same problem and I think this is not feasible with the current design of the Cobertura Maven2 plugin design as it is today. It does only address the test phase and not the integration-test phase. I plan to work on another Cobertura plugin (inspired from the philosophy of the Clover plugin) that address this issue. Jeff On Dec 13, 2007 3:29 PM, Brewster, Richard [EMAIL PROTECTED] wrote: I want to produce a coverage report for the integration test phase of a web application (war packaging). My integration tests are run by the Cargo maven plugin launching JBoss 4.0.5. I've been using the 2.0 version of the cobertura-maven-plugin (and will try the upgrade to 2.2 ). I have a modular project with core and web modules. I get the expected coverage reports for my core module, but zero coverage for the web module. The instrumented classes are not packaged into the war, for one. According to the Cobertura FAQ, this sort of coverage testing can be done. http://cobertura.sourceforge.net/faq.html Has anyone done this? Any advice would be appreciated! Also, it would be great if integration test coverage could be documented here, too: http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Thanks, Richard Brewster Senior Associate Perrin Quarles Associates [EMAIL PROTECTED] (434) 817-2640 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- Pedro Viegas Walking on water and developing software from a specification are easy if both are frozen. - Edward V. Berard
2.1 download possible?
I cannot use maven 2.0.8 due to blocker issue http://jira.codehaus.org/browse/MNG-2258. I am running on JDK 1.6 and have SQL plugin executions in my pom. Under JDK 1.6, they run out of order since the code uses Maps instead of lists or a linked list map. My code doesn't compile on JDK 1.5 and some of my build goals fail under JDK 1.6. So I am stuck without being able to use maven right now. Can MNG-2258 be back-ported for a 2.0.8.1 release, or will 2.1 be out soon (meaning in the next week or so)? If no to both of these questions, what is the best way to download, or at least produce a 2.1 snapshot release? I am able to build https://svn.apache.org/repos/asf/maven/components/trunk fine, but that does not give me a runnable mvn command. Is there a WIKI for making a 2.1 release that I missed? Thanks, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 download possible?
Does this help you: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html ? On Dec 20, 2007 7:50 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I cannot use maven 2.0.8 due to blocker issue http://jira.codehaus.org/browse/MNG-2258. I am running on JDK 1.6 and have SQL plugin executions in my pom. Under JDK 1.6, they run out of order since the code uses Maps instead of lists or a linked list map. My code doesn't compile on JDK 1.5 and some of my build goals fail under JDK 1.6. So I am stuck without being able to use maven right now. Can MNG-2258 be back-ported for a 2.0.8.1 release, or will 2.1 be out soon (meaning in the next week or so)? If no to both of these questions, what is the best way to download, or at least produce a 2.1 snapshot release? I am able to build https://svn.apache.org/repos/asf/maven/components/trunk fine, but that does not give me a runnable mvn command. Is there a WIKI for making a 2.1 release that I missed? Thanks, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coverage report of web application integration test with cobertura-maven-plugin
Hello, I have extended the corbertura-maven-plugin in order to do that but I'm facing an issue with the cargo plugin: my cobertura plugin will not generate a new artifact with a specific classifier (like the clover plugin) but when the cargo plugin starts a container, it will deploy both artifacts, the original one and the one generated with corbertura. I need to continue working on it in order to find a solution. Jeff On Dec 20, 2007 7:41 PM, Pedro Viegas [EMAIL PROTECTED] wrote: Hi guys, Any more news on this? This is a really important feature. We've been battling on this one for a week ate work. Any workarrounds, any news? Thanks, On Dec 13, 2007 3:34 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Thus you'll have my help ;-) On Dec 13, 2007 4:29 PM, Jeff MAURY [EMAIL PROTECTED] wrote: I would prefer extending the current one. Jeff On Dec 13, 2007 4:26 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: another cobertura plugin or an extension of the current one ? otherwise you have my +1 to have the possibility to include integration tests in reports Arnaud On Dec 13, 2007 3:58 PM, Jeff MAURY [EMAIL PROTECTED] wrote: Richard, I have the same problem and I think this is not feasible with the current design of the Cobertura Maven2 plugin design as it is today. It does only address the test phase and not the integration-test phase. I plan to work on another Cobertura plugin (inspired from the philosophy of the Clover plugin) that address this issue. Jeff On Dec 13, 2007 3:29 PM, Brewster, Richard [EMAIL PROTECTED] wrote: I want to produce a coverage report for the integration test phase of a web application (war packaging). My integration tests are run by the Cargo maven plugin launching JBoss 4.0.5. I've been using the 2.0 version of the cobertura-maven-plugin (and will try the upgrade to 2.2 ). I have a modular project with core and web modules. I get the expected coverage reports for my core module, but zero coverage for the web module. The instrumented classes are not packaged into the war, for one. According to the Cobertura FAQ, this sort of coverage testing can be done. http://cobertura.sourceforge.net/faq.html Has anyone done this? Any advice would be appreciated! Also, it would be great if integration test coverage could be documented here, too: http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Thanks, Richard Brewster Senior Associate Perrin Quarles Associates [EMAIL PROTECTED] (434) 817-2640 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- Pedro Viegas
Re: 2.1 download possible?
Yes it does, thank you. I'll just have to set it for the compiler and the surefire plugin. On Dec 20, 2007 12:25 PM, Tom Huybrechts [EMAIL PROTECTED] wrote: Does this help you: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html ? On Dec 20, 2007 7:50 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I cannot use maven 2.0.8 due to blocker issue http://jira.codehaus.org/browse/MNG-2258. I am running on JDK 1.6 and have SQL plugin executions in my pom. Under JDK 1.6, they run out of order since the code uses Maps instead of lists or a linked list map. My code doesn't compile on JDK 1.5 and some of my build goals fail under JDK 1.6. So I am stuck without being able to use maven right now. Can MNG-2258 be back-ported for a 2.0.8.1 release, or will 2.1 be out soon (meaning in the next week or so)? If no to both of these questions, what is the best way to download, or at least produce a 2.1 snapshot release? I am able to build https://svn.apache.org/repos/asf/maven/components/trunk fine, but that does not give me a runnable mvn command. Is there a WIKI for making a 2.1 release that I missed? Thanks, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 download possible?
Yes that worked. I also had to downgrade the maven-sql-plugin from psql jdbc4 to jdbc3 which isn't a problem Thanks again, Andrew On Dec 20, 2007 12:56 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Yes it does, thank you. I'll just have to set it for the compiler and the surefire plugin. On Dec 20, 2007 12:25 PM, Tom Huybrechts [EMAIL PROTECTED] wrote: Does this help you: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html ? On Dec 20, 2007 7:50 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I cannot use maven 2.0.8 due to blocker issue http://jira.codehaus.org/browse/MNG-2258. I am running on JDK 1.6 and have SQL plugin executions in my pom. Under JDK 1.6, they run out of order since the code uses Maps instead of lists or a linked list map. My code doesn't compile on JDK 1.5 and some of my build goals fail under JDK 1.6. So I am stuck without being able to use maven right now. Can MNG-2258 be back-ported for a 2.0.8.1 release, or will 2.1 be out soon (meaning in the next week or so)? If no to both of these questions, what is the best way to download, or at least produce a 2.1 snapshot release? I am able to build https://svn.apache.org/repos/asf/maven/components/trunk fine, but that does not give me a runnable mvn command. Is there a WIKI for making a 2.1 release that I missed? Thanks, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to deploy corporate-pom?
Step back a second and consider... Its 1 week before xmas, people are going away on holiday. A high profile project is in the final phases of testing and you discover a show stopper. You as the release manager go make the final release with the fix, but someone has released a new comporate pom that breaks your build... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Don't kill the messenger
Anybody saw this post? http://fishbowl.pastiche.org/ Unfortunately the author, Charles Miller [EMAIL PROTECTED], disabled the comments to prevent spam. Hmmm. Regards, Borut
Re: Problem to send email (Validation user) with Continuum 1.1 final
On 12/20/07, Claudio Ranieri [EMAIL PROTECTED] wrote: I looked for this file in Continuum 1.1 final, but I did´nt find security.properties in /path/to/continuum/conf/ Using grep I found the file security.properties in /path/to/continuum/apps/continuum/webapp/WEB-INF/classes/org/apache/maven/continuum/security.properties I added in this file this lines: You can create /path/to/continuum/conf/security.properties and put your changes there-- they should override the ones down in the webapp, and it will make upgrades easier. -- Wendy
RE: Don't kill the messenger
This must obviously be a guy who never had a build with more than one single module. So he never learned that it is NOT a good idea to keep all dependencies in every single module ;) Additionally this guy does not know about maven-proxy and the ability to backup all artifacts you need for the whole company. So for me, I can simply ignore his personal opinion :) LieGrü, strub --- Borut BolÄina [EMAIL PROTECTED] schrieb: Anybody saw this post? http://fishbowl.pastiche.org/ Unfortunately the author, Charles Miller [EMAIL PROTECTED], disabled the comments to prevent spam. Hmmm. Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Trying to work out where a snapshot caching problem is
Hi, I'm having a problem with Maven caching and snapshots. I am using Artifactory as a repository cache, which everybody is configured to use. If a release version is needed, everything is fetched into the users' local repository as expected. However the same is not happening with snapshots. I know the snapshots are there - I can see them, and if I do a manual copy out of Artifactory and place them in the local repository everything is fine. I'm not sure whether the problem is my Maven configuration, or an Artifactory configuration. Are there any diagnostics I can turn on to determine where the problem is? I've included the relevant bits of the (customised) settings.xml which everybody is using. This happens with Maven 2.0.7 and 2.0.8. Thanks, Ian settings servers server idartifactory.releases/id usernameadmin/username passwordpassword/password /server server idartifactory.snapshots/id usernameadmin/username passwordpassword/password /server /servers mirrors mirror idartifactory/id mirrorOf*/mirrorOf urlhttp://ebizci/artifactory/all//url nameArtifactory/name /mirror /mirrors profiles !-- Default profile, which should always be set -- profile iddefault/id !-- Need this repository until the dashboard plugin becomes ready for release -- pluginRepositories pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository /pluginRepositories /profile /profiles !-- activeProfiles | List of profiles that are active for all builds. |-- activeProfiles activeProfiledefault/activeProfile /activeProfiles /settings Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Privacy: If you are responding to this email or providing personal information to the SRO for the purposes of one of the Acts it administers, such information is used only for the purpose for which it was collected (administration of SRO legislation ) and is protected by the Information Privacy Act 2000 and secrecy provisions contained in legislation administered by SRO. It is not disclosed otherwise than in accordance with the law. If you would like a copy of the SRO Privacy Policy please refer to SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request a copy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Don't kill the messenger
I don't agree with most of the post, but he does have a point about resolving dependencies during every build. On one of my projects, I am using several snapshots due to needing bug fixes. I really wish I could turn off snapshot checking until I specifically ask for it to check. Like a maven.snapshot.skip flag. -Andrew On Dec 20, 2007 2:38 PM, Mark Struberg [EMAIL PROTECTED] wrote: This must obviously be a guy who never had a build with more than one single module. So he never learned that it is NOT a good idea to keep all dependencies in every single module ;) Additionally this guy does not know about maven-proxy and the ability to backup all artifacts you need for the whole company. So for me, I can simply ignore his personal opinion :) LieGrü, strub --- Borut BolÄ ina [EMAIL PROTECTED] schrieb: Anybody saw this post? http://fishbowl.pastiche.org/ Unfortunately the author, Charles Miller [EMAIL PROTECTED], disabled the comments to prevent spam. Hmmm. Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Don't kill the messenger
You could run -o (offline) and then leave it off when you want to check for snapshot updates. Wayne On 12/20/07, Andrew Robinson [EMAIL PROTECTED] wrote: I don't agree with most of the post, but he does have a point about resolving dependencies during every build. On one of my projects, I am using several snapshots due to needing bug fixes. I really wish I could turn off snapshot checking until I specifically ask for it to check. Like a maven.snapshot.skip flag. -Andrew On Dec 20, 2007 2:38 PM, Mark Struberg [EMAIL PROTECTED] wrote: This must obviously be a guy who never had a build with more than one single module. So he never learned that it is NOT a good idea to keep all dependencies in every single module ;) Additionally this guy does not know about maven-proxy and the ability to backup all artifacts you need for the whole company. So for me, I can simply ignore his personal opinion :) LieGrü, strub --- Borut BolÄ ina [EMAIL PROTECTED] schrieb: Anybody saw this post? http://fishbowl.pastiche.org/ Unfortunately the author, Charles Miller [EMAIL PROTECTED], disabled the comments to prevent spam. Hmmm. Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Trying to work out where a snapshot caching problem is
This is due to the snapshot update policy. By default maven will only update once a day you need to update the snapshot policy to 'always' or a more appropriate interval. Add this to the snapshot repo definition snapshotPolicyalways/snapshotPolicy Try this and see if it works for you. Rgds, ste -Original Message- From: Ian Rowlands [mailto:[EMAIL PROTECTED] Sent: Thursday, December 20, 2007 1:47 PM To: undisclosed-recipients Subject: Trying to work out where a snapshot caching problem is Hi, I'm having a problem with Maven caching and snapshots. I am using Artifactory as a repository cache, which everybody is configured to use. If a release version is needed, everything is fetched into the users' local repository as expected. However the same is not happening with snapshots. I know the snapshots are there - I can see them, and if I do a manual copy out of Artifactory and place them in the local repository everything is fine. I'm not sure whether the problem is my Maven configuration, or an Artifactory configuration. Are there any diagnostics I can turn on to determine where the problem is? I've included the relevant bits of the (customised) settings.xml which everybody is using. This happens with Maven 2.0.7 and 2.0.8. Thanks, Ian settings servers server idartifactory.releases/id usernameadmin/username passwordpassword/password /server server idartifactory.snapshots/id usernameadmin/username passwordpassword/password /server /servers mirrors mirror idartifactory/id mirrorOf*/mirrorOf urlhttp://ebizci/artifactory/all//url nameArtifactory/name /mirror /mirrors profiles !-- Default profile, which should always be set -- profile iddefault/id !-- Need this repository until the dashboard plugin becomes ready for release -- pluginRepositories pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository /pluginRepositories /profile /profiles !-- activeProfiles | List of profiles that are active for all builds. |-- activeProfiles activeProfiledefault/activeProfile /activeProfiles /settings Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Privacy: If you are responding to this email or providing personal information to the SRO for the purposes of one of the Acts it administers, such information is used only for the purpose for which it was collected (administration of SRO legislation ) and is protected by the Information Privacy Act 2000 and secrecy provisions contained in legislation administered by SRO. It is not disclosed otherwise than in accordance with the law. If you would like a copy of the SRO Privacy Policy please refer to SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request a copy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Don't kill the messenger
Or set it to never in the repository definition and then use -U to use it when you want. - Brett On 21/12/2007, Wayne Fay [EMAIL PROTECTED] wrote: You could run -o (offline) and then leave it off when you want to check for snapshot updates. Wayne On 12/20/07, Andrew Robinson [EMAIL PROTECTED] wrote: I don't agree with most of the post, but he does have a point about resolving dependencies during every build. On one of my projects, I am using several snapshots due to needing bug fixes. I really wish I could turn off snapshot checking until I specifically ask for it to check. Like a maven.snapshot.skip flag. -Andrew On Dec 20, 2007 2:38 PM, Mark Struberg [EMAIL PROTECTED] wrote: This must obviously be a guy who never had a build with more than one single module. So he never learned that it is NOT a good idea to keep all dependencies in every single module ;) Additionally this guy does not know about maven-proxy and the ability to backup all artifacts you need for the whole company. So for me, I can simply ignore his personal opinion :) LieGrü, strub --- Borut BolÄ ina [EMAIL PROTECTED] schrieb: Anybody saw this post? http://fishbowl.pastiche.org/ Unfortunately the author, Charles Miller [EMAIL PROTECTED], disabled the comments to prevent spam. Hmmm. Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Don't kill the messenger
Some points are really problematic with Maven. Every day the first usage of maven on each project is really slow. I would like some sort of improvement with this. What about adding the possibility to download commonly used plugins after installation (just a script...). What about preparing some scripts (that can be used as cronjob or at boot time) that resolve some dependencies in the background? Adding some intelligence should be possible. What about using several threads to look for library updates? What about setting shorter timeouts (ever tried to use maven if a repository is not available?) This are small improvements that don't change the internals or principles of maven but could improve my user experience a lot. Regards, Johannes Schneider Borut Bolčina wrote: Anybody saw this post? http://fishbowl.pastiche.org/ Unfortunately the author, Charles Miller [EMAIL PROTECTED], disabled the comments to prevent spam. Hmmm. Regards, Borut smime.p7s Description: S/MIME Cryptographic Signature
Re: Java EE 5 Archetypes?
Hi Stephen, Thanks for the help. :-) I did find a link off of that one to an archetype on java.net, but they had said that the archetype is still in progress. However, I did find a couple of blogs that have instructions on how to get going with a Java EE 5 project http://www.jaceklaskowski.pl/w/index.php?title=Tworzenie_aplikacji_Java_EE_5_z_Apache_Maven_2_i_Glassfish(in polish) http://technology.amis.nl/blog/?p=2489 Cheers, Jim On Dec 11, 2007 5:47 PM, Gargan, Stephen [EMAIL PROTECTED] wrote: You might find something useful (perhaps as the basis for your own archetype) on the list of maintained here, http://docs.codehaus.org/display/MAVENUSER/Archetypes+List rgds, ste -Original Message- From: Jim Bethancourt [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 8:18 AM To: users@maven.apache.org Subject: Java EE 5 Archetypes? Hello all, Does anyone know where I might be able to find a Maven 2 archetype for Java EE 5 to get my project off to a start? It would be very handy to have an archetype that provides structure for both the servlet container and EJB container. Thanks, Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Trying to work out where a snapshot caching problem is
Ian, it sounds like you have not configured Maven with the address of the snapshot repositories. I suspect you have just setup a mirror to point to the main repository in Artifactory (in which you are caching Apache, Codehaus etc). Its generally a good idea to keep release and snapshot artifacts separate in any case Don't forget to list the pluginRepository too. And don't foget to activate the profile, either in settings.xml (typical) or on the command line. Try adding something like the following to your settings.xml profile iddefault-repositories/id repositories repository idsnapshot/id nameSNAPSHOT Repository/name urlhttp://hubpc65:8080/artifactory/snapshot/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idsnapshot/id nameSNAPSHOT Repository/name urlhttp://hubpc65:8080/artifactory/snapshot/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled updatePolicyalways/updatePolicy /snapshots /pluginRepository /pluginRepositories /profile William -Original Message- From: Ian Rowlands [mailto:[EMAIL PROTECTED] Sent: Friday, 21 December 2007 7:47 AM To: undisclosed-recipients Subject: [***POSSIBLE SPAM***] - Trying to work out where a snapshot caching problem is - Sender is forged (SPF Fail) Hi, I'm having a problem with Maven caching and snapshots. I am using Artifactory as a repository cache, which everybody is configured to use. If a release version is needed, everything is fetched into the users' local repository as expected. However the same is not happening with snapshots. I know the snapshots are there - I can see them, and if I do a manual copy out of Artifactory and place them in the local repository everything is fine. I'm not sure whether the problem is my Maven configuration, or an Artifactory configuration. Are there any diagnostics I can turn on to determine where the problem is? I've included the relevant bits of the (customised) settings.xml which everybody is using. This happens with Maven 2.0.7 and 2.0.8. Thanks, Ian settings servers server idartifactory.releases/id usernameadmin/username passwordpassword/password /server server idartifactory.snapshots/id usernameadmin/username passwordpassword/password /server /servers mirrors mirror idartifactory/id mirrorOf*/mirrorOf urlhttp://ebizci/artifactory/all//url nameArtifactory/name /mirror /mirrors profiles !-- Default profile, which should always be set -- profile iddefault/id !-- Need this repository until the dashboard plugin becomes ready for release -- pluginRepositories pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository /pluginRepositories /profile /profiles !-- activeProfiles | List of profiles that are active for all builds. |-- activeProfiles activeProfiledefault/activeProfile /activeProfiles /settings Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Privacy: If you are responding to this email or providing personal information to the SRO for the purposes of one of the Acts it administers, such information is used only for the purpose for which it was collected (administration of SRO legislation ) and is protected by the Information Privacy Act 2000 and secrecy provisions contained in legislation administered by SRO. It is not disclosed otherwise than in accordance with the law. If you would like a copy of the SRO Privacy Policy please refer to SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request a copy.
Re: Don't kill the messenger
You could solve your first run of Maven every day is slow issue by creating a cron job to run mvn depedency:go-offline on your project(s) at 6am every day. Right now, having multiple threads of Maven running at the same time using the same local repo cache is a bad idea. A few new implementations have been discussed on dev@ and I imagine we'll see some changes there at some point. Wayne On 12/20/07, Johannes Schneider [EMAIL PROTECTED] wrote: Some points are really problematic with Maven. Every day the first usage of maven on each project is really slow. I would like some sort of improvement with this. What about adding the possibility to download commonly used plugins after installation (just a script...). What about preparing some scripts (that can be used as cronjob or at boot time) that resolve some dependencies in the background? Adding some intelligence should be possible. What about using several threads to look for library updates? What about setting shorter timeouts (ever tried to use maven if a repository is not available?) This are small improvements that don't change the internals or principles of maven but could improve my user experience a lot. Regards, Johannes Schneider Borut Bolčina wrote: Anybody saw this post? http://fishbowl.pastiche.org/ Unfortunately the author, Charles Miller [EMAIL PROTECTED], disabled the comments to prevent spam. Hmmm. Regards, Borut
Re: Don't kill the messenger
On Dec 21, 2007 8:38 AM, Mark Struberg [EMAIL PROTECTED] wrote: This must obviously be a guy who never had a build with more than one single module. So he never learned that it is NOT a good idea to keep all dependencies in every single module ;) Charles is the architect for Atlassian Confluence, who's significantly complicated (multi-module) build is driven by Maven 2 and has been for at least a year now. Atlassian as a company has partaken of the Maven coolaid, resulting in hundreds of Maven 2-created artifacts. In fact, our plugin developer kit is built on Maven 2 archetypes as a way to quickly get potential developers up to speed. His comment about the dependencies springs from some bad experiences we had with our Maven 1 JIRA builds. When ibiblio decided to reorganize their repository, it broke our source distributions, causing lots of user complaints. Anytime you have your build depend on external resources, you introduce a point of failure that is particularly dangerous when you try to support old releases that may be many years old. Yes, there are ways to mitigate that problem and yes, Atlassian uses Archiva to have more control over resources, but I believe Charles' point is it is still broken by design, despite the bandaids you stick on it. Don -- yes, I work for Atlassian (of whom I don't speak for) but my love/mostly hate affair with Maven extends back many years with Struts...just ask Wendy :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Don't kill the messenger
Offline mode breaks when there are snapshots: mvn -o install [INFO] Failed to resolve artifact. GroupId: some-group ArtifactId: some-artifact Version: 1.0-SNAPSHOT Reason: System is offline. some-group:some-artifact:pom:1.0-SNAPSHOT NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. It *should* work, but doesn't. Maybe I am missing something? On Dec 20, 2007 2:57 PM, Wayne Fay [EMAIL PROTECTED] wrote: You could run -o (offline) and then leave it off when you want to check for snapshot updates. Wayne On 12/20/07, Andrew Robinson [EMAIL PROTECTED] wrote: I don't agree with most of the post, but he does have a point about resolving dependencies during every build. On one of my projects, I am using several snapshots due to needing bug fixes. I really wish I could turn off snapshot checking until I specifically ask for it to check. Like a maven.snapshot.skip flag. -Andrew On Dec 20, 2007 2:38 PM, Mark Struberg [EMAIL PROTECTED] wrote: This must obviously be a guy who never had a build with more than one single module. So he never learned that it is NOT a good idea to keep all dependencies in every single module ;) Additionally this guy does not know about maven-proxy and the ability to backup all artifacts you need for the whole company. So for me, I can simply ignore his personal opinion :) LieGrü, strub --- Borut BolÄ ina [EMAIL PROTECTED] schrieb: Anybody saw this post? http://fishbowl.pastiche.org/ Unfortunately the author, Charles Miller [EMAIL PROTECTED], disabled the comments to prevent spam. Hmmm. Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Don't kill the messenger
Borut Bolčina wrote: Anybody saw this post? http://fishbowl.pastiche.org/ Its quite polemic: |Tracking down dependencies and sorting out their transitive relationships |is a tricky task Yes, traversing a tree is like magic... JT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Don't kill the messenger
--- Jan Torben Heuer [EMAIL PROTECTED] schrieb: Yes, traversing a tree is like magic... Not if there are multiple references to e.g. the same artifact but with different versions, etc... In real live this can be really beasty. LieGrü, strub Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Don't kill the messenger
Sorry, it looks like the settings.xml that my company has us use has an update policy of always. Guess that conflicts with offline. I retract any agreement I had with that blog :) -Andrew On Dec 20, 2007 4:29 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Offline mode breaks when there are snapshots: mvn -o install [INFO] Failed to resolve artifact. GroupId: some-group ArtifactId: some-artifact Version: 1.0-SNAPSHOT Reason: System is offline. some-group:some-artifact:pom:1.0-SNAPSHOT NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. It *should* work, but doesn't. Maybe I am missing something? On Dec 20, 2007 2:57 PM, Wayne Fay [EMAIL PROTECTED] wrote: You could run -o (offline) and then leave it off when you want to check for snapshot updates. Wayne On 12/20/07, Andrew Robinson [EMAIL PROTECTED] wrote: I don't agree with most of the post, but he does have a point about resolving dependencies during every build. On one of my projects, I am using several snapshots due to needing bug fixes. I really wish I could turn off snapshot checking until I specifically ask for it to check. Like a maven.snapshot.skip flag. -Andrew On Dec 20, 2007 2:38 PM, Mark Struberg [EMAIL PROTECTED] wrote: This must obviously be a guy who never had a build with more than one single module. So he never learned that it is NOT a good idea to keep all dependencies in every single module ;) Additionally this guy does not know about maven-proxy and the ability to backup all artifacts you need for the whole company. So for me, I can simply ignore his personal opinion :) LieGrü, strub --- Borut BolÄ ina [EMAIL PROTECTED] schrieb: Anybody saw this post? http://fishbowl.pastiche.org/ Unfortunately the author, Charles Miller [EMAIL PROTECTED], disabled the comments to prevent spam. Hmmm. Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coverage report of web application integration test with cobertura-maven-plugin
Thanks Jeff, Please post back when you have any more news. Best of luck. Regards, On Dec 20, 2007 7:45 PM, Jeff MAURY [EMAIL PROTECTED] wrote: Hello, I have extended the corbertura-maven-plugin in order to do that but I'm facing an issue with the cargo plugin: my cobertura plugin will not generate a new artifact with a specific classifier (like the clover plugin) but when the cargo plugin starts a container, it will deploy both artifacts, the original one and the one generated with corbertura. I need to continue working on it in order to find a solution. Jeff On Dec 20, 2007 7:41 PM, Pedro Viegas [EMAIL PROTECTED] wrote: Hi guys, Any more news on this? This is a really important feature. We've been battling on this one for a week ate work. Any workarrounds, any news? Thanks, On Dec 13, 2007 3:34 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Thus you'll have my help ;-) On Dec 13, 2007 4:29 PM, Jeff MAURY [EMAIL PROTECTED] wrote: I would prefer extending the current one. Jeff On Dec 13, 2007 4:26 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: another cobertura plugin or an extension of the current one ? otherwise you have my +1 to have the possibility to include integration tests in reports Arnaud On Dec 13, 2007 3:58 PM, Jeff MAURY [EMAIL PROTECTED] wrote: Richard, I have the same problem and I think this is not feasible with the current design of the Cobertura Maven2 plugin design as it is today. It does only address the test phase and not the integration-test phase. I plan to work on another Cobertura plugin (inspired from the philosophy of the Clover plugin) that address this issue. Jeff On Dec 13, 2007 3:29 PM, Brewster, Richard [EMAIL PROTECTED] wrote: I want to produce a coverage report for the integration test phase of a web application (war packaging). My integration tests are run by the Cargo maven plugin launching JBoss 4.0.5. I've been using the 2.0 version of the cobertura-maven-plugin (and will try the upgrade to 2.2 ). I have a modular project with core and web modules. I get the expected coverage reports for my core module, but zero coverage for the web module. The instrumented classes are not packaged into the war, for one. According to the Cobertura FAQ, this sort of coverage testing can be done. http://cobertura.sourceforge.net/faq.html Has anyone done this? Any advice would be appreciated! Also, it would be great if integration test coverage could be documented here, too: http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Thanks, Richard Brewster Senior Associate Perrin Quarles Associates [EMAIL PROTECTED] (434) 817-2640 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com -- .. Arnaud HERITIER .. OCTO Technology -
RE: Trying to work out where a snapshot caching problem is
The problem has been solved - thanks for your help. I assumed that the mirror would pick up the snapshots - obviously that is not the case. So I set it in the settings.xml file, and now everything works as expected. Thanks, Ian William Ferguson wrote: Ian, it sounds like you have not configured Maven with the address of the snapshot repositories. I suspect you have just setup a mirror to point to the main repository in Artifactory (in which you are caching Apache, Codehaus etc). Its generally a good idea to keep release and snapshot artifacts separate in any case Don't forget to list the pluginRepository too. And don't foget to activate the profile, either in settings.xml (typical) or on the command line. Try adding something like the following to your settings.xml profile iddefault-repositories/id repositories repository idsnapshot/id nameSNAPSHOT Repository/name urlhttp://hubpc65:8080/artifactory/snapshot/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idsnapshot/id nameSNAPSHOT Repository/name urlhttp://hubpc65:8080/artifactory/snapshot/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled updatePolicyalways/updatePolicy /snapshots /pluginRepository /pluginRepositories /profile William -Original Message- From: Ian Rowlands [mailto:[EMAIL PROTECTED] Sent: Friday, 21 December 2007 7:47 AM To: undisclosed-recipients Subject: [***POSSIBLE SPAM***] - Trying to work out where a snapshot caching problem is - Sender is forged (SPF Fail) Hi, I'm having a problem with Maven caching and snapshots. I am using Artifactory as a repository cache, which everybody is configured to use. If a release version is needed, everything is fetched into the users' local repository as expected. However the same is not happening with snapshots. I know the snapshots are there - I can see them, and if I do a manual copy out of Artifactory and place them in the local repository everything is fine. I'm not sure whether the problem is my Maven configuration, or an Artifactory configuration. Are there any diagnostics I can turn on to determine where the problem is? I've included the relevant bits of the (customised) settings.xml which everybody is using. This happens with Maven 2.0.7 and 2.0.8. Thanks, Ian settings servers server idartifactory.releases/id usernameadmin/username passwordpassword/password /server server idartifactory.snapshots/id usernameadmin/username passwordpassword/password /server /servers mirrors mirror idartifactory/id mirrorOf*/mirrorOf urlhttp://ebizci/artifactory/all//url nameArtifactory/name /mirror /mirrors profiles !-- Default profile, which should always be set -- profile iddefault/id !-- Need this repository until the dashboard plugin becomes ready for release -- pluginRepositories pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository /pluginRepositories /profile /profiles !-- activeProfiles | List of profiles that are active for all builds. |-- activeProfiles activeProfiledefault/activeProfile /activeProfiles /settings Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Privacy: If you are responding to this email or providing personal information to the SRO for the purposes of one of the Acts it administers, such information is used only for the purpose for which it was collected (administration of SRO legislation ) and is protected by the Information Privacy Act 2000 and secrecy provisions contained
