Re: RSS feeds in maven archiva
Hi, It shouldn't require any additional action. I did find I occasionally got an empty result on 1.3.9, but the feeds are working correctly in 2.1.0. The error you got seems like it doesn't see /feeds/ at all - what is the RSS URL you are subscribing to? Cheers, Brett On 31 Jul 2014, at 1:33 pm, ghostwolf59 martin.cederv...@commerce.wa.gov.au wrote: Hi, Is RSS feeds meant to work without any additional configurations in Maven Archiva ? The only information I managed to find is the formatting changes to the url made since 1.1.2 I currently use Maven Archiva v1.3.9 When I try to subscribe on a repo I receive HTTP Status 404 - There is no Action mapped for namespace [/] and action name [releases] associated with context path [/archiva]. I've tried to subscribe on a feed both by clicking the rss feed icon from the repositories page as well as using the http://[hostname]:[port]/archiva/feeds/[repositoryId] format with the SharpReader, but non work Do I need to configure archiva or tomcat before I can enable this or...? cheers -- View this message in context: http://archiva.996284.n3.nabble.com/RSS-feeds-in-maven-archiva-tp15797.html Sent from the Issues mailing list archive at Nabble.com.
Re: RSS feeds in maven archiva
I've had a closer look - I was testing an older 1.3.6 installation, and it seems there has been a regression in 1.3.9 where I see the error you're getting. I'll see if I can patch this for the 1.3.x branch, but there's no issues in the newer 2.x releases. - Brett On 1 Aug 2014, at 1:34 pm, Brett Porter br...@apache.org wrote: Hi, It shouldn't require any additional action. I did find I occasionally got an empty result on 1.3.9, but the feeds are working correctly in 2.1.0. The error you got seems like it doesn't see /feeds/ at all - what is the RSS URL you are subscribing to? Cheers, Brett On 31 Jul 2014, at 1:33 pm, ghostwolf59 martin.cederv...@commerce.wa.gov.au wrote: Hi, Is RSS feeds meant to work without any additional configurations in Maven Archiva ? The only information I managed to find is the formatting changes to the url made since 1.1.2 I currently use Maven Archiva v1.3.9 When I try to subscribe on a repo I receive HTTP Status 404 - There is no Action mapped for namespace [/] and action name [releases] associated with context path [/archiva]. I've tried to subscribe on a feed both by clicking the rss feed icon from the repositories page as well as using the http://[hostname]:[port]/archiva/feeds/[repositoryId] format with the SharpReader, but non work Do I need to configure archiva or tomcat before I can enable this or...? cheers -- View this message in context: http://archiva.996284.n3.nabble.com/RSS-feeds-in-maven-archiva-tp15797.html Sent from the Issues mailing list archive at Nabble.com.
Re: Cannot start Archiva 1.3.x
That does seem odd - did it accidentally get configured to use something like gcj when it was changed? Is there any more to the exception trace? To narrow it down, you can try these changes in wrapper.conf: - change wrapper.java.command=java to be the full path of the Java you want to use - add wrapper.debug=TRUE to the file These are if you are using the standalone install. - Brett On 15 Jul 2014, at 12:26 am, Mar4tin syrinx2...@msn.com wrote: Hi, For some obscure reason our Archiva cannot be restarted. First I thought it was the upgrade to Java 8 that did it (something we did recently on our server), but reverting switching back to Java 6 doesn't seem to solve this issue. Anyone can help? Caused by: java.lang.IllegalStateException: Context namespace element 'annotation-config' and its parser class [org.springframework.context.annotation.AnnotationConfigBeanDefinitionParser] are only available on JDK 1.5 and higher at org.springframework.context.config.ContextNamespaceHandler$1.parse(ContextNamespaceHandler.java:65) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1297) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1287) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:92) at org.codehaus.plexus.spring.PlexusBeanDefinitionDocumentReader.registerBeanDefinitions(PlexusBeanDefinitionDocumentReader.java:85) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:507) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:398) ... 43 more -- View this message in context: http://archiva.996284.n3.nabble.com/Cannot-start-Archiva-1-3-x-tp15686.html Sent from the Issues mailing list archive at Nabble.com.
Re: Help understanding RepositoryContentConsumer API
On 15 Jul 2014, at 5:37 am, Matt Magoffin apache@msqr.us wrote: If the whenGathered date was set to the epoch or null, or perhaps the RepositoryScanner.FRESH_SCAN constant (with a value of 0), that would indicate to my consumer that a full scan were being performed. But when I do initiate the Directory Scan from the UI, the whenGathered is set to the current time. Right - that was what I found as well (though it wasn't what I recalled). We could probably add some more hooks into the overall process if you wanted to propose such a change? Or is processing updates and deletions sufficient to maintain the metadata, without having to start from scratch? If I could process updates and deletions, and know they were such, I could maintain the metadata appropriately, yes. The reason I want to re-create the metadata is for the case when something is deleted. I don't see how I get informed of deletions in the RepositoryContentConsumer API, however. Is there a way to get notified of them? In 1.3.x, there's a DatabaseCleanupConsumer that you can implement, which will get called when an artifact is deleted. In 2.0.x, there's a different event class that it'll need to be ported to. Which are you targeting? - Brett Cheers, m@
[RESULT] Apache Archiva 1.3.9
The vote has passed with 3 x +1. I'll proceed to finalise the release. - Brett On 25 Jun 2014, at 7:03 pm, Brett Porter br...@apache.org wrote: Hi, I'd like to call a vote to release Apache Archiva 1.3.9. This is an update to those still on 1.3.x that has an updated version of Struts for some of their latest fixes. (The announcement will still recommend users upgrade to 2.0.1 when they can). The release artifacts are at: https://dist.apache.org/repos/dist/dev/archiva/1.3.9/ Specifically, https://dist.apache.org/repos/dist/dev/archiva/1.3.9/src/apache-archiva-1.3.9-src.zip with signature https://dist.apache.org/repos/dist/dev/archiva/1.3.9/src/apache-archiva-1.3.9-src.zip.asc Site available here: http://archiva.apache.org/docs/1.3.9/ Staging repository: https://archiva-repository.apache.org/archiva/repository/archiva-releases-stage-1.3/ The git tag is archiva-1.3.9, revision d806ab411edaf73b9f03c9e939b9dfb88db04c23 The vote is open for 72 hours: [ ] +1 [ ] 0 [ ] -1 Regards, Brett
[ANNOUNCE] Apache Archiva 1.3.9 Released
The Apache Archiva team would like to announce the release of Archiva 1.3.9. This is primarily a bug fix release for users that have not yet upgraded to Archiva 2.0.1+. Archiva is available for download from: * http://archiva.apache.org/download.html Archiva is an application for managing one or more remote artifact repositories, including administration, artifact handling, browsing and searching. If you have any questions, please consult: * the web site: http://archiva.apache.org/ * the archiva-user mailing list: http://archiva.apache.org/mail-lists.html Thanks, The Apache Archiva Team
[VOTE] Apache Archiva 1.3.8
Hi, I'd like to call a vote to release Apache Archiva 1.3.8. This is an update to those still on 1.3.x that has an updated version of Struts for some of their latest fixes, and supercedes the vote for 1.3.7. (The announcement will still recommend users upgrade to 2.0.1 when they can). The release artifacts are at: https://dist.apache.org/repos/dist/dev/archiva/1.3.8/ Specifically, https://dist.apache.org/repos/dist/dev/archiva/1.3.8/src/apache-archiva-1.3.8-src.zip with signature https://dist.apache.org/repos/dist/dev/archiva/1.3.8/src/apache-archiva-1.3.8-src.zip.asc Site available here: http://archiva.apache.org/docs/1.3.8/ Staging repository: https://archiva-repository.apache.org/archiva/repository/archiva-releases-stage-1.3/ The git tag is archiva-1.3.8, revision df33f0707d7c64f34ce88c5416e817fc8aa2388d The vote is open for 72 hours: [ ] +1 [ ] 0 [ ] -1 Regards, Brett
Re: svn commit: r1583496 - in /archiva/branches/archiva-1.3.x/archiva-jetty: pom.xml src/main/assembly/bin.xml
Thanks. However, this now suffers the problem with ARCHIVA_BASE that I patched for 2.0.0 previously. I'll update tomorrow, but if you have a chance to look and adjust beforehand, I'd appreciate it :) On 1 Apr 2014, at 11:02 am, sk...@apache.org wrote: Author: skygo Date: Tue Apr 1 00:02:32 2014 New Revision: 1583496 URL: http://svn.apache.org/r1583496 Log: appassembler-maven-plugin up to 1.7, better x64 selection for deamon Modified: archiva/branches/archiva-1.3.x/archiva-jetty/pom.xml archiva/branches/archiva-1.3.x/archiva-jetty/src/main/assembly/bin.xml Modified: archiva/branches/archiva-1.3.x/archiva-jetty/pom.xml URL: http://svn.apache.org/viewvc/archiva/branches/archiva-1.3.x/archiva-jetty/pom.xml?rev=1583496r1=1583495r2=1583496view=diff == --- archiva/branches/archiva-1.3.x/archiva-jetty/pom.xml (original) +++ archiva/branches/archiva-1.3.x/archiva-jetty/pom.xml Tue Apr 1 00:02:32 2014 @@ -98,8 +98,9 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdappassembler-maven-plugin/artifactId -version1.0/version +version1.7/version configuration + configurationDirectoryconf/configurationDirectory daemons daemon idarchiva/id @@ -163,6 +164,7 @@ includesolaris-sparc-32/include includesolaris-sparc-64/include includewindows-x86-32/include +includewindows-x86-64/include /includes /generatorConfiguration /generatorConfigurations Modified: archiva/branches/archiva-1.3.x/archiva-jetty/src/main/assembly/bin.xml URL: http://svn.apache.org/viewvc/archiva/branches/archiva-1.3.x/archiva-jetty/src/main/assembly/bin.xml?rev=1583496r1=1583495r2=1583496view=diff == --- archiva/branches/archiva-1.3.x/archiva-jetty/src/main/assembly/bin.xml (original) +++ archiva/branches/archiva-1.3.x/archiva-jetty/src/main/assembly/bin.xml Tue Apr 1 00:02:32 2014 @@ -82,6 +82,7 @@ outputDirectorybin/outputDirectory includes includewrapper-windows-x86-32.exe/include +includewrapper-windows-x86-64.exe/include /includes fileMode0755/fileMode /fileSet -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Using Git as a repository?
On 2 Apr 2014, at 10:14 am, Olivier Lamy ol...@apache.org wrote: Hi, So is there any objections if we move redback-core and archiva to git? +1 I've been meaning to propose this also... (redback-components and parent pom won't be concerned) Why is that? Also, what about the site sources? - Brett -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Using Git as a repository?
On 2 Apr 2014, at 11:50 am, Olivier Lamy ol...@apache.org wrote: On 2 April 2014 11:20, Brett Porter br...@apache.org wrote: On 2 Apr 2014, at 10:14 am, Olivier Lamy ol...@apache.org wrote: Hi, So is there any objections if we move redback-core and archiva to git? +1 I've been meaning to propose this also... (redback-components and parent pom won't be concerned) Why is that? because it's plenty of sub modules so releasing only few will be pain as not very well supported by maven release. So will need to have a separate git repository per component which will be IMHO a pain to do (last time I checked git sub modules support this was not really famous) Also, what about the site sources? Yup possible too. But I would prefer focus first on most important part of sources. Does it make sense? Yep! - Brett -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Cassandra storage and jdk version?
On 1 Apr 2014, at 11:37 am, Olivier Lamy ol...@apache.org wrote: Hi Folks, I finished the implementation of the metadata storage using Cassandra. See docs here: http://archiva.apache.org/docs/2.0.2-SNAPSHOT/adminguide/repositories-content-storage.html Builds available from here: https://builds.apache.org/view/A-D/view/Archiva/job/archiva-all-maven-3.1.x-jdk-1.7/ Will take a look! What is the impact on the app overall in terms of deployment, performance, memory, etc.? The question is now the jdk version. With this cassandra runtime version it's now 1.7. So are we ok to set 1.7 as a prerequisite? No problem here. - Brett -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
[VOTE] Apache Archiva 1.3.7
Hi, I'd like to call a vote to release Apache Archiva 1.3.7. This is an update to those still on 1.3.x that has an updated version of Struts for some of their latest fixes. (The announcement will still recommend users upgrade to 2.0.1 when they can). The release artifacts are at: https://dist.apache.org/repos/dist/dev/archiva/1.3.7/ Specifically, https://dist.apache.org/repos/dist/dev/archiva/1.3.7/src/apache-archiva-1.3.7-src.zip with signature https://dist.apache.org/repos/dist/dev/archiva/1.3.7/src/apache-archiva-1.3.7-src.zip.asc Site available here: http://archiva.apache.org/docs/1.3.7/ Staging repository: https://archiva-repository.apache.org/archiva/repository/archiva-releases-stage-1.3/ The SVN tag is r1583096, http://svn.apache.org/repos/asf/archiva/tags/archiva-1.3.7/ The vote is open for 72 hours: [ ] +1 [ ] 0 [ ] -1 Regards, Brett
Re: [VOTE] Apache Archiva 2.0.0
Unfortunately I've had commitments every evening from last Fri to tomorrow :) I'll certainly have a look Thurs night if no other votes by then - sorry about that. - Brett On 11 Feb 2014, at 10:48 pm, Olivier Lamy ol...@apache.org wrote: ping. Still missing one binding +1 On 10 February 2014 10:22, Olivier Lamy ol...@apache.org wrote: My +1 On 7 February 2014 10:54, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Archiva 2.0.0 We fixed 29 issues (since 1.4-M4). The release note is available here [1] (staging documentation as well [2]. Staged maven repository: https://archiva-repository.apache.org/archiva/repository/archiva-releases-stage/ Staged distribution: https://dist.apache.org/repos/dist/dev/archiva/2.0.0/ Vote open for 96H (yup it's week end soon and it's major release) [+1] [0] [-1] Cheers, -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy [1] http://archiva.apache.org/docs/2.0.0/release-notes.html [2] http://archiva.apache.org/docs/2.0.0 -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Apache Archiva 2.0.0-RC1
Same here for all of those - I think Olivier fixed the first problem in the RC branch, but I haven't re-tested yet. Not sure if the sorting problem was fixed yet. On 30 Jan 2014, at 7:47 pm, Sascha Vogt sascha.v...@gmail.com wrote: Hi Olivier, Am 30.01.2014 06:36, schrieb Olivier Lamy: Hi, Apologize for delay, I was a bit busy because of $DAYJOB and beach :-). I will have to respin a RC build due to issues fixes. BTW if you find any issues let me know before. I found something, not sure if this is caused by me / our infrastructure or a general issue: Searching for users maintained in LDAP is not working reliably. When I search for a user in the filters, auto-complete shows me the user, but if I click on it or use down+enter to select it, nothing happens. Additionally clicking on Filter just removes the search. And third, the list is not sorted alphabetically (under no criteria, not user name, full name nor email) even after clicking Sort by name. Tested with FF 26 and Chrome 32 (on Windows). IE10 doesn't even load the GUI, Login / Register is gray and in the middle of the screen I get the loading spinner. Greetings -Sascha- -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: svn commit: r1562340 - /archiva/branches/archiva-1.3.x/archiva-modules/archiva-base/archiva-consumers/archiva-core-consumers/src/test/java/org/apache/maven/archiva/consumers/core/repository/Cleanu
Hi, This does change the semantic (thought it may not affect the test that much), as INDEX_PATH is a zip file - I wonder if you just needed file.getParentFile().mkdirs()? Or is there a problem with file.createNewFile() that it needs to actually create something? Thanks, Brett On 29 Jan 2014, at 12:34 pm, sk...@apache.org wrote: Author: skygo Date: Wed Jan 29 01:34:02 2014 New Revision: 1562340 URL: http://svn.apache.org/r1562340 Log: fix test for windoz os (hope not breaking semantic) Modified: archiva/branches/archiva-1.3.x/archiva-modules/archiva-base/archiva-consumers/archiva-core-consumers/src/test/java/org/apache/maven/archiva/consumers/core/repository/CleanupReleasedSnapshotsRepositoryPurgeTest.java Modified: archiva/branches/archiva-1.3.x/archiva-modules/archiva-base/archiva-consumers/archiva-core-consumers/src/test/java/org/apache/maven/archiva/consumers/core/repository/CleanupReleasedSnapshotsRepositoryPurgeTest.java URL: http://svn.apache.org/viewvc/archiva/branches/archiva-1.3.x/archiva-modules/archiva-base/archiva-consumers/archiva-core-consumers/src/test/java/org/apache/maven/archiva/consumers/core/repository/CleanupReleasedSnapshotsRepositoryPurgeTest.java?rev=1562340r1=1562339r2=1562340view=diff == --- archiva/branches/archiva-1.3.x/archiva-modules/archiva-base/archiva-consumers/archiva-core-consumers/src/test/java/org/apache/maven/archiva/consumers/core/repository/CleanupReleasedSnapshotsRepositoryPurgeTest.java (original) +++ archiva/branches/archiva-1.3.x/archiva-modules/archiva-base/archiva-consumers/archiva-core-consumers/src/test/java/org/apache/maven/archiva/consumers/core/repository/CleanupReleasedSnapshotsRepositoryPurgeTest.java Wed Jan 29 01:34:02 2014 @@ -137,6 +137,9 @@ public class CleanupReleasedSnapshotsRep listenerControl.replay(); File file = new File( repoRoot, INDEX_PATH ); +// windows fix +file.mkdirs(); + file.createNewFile(); assertTrue( file.exists() ); -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Apache Archiva 2.0.0-RC1
Hi Sascha, The ASF infra team is aware of a problem with dist.apache.org and are working on it. In the mean time, you can also get the binaries from here: https://archiva-repository.apache.org/archiva/repository/archiva-releases-stage/org/apache/archiva/archiva-jetty/2.0.0-RC1/ Regards, Brett On 25 Jan 2014, at 1:49 am, Sascha Vogt sascha.v...@gmail.com wrote: Hi Olivier, I wanted to give it a try (especially regarding LDAP integration) but I can't seem to access https://dist.apache.org/repos/dist/dev/archiva/2.0.0-RC1/ Should it still be available? Greetings -Sascha- Am 19.01.2014 23:16, schrieb Olivier Lamy: Hi, This is the RC1 of Apache Archiva 2.0.0-RC1. If all good, 2.0.0 will be build from this one. Jira changes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18971styleName=TextprojectId=10980Create=Create Staged repository with various redback librarires: https://archiva-repository.apache.org/archiva/repository/archiva-releases-stage Apache Distribution: https://dist.apache.org/repos/dist/dev/archiva/2.0.0-RC1/ I will wait 3 days, if no issues found, I will start a 2.0.0 release vote Cheers, -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Apache Archiva 2.0.0-RC1
On 21 Jan 2014, at 9:18 am, Olivier Lamy ol...@apache.org wrote: On 20 January 2014 15:27, Brett Porter br...@apache.org wrote: 1) can't change ARCHIVA_BASE variable when using the service wrapper. This is due to a change in the AppAssembler plugin that I don't agree with, but haven't had the time to revise it yet. I have a workaround we can apply in Archiva - will roll through that later this evening. ? I miss your point. If you set the ARCHIVA_BASE variable before starting to use a different conf/log directory, it ignores it (the wrapper.conf ends up with set.ARCHIVA_BASE=. instead of set.default.ARCHIVA_BASE=.). 2) Next was this error: jvm 1| org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'managedRepositoryAdmin#default': Invocation of init method failed; nested exception is org.apache.archiva.admin.model.RepositoryAdminException: Cannot forcefully unlock a NativeFSLock which is held by another indexer component: /var/local/archiva/data/indexes/com.maestrodev.maestro.releases/write.lock This happened because there was a stage repository using the same indexDir. I removed the configuration from the stage directory - but do we need to force some upgrade here? 3) Need to make sure upgrade notes take care of context-root change (they may do, I haven't had a chance to check that just yet) Only got as far as starting it up, so will do more testing. Should we move forward on the redback / parent releases to get them out of the way while the overall stuff proceeds? I wanted to avoid too many votes :-) Should be easy to pass some of the votes while RC might get re-made - I'm finding it hard to build everything right now because they depend on staged bits :) - Brett
Re: 2.0.0 Release time
On 14 Jan 2014, at 9:34 am, Olivier Lamy ol...@apache.org wrote: On 13 January 2014 12:02, Brett Porter br...@apache.org wrote: Would it make sense to go through some RC cycles? We should plan some specific promotion of the 2.0.0 release once it is GA. I believe we already did 1.4-M1 to M4 (this sounds already RC for me :-) ) I was thinking more like the typical Maven releases - in other words, if we put up 2.0.0 for vote and it fails, what happens next? Re-spin 2.0.0, move to 2.0.1, or do we start out with some 2.0.0-RCx releases until it's good? Or do we do more snapshot testing until we already have a passable number of +1's and then just vote on 2.0.0 then? Definitely like to see releases moving forward. I know I've been slack on testing recently... unfortunately this week is particularly bad as I'm fully booked up already :) Releasing will be more than a week. So no worries you will have time to test :P Thanks :) - Brett -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: 2.0.0 Release time
Would it make sense to go through some RC cycles? We should plan some specific promotion of the 2.0.0 release once it is GA. Definitely like to see releases moving forward. I know I've been slack on testing recently... unfortunately this week is particularly bad as I'm fully booked up already :) - Brett On 10 Jan 2014, at 3:29 pm, Olivier Lamy ol...@apache.org wrote: Feel free to download from here: https://builds.apache.org/view/A-D/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/ builds #2218 + On 10 January 2014 15:16, Chris Graham chrisgw...@gmail.com wrote: Do we have a stable build that I can at least test first? Which jenkins job should I take a build from and quickly test? -Chris On Fri, Jan 10, 2014 at 2:55 PM, Olivier Lamy ol...@apache.org wrote: Yup it's new year so I believe it's release time for a hot 2.0.0! :-) Any objections? Cheers, -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter @brettporter http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Next version: Archiva 2.0.0?
Hi, Can't remember if I've brought this up before... I'm a big fan of semantic versioning :) Given the large changes to the UI, and that we're talking about dropping features (and have already dropped XMLRPC and a large number of internal APIs), should we think about renaming 1.4-SNAPSHOT to 2.0.0-SNAPSHOT? Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Remove maven 1 support
I'd say keep using the shipped dependency. We know where to find it if a change is ever needed, and would more likely remove the support if we found some work was needed anyway... On 23/07/2013, at 11:26 AM, Olivier Lamy ol...@apache.org wrote: 2013/7/22 Brett Porter br...@apache.org: Is it already working in 1.4? If so, maybe a deprecation cycle might be a good idea. should work :-) The question is related to import source code from maven or not. I don't mind removing it, but it might be good to understand how many users actively use that still. - Brett On 20/07/2013, at 8:53 PM, Olivier Lamy ol...@apache.org wrote: Hi, As now maven 1.x is EOL [1] We can remove the support in Archiva? Objections? Cheers, -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy [1] http://maven.apache.org/maven-1.x-eol.html -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Remove maven 1 support
Is it already working in 1.4? If so, maybe a deprecation cycle might be a good idea. I don't mind removing it, but it might be good to understand how many users actively use that still. - Brett On 20/07/2013, at 8:53 PM, Olivier Lamy ol...@apache.org wrote: Hi, As now maven 1.x is EOL [1] We can remove the support in Archiva? Objections? Cheers, -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy [1] http://maven.apache.org/maven-1.x-eol.html -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: SLF4J errors ?
It would be good to avoid the conflict, but as you can see here it picked the right one so the warning shouldn't be significant (the link in the error has more info). On 02/03/2013, at 9:37 AM, Chris Graham chrisgw...@gmail.com wrote: In using M4-SNAPSHOT on WAS8, in looking in the system log, I saw: [3/2/13 8:45:57:460 EST] 0010 SystemErr R SLF4J: Class path contains multiple SLF4J bindings. [3/2/13 8:45:57:461 EST] 0010 SystemErr R SLF4J: Found binding in [wsjar:file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/buildCell01/archiva-1_4-M4-SNAPSHOT_war.ear/archiva-webapp-1.4-M4-SNAPSHOT-1989.war/WEB-INF/lib/log4j-slf4j-impl-2.0-beta4.jar!/org/slf4j/impl/StaticLoggerBinder.class] [3/2/13 8:45:57:461 EST] 0010 SystemErr R SLF4J: Found binding in [bundleresource://481.fwk-786195778:1/org/slf4j/impl/StaticLoggerBinder.class] [3/2/13 8:45:57:461 EST] 0010 SystemErr R SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. [3/2/13 8:45:57:465 EST] 0010 SystemErr R SLF4J: Actual binding is of type [org.slf4j.helpers.Log4JLoggerFactory] I'm not sure of it's significant or not. -Chris -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
edit roles not working on archiva-repository.apache.org
Hi Olivier, I tried to use the admin interface on there, but nothing appears in the edit roles pane. Is there an update that can be made to archiva-repository that might help with this problem? Is there a way I can get access to the VM? Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: edit roles not working on archiva-repository.apache.org
I was able to edit the roles using the REST API. However now I'm getting a 500 error and don't think I have access to diagnose it: https://archiva-repository.apache.org/archiva/repository/public/Microsoft/Build/Engine/Microsoft.Build.Engine/2.0.0.0/Microsoft.Build.Engine-2.0.0.0.pom On 02/03/2013, at 10:49 PM, Brett Porter br...@apache.org wrote: Hi Olivier, I tried to use the admin interface on there, but nothing appears in the edit roles pane. Is there an update that can be made to archiva-repository that might help with this problem? Is there a way I can get access to the VM? Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: edit roles not working on archiva-repository.apache.org
On 03/03/2013, at 1:39 AM, Olivier Lamy ol...@apache.org wrote: I just deployed a version with a fix for that.( was fixed this week) To have access I don't know exactly how to do that for you. Maybe you can ask infra. The vm is archiva-vm.a.o Will do. regarding your artifact we don't deliver artifacts with such name :P from which repository is that available ? It's not, it should have returned a 404 but it got a 500 instead. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: [VOTE] Release Archiva 1.3.6
Hi Brent, On 08/01/2013, at 4:06 PM, Brent Atkinson brent.atkin...@gmail.com wrote: Source signatures: gpg ok, md5/sha1 ok, but filename in sha1 and md5 files doesn't match name of source zip Binary signatures: gpg ok, md5/sha1 ok, but filename in sha1 and md5 files doesn't match names of binary packages I'll fix the filenames. Building: Tests fail on Win7, success with -DskipTests Running: -bin.tar bundle: ok, -bin.zip bundle: ok Due to the test failures, I don't feel right signing-off, so I'm a non-binding 0 Thanks for letting us know - I think these problems were fixed up on trunk some time back. Probably best to focus on issues there. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
[RESULT] [VOTE] Release Archiva 1.3.6
Vote passes with +1 from myself, Deng and Olivier and a 0 from Brent (non-binding). I'll proceed with it in the morning. - Brett On 07/01/2013, at 11:53 PM, Brett Porter br...@apache.org wrote: Hi, I'd like to call a vote to release Archiva 1.3.6. The source bundles are located here: https://dist.apache.org/repos/dist/dev/archiva/1.3.6/src/ The following binaries will also be made available: https://dist.apache.org/repos/dist/dev/archiva/1.3.6/binaries/ The updated documentation has been deployed here: http://archiva.apache.org/docs/1.3.6/ Please test and vote accordingly! [ ] +1 [ ] 0 [ ] -1 The vote will be open for 72 hours. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
[VOTE] Release Archiva 1.3.6
Hi, I'd like to call a vote to release Archiva 1.3.6. The source bundles are located here: https://dist.apache.org/repos/dist/dev/archiva/1.3.6/src/ The following binaries will also be made available: https://dist.apache.org/repos/dist/dev/archiva/1.3.6/binaries/ The updated documentation has been deployed here: http://archiva.apache.org/docs/1.3.6/ Please test and vote accordingly! [ ] +1 [ ] 0 [ ] -1 The vote will be open for 72 hours. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Releasing 1.4-M4
Sounds good. Appreciate the push! We should probably talk about what is needed to call it 1.4 final after that and narrow the scope to that. I'll look over the tickets you asked questions of me in over the next couple of days. Cheers, Brett On 21/12/2012, at 12:57 AM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release 1.4-M4. A bit late for xmas now :-). But early next year. Any issue ? Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: UserManager Impl choice via UI and ldap configuration
On 25/11/2012, at 4:54 AM, Olivier Lamy ol...@apache.org wrote: Hi Folks, I have recently changed some stuff to be able to dynamically change userManager impl used tru the UI (jdo or ldap) (see [1]). (and it works :-) ). Cool! Note this means user.manager.impl property from security.properties is not used anymore. I wonder if this property if here must win ? If you're storing it in a different configuration file, I think you should read the old config and populate the new (which wins after that) for easier upgrades. Furthermore, I'd like to improve a bit ldap configuration and add screens to configure dynamically (ldap server host/port, basedn etc...) (maybe ldap mapper too). In fact all content detailled here [2] must be configurable with the UI. Makes sense ? BTW more generally I wonder if we must continue read configuration from security.properties ? (too ease my hack I would say no :-) ) As above - please retain it, or at least migrate it to the new location; and make sure everything can be configured somewhere without the UI. I use that to lay down a fully functional Archiva without having to configure it by hand: https://github.com/maestrodev/puppet-archiva/blob/master/templates/security.properties.erb Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: P2 repository support
On 18/10/2012, at 9:03 AM, Olivier Lamy ol...@apache.org wrote: 2012/10/17 Jeff MAURY jeffma...@jeffmaury.com: Hello, having a lot of problems with Nexus OSS P2 support, I'm wondering if there is any work done or planned in order to support P2 repos in Archiva ? Also, is there a documentation about the internal architecture and extension points ? Currently no extensions point except writing a consumer which won't really help in your case. It's on my TODO list to review a bit the architecture to be able to write your own repository type. This need some refactoring as in some parts we are very maven centric :-). This was a clear goal of the refactoring I did some time back. There's still some Maven bits to extract as you say, but I don't think the API should significantly change. The first one is always the hardest... I know someone started to poke at doing this for Ivy but it was hard to proceed. Unfortunately I've struggled to find the time recently to finish up what I started, but of course I'm happy to answer questions or review any work towards it. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: P2 repository support
http://archiva.apache.org/ref/1.4-M3-SNAPSHOT/ On 23/10/2012, at 5:16 AM, Jeff MAURY jeffma...@gmail.com wrote: Hello, Apart from the code, is there some docs on the repository design (wiki,) Thanks Jeff Le 22 oct. 2012 08:23, Brett Porter br...@apache.org a écrit : On 18/10/2012, at 9:03 AM, Olivier Lamy ol...@apache.org wrote: 2012/10/17 Jeff MAURY jeffma...@jeffmaury.com: Hello, having a lot of problems with Nexus OSS P2 support, I'm wondering if there is any work done or planned in order to support P2 repos in Archiva ? Also, is there a documentation about the internal architecture and extension points ? Currently no extensions point except writing a consumer which won't really help in your case. It's on my TODO list to review a bit the architecture to be able to write your own repository type. This need some refactoring as in some parts we are very maven centric :-). This was a clear goal of the refactoring I did some time back. There's still some Maven bits to extract as you say, but I don't think the API should significantly change. The first one is always the hardest... I know someone started to poke at doing this for Ivy but it was hard to proceed. Unfortunately I've struggled to find the time recently to finish up what I started, but of course I'm happy to answer questions or review any work towards it. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: P2 repository support
On 23/10/2012, at 8:56 AM, Olivier Lamy ol...@apache.org wrote: Perso, The idea I have in mind is to remove some maven logic currently located in ArchivaDavResourceFactory to ManagedDefaultRepositoryContent. With adding some new methods in ManagedRepositoryContent to handle groups and special paths (./indexer). As it, all the logic will be in the ManagedRepositoryContent imll (can be maven or any other new repository type). Makes sense ? Yes to moving it out of the DAV section - that's definitely necessary. I'd just say it should move to metadata-repository-api rather than repository layer - I figured as things were decoupled that the old repository layer would go away. There's a storage package in metadata-repository-api that is already clean of Maven references (I hope!) - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Archiva instance on vmbuild.a.o
I've started moving things over, but not complete. I'll take care of it, but if you'd like to help accelerate it, let me know :) - Brett On 30/09/2012, at 12:50 AM, Olivier Lamy ol...@apache.org wrote: Hi, I just wonder if we could stop it and simply redirect to archiva-repository.a.o/archiva ? Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Volunteers for Apache Archiva instance
Yep. On 28/09/2012, at 1:41 AM, Olivier Lamy ol...@apache.org wrote: Hi Folks, As you know as part of our release process[1], we publish artifacts to people.a.o using scp. And this repository is sync to Maven central using rsync. INFRA folks like to avoid those rsync process from people.a.o. The solution was to moved to nexus. But as we like to eat our own dogfood :-), I propose to replace the rsync from people to a rsync from archiva-repository.a.o (there is a Archiva instance here I use for testing and releasing). (http://archiva-repository.apache.org/archiva/ ) INFRA will agree on that if we have some volunteers to help on maintenance/monitoring. Some of you are candidate to help ? Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] http://archiva.apache.org/developers/releasing.html -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Release to central
I think we should ask first if central will sync from archiva-repository for selected group IDs to accommodate (we are still within their forge policy). Failing that, we should rsync the content into r.a.o to be picked up, rather than deploying to nexus. That's a lot of manual double-work (and not dogfooding would not be an option). - Brett On 25/09/2012, at 6:04 PM, Olivier Lamy ol...@apache.org wrote: Hi, It looks rsync from /www/people.apache.org/repo/m2-ibiblio-rsync-repository to maven central is not anymore supported. (Don't ask me why I have some ideas but I prefer to not discuss on the topic.) So if we want our release going to central we have deployed releases to nexus. I will created jira entry for that. -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Release to central
On 26/09/2012, at 3:06 AM, Olivier Lamy ol...@apache.org wrote: Now artifacts are in central. 2012/9/25 Olivier Lamy ol...@apache.org: Quick update on that. In fact the rsync from people.a.o to central is still active (but was buggy) but it runs only once a day. (and I don't know when :-) ) Apologies if I conflated different messages on the topic. I was sure it had already been turned off on purpose. It still won't last much longer, so it would be good to see if our repo can be synced directly. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Future plans for archiva ?
Now that JIRA has labels, these are probably the best way to flag such things - that way they can span a number of releases but you can keep track of them all together. On 25/09/2012, at 3:39 AM, Eric Barboni eric.barb...@irit.fr wrote: Maybe we can create some roadmap entry like it was done for ui-rewrite just to maybe not bind to a numerical version. Was thinking on one for (repository API stuff + runtime plugin) . Another one for grouping thinks on auth (because of potential rewrite). -Message d'origine- De : Brett Porter [mailto:br...@porterclan.net] De la part de Brett Porter Envoyé : lundi 24 septembre 2012 06:34 À : dev@archiva.apache.org Objet : Re: Future plans for archiva ? Sorry for the delayed response, just picked up on this. Aside from the roadmap-level things Olivier and JB mentioned, in JIRA I think we did reasonably well of keeping things targeted to a good version. And anything not in a version should be responded to and put into one if appropriate. Triage is always a valuable thing to do... On 03/09/2012, at 9:59 PM, Eric Barboni eric.barb...@irit.fr wrote: As I am quite new to Archiva and as there are a lots of opened issues in Jira, I have not a clear opinion of what should be done. Seems that in a near future 1.4-M3 will be released for new UI rewrite. It seems that there will be a plugin way of supporting different repository type (more or less new Repository API ) (sounds great) AFAIK That the new big rewrite plan. Why not: doing also plugin mechanism for authentication provider (i.e. ldap) + configuration parameters in UI instead of in xml files ? Best Regards Eric PS: I keep playing with jdk 7 tests. -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: [VOTE] Archiva Parent 9 ans redback components
On 22/09/2012, at 12:18 AM, Olivier Lamy ol...@apache.org wrote: Hi, In order to move forward on releasing 1.4-M3, I'd like to start with releasing parent and redback components. Redback components has been moved from codehaus sources tree and repackage under org.apache.archiva.redback.components. The staged repository is here: https://archiva-repository.apache.org/archiva/repository/archiva-releases-stage/ Or with new UI :-) : https://archiva-repository.apache.org/archiva/index.html?request_lang=en#browse~archiva-releases-stage/org.apache.archiva Direct links to the source ZIPs would be appreciated for testing purposes :) A website is available too http://archiva.apache.org/redback/components/ (with at least javadoc some components have docs others not) Artifacts for this vote: * archiva parent 9 +1 * org.apache.archiva.redback.components:redback-components:2.0 (parent pom of all components) +1 * org.apache.archiva.redback.components:expression-evaluator:2.0 +1 * org.apache.archiva.redback.components:spring-apacheds:2.0 +1 * org.apache.archiva.redback.components.cache:spring-cache:2.0 (all sub modules included) +1 * org.apache.archiva.redback.components:spring-jdo2:2.0 +1 * org.apache.archiva.redback.components:spring-quartz:2.0 +1 * org.apache.archiva.redback.components.registry:spring-registry:2.0 (all sub modules included) +1 But the build fails if you don't have slf4j-simple 1.7.1 in your local repo - something to workaround. I've fixed on trunk. * org.apache.archiva.redback.components:spring-taskqueue:2.0 +1 * org.apache.archiva.redback.components:spring-utils:2.0 +1 Vote open for 72H [+1] [0] [-1] Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Future plans for archiva ?
Sorry for the delayed response, just picked up on this. Aside from the roadmap-level things Olivier and JB mentioned, in JIRA I think we did reasonably well of keeping things targeted to a good version. And anything not in a version should be responded to and put into one if appropriate. Triage is always a valuable thing to do... On 03/09/2012, at 9:59 PM, Eric Barboni eric.barb...@irit.fr wrote: As I am quite new to Archiva and as there are a lots of opened issues in Jira, I have not a clear opinion of what should be done. Seems that in a near future 1.4-M3 will be released for new UI rewrite. It seems that there will be a plugin way of supporting different repository type (more or less new Repository API ) (sounds great) AFAIK That the new big rewrite plan. Why not: doing also plugin mechanism for authentication provider (i.e. ldap) + configuration parameters in UI instead of in xml files ? Best Regards Eric PS: I keep playing with jdk 7 tests. -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Licence for dependencies in plugins
http://www.apache.org/legal/resolved.html#category-b It's fine, as long as it is only in binary form and any notices are adhered to. - Brett On 08/08/2012, at 1:35 AM, Adrien Lecharpentier adrien.lecharpent...@gmail.com wrote: Hi dev, I'd like to use a library for a plugin we're developing to add CUDF behavior in Archiva. This library is under Eclipse Licence ( http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/tree/p2/demos/misc-conf-2010/org.eclipse.equinox.p2.cudf) but is really needed. Is it completely forbidden to use such library? -- Adrien -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Welcome Eric Barboni as a new Archiva Committer
Great to have you on board! On 04/08/2012, at 4:52 PM, Olivier Lamy ol...@apache.org wrote: Hi, The Apache Archiva is pleased to announce Eric Barboni as a new Apache Archiva committer. Join me to welcome Eric (and happy hacking !) -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Docs for new UI
On 31/07/2012, at 6:46 PM, Olivier Lamy ol...@apache.org wrote:
Hi,
Currently we have a module archiva-docs with screenshots deployed to
http://archiva.apache.org/docs/${project.version}
(http://archiva.apache.org/docs/1.4-M2)
I'd like to start adding screenshots of new ui, I wonder the best strategy ? :
1) change current module with new ui screenshots
2) having a mix of both old and new ui screenshots
3) something else
My preference could go to 1) as (at least I hope :-) ) we will
maintain only the new ui in the future.
+1 I'm happy for us to commit to the new UI as a default for 1.4.
- Brett
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
Re: Moving distributions to svnpub
We have to eventually, right? :) Thanks for sorting it out. On 31/07/2012, at 4:51 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: +1 It makes sense Regards JB On 07/30/2012 06:45 PM, Olivier Lamy wrote: Hi, Any objections if we move release distribution to svnpub ? Thanks, -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: 1.4-M3 Release ?
On 10/07/2012, at 3:38 AM, Olivier Lamy wrote: Hi, I'd like to start the release process for a 1.4-M3 (including the new UI !!). Any objections ? Great! I will start that around end of july (need vacations first :-) ). (yes Brett French folks has a lot :P ). :D As this release will need to release a LOT of stuff (redback core/components now imported in asf scm), I wonder what is the best strategy: * release redback components then call a vote, release redback core then call a vote, release archiva then call a vote. * release everything in one block then call a vote Perso I prefer 2nd mode (can be faster) I think that makes sense. Do the components need to be separate releases, or should they just be folded in as 1.4-M3-SNAPSHOT as well since they are under the Archiva group? Also, should the relevant parts of the red back site be folded into Archiva's? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/
Re: svn commit: r1357890
On 06/07/2012, at 7:15 PM, Olivier Lamy wrote: I understand the company copyright issue. But if I read that http://www.apache.org/licenses/LICENSE-2.0#apply There is a Copyright [] [name of copyright owner] ?? That describes how another projects using the Apache License should apply the headers. For code contributed to the ASF, this is the policy: http://www.apache.org/legal/src-headers.html In particular: -- If the source file is submitted with a copyright notice included in it, the copyright owner (or owner's agent) must either: • remove such notices, or • move them to the NOTICE file associated with each applicable project release, or • provide written permission for the ASF to make such removal or relocation of the notices. -- Having permission to remove the header below avoids us having to maintain the duplicate. - Brett 2012/7/6 Olivier Lamy ol...@apache.org: Ouch yes sorry I didn't check that !! My bad. I will. 2012/7/6 Brett Porter br...@apache.org: On 06/07/2012, at 6:43 AM, ol...@apache.org wrote: +/* + * Copyright 2012 Zenika + * + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ Can we request the submitter replace these license headers? - Brett
Re: svn commit: r1357890
On 06/07/2012, at 7:33 PM, Adrien Lecharpentier wrote: Hello, Ok, this is my mistake. I'm making the new patch with some tests fixe from the original patch. Thanks - is much appreciated! -- Adrien Lecharpentier 2012/7/6 Brett Porter br...@apache.org On 06/07/2012, at 7:15 PM, Olivier Lamy wrote: I understand the company copyright issue. But if I read that http://www.apache.org/licenses/LICENSE-2.0#apply There is a Copyright [] [name of copyright owner] ?? That describes how another projects using the Apache License should apply the headers. For code contributed to the ASF, this is the policy: http://www.apache.org/legal/src-headers.html In particular: -- If the source file is submitted with a copyright notice included in it, the copyright owner (or owner's agent) must either: • remove such notices, or • move them to the NOTICE file associated with each applicable project release, or • provide written permission for the ASF to make such removal or relocation of the notices. -- Having permission to remove the header below avoids us having to maintain the duplicate. - Brett 2012/7/6 Olivier Lamy ol...@apache.org: Ouch yes sorry I didn't check that !! My bad. I will. 2012/7/6 Brett Porter br...@apache.org: On 06/07/2012, at 6:43 AM, ol...@apache.org wrote: +/* + * Copyright 2012 Zenika + * + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ Can we request the submitter replace these license headers? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/
Re: Stop 1.5 support ?
Ok with me. On 15/06/2012, at 8:06 AM, Olivier Lamy wrote: Hi, I wonder if we must continue supporting 1.5 ? As we use CXF now, we are not able to use last version as this doesn't support 1.5 now. WDYT ? Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
issues list
Hi, The issues list wasn't getting mail since Codehaus upgraded JIRA (https://jira.codehaus.org/browse/HAUS-2232). I've now fixed it, but you might want to skim the project to see if any issues were filed in the last week or so. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: folding Redback into Archiva ?
Thanks Olivier. A few things... - It usually says officer or member responsible - if the template changed to just officer, it should be Deng - would be better to use mail-archives + s.apache.org as the link to this thread for acceptance - it might be good to checksum the tarball Cheers, Brett On 04/04/2012, at 12:59 AM, Olivier Lamy wrote: Done mail thread incubator@ http://markmail.org/message/pluumnrljzlzsvui Ip clearance: http://incubator.apache.org/ip-clearance/redback.html 2012/4/3 Olivier Lamy ol...@apache.org: Hello, As no objections :-), I will prepare ip clearance papers and then import code. Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy 2012/3/29 Olivier Lamy ol...@apache.org: Hello, Sorry for cross posting. I'd like to restart an old thread (see http://markmail.org/thread/g7czzsyvie6xhket ) So what do you think about forking redback stuff to Archiva svn tree ? (I mean not importing svn history) http://svn.codehaus.org/redback/redback/ - http://svn.apache.org/repos/asf/archiva/redback/redback-core http://svn.codehaus.org/redback/components/ - http://svn.apache.org/repos/asf/archiva/redback/redback-components And changing various namespaces (groupId to org.apache.archiva.redback and root package too). BTW I will take about ip clearance. WDYT ? Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Regarding A Project Idea for GSOC 2012
We hadn't to this point, but we have done so in the past. I'm happy to mentor if we have a suitable project idea. What is it about Archiva that attracts you to working on it? On 18/03/2012, at 5:17 PM, Kasun Siriwardhana wrote: Dear Sir, Madam, I am a undergraduate in University of Colombo ,Sri Lanka. I have an idea to participate in Google Summer of Program in this summer.And I am still in the phase of research for a project idea which suits for my capabilities. (Since i have not expertise lot of technologies). But I have some experiences in programming in java , j2ee, Struts , Spring (MVC and DI), Grails as well as the build tools like maven , ant , svn , git. I would like to get more information if the development team of apache archiva is planing to involve with the gsoc program in this summer. Thanks. Kasun Siriwardhana -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: [RFC] New UI
I've upgraded my personal version and will try it for a while to see how it goes. Thanks! - Brett On 15/03/2012, at 9:16 PM, Olivier Lamy wrote: Hello, I made some progress on the new UI. You can test it with the following build https://builds.apache.org/view/A-F/view/Archiva/job/archiva-all-maven-3.x-jdk-1.6/lastSuccessfulBuild/artifact/archiva/archiva-jetty-js/target/apache-archiva-js-1.4-M3-SNAPSHOT-bin.zip . Currently it's based on a jetty container (without anymore jsp support) and the current limited wrapper. I'd like to have something based on Tomcat and commons-daemon (for better support of 64 platforms). Regarding the UI, the top task is here: https://jira.codehaus.org/browse/MRM-1497 (have a look at various sub tasks). The TODOs list is: * more selenium tests * artifact info details screens (something I will work in the coming days) * other subtasks * more selenium tests * and last but not least more selenium tests ( :-) ) I'd like to have your impressions on this new UI (feel free to add sub task) Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: svn commit: r1234700 - in /archiva/trunk: archiva-docs/src/site/site.xml archiva-modules/archiva-web/archiva-webapp-js/src/site/site.xml
Should this be used for archiva-modules top level site instead of just the -js? and the main site as well... currently it uses stylus in the parent. - Brett On 23/01/2012, at 7:34 PM, ol...@apache.org wrote: Author: olamy Date: Mon Jan 23 08:34:50 2012 New Revision: 1234700 URL: http://svn.apache.org/viewvc?rev=1234700view=rev Log: fluido skin 1.1 Modified: archiva/trunk/archiva-docs/src/site/site.xml archiva/trunk/archiva-modules/archiva-web/archiva-webapp-js/src/site/site.xml Modified: archiva/trunk/archiva-docs/src/site/site.xml URL: http://svn.apache.org/viewvc/archiva/trunk/archiva-docs/src/site/site.xml?rev=1234700r1=1234699r2=1234700view=diff == --- archiva/trunk/archiva-docs/src/site/site.xml (original) +++ archiva/trunk/archiva-docs/src/site/site.xml Mon Jan 23 08:34:50 2012 @@ -28,7 +28,7 @@ skin groupIdorg.apache.maven.skins/groupId artifactIdmaven-fluido-skin/artifactId -version1.0/version +version1.1/version /skin publishDate format=-MM-dd position=right / Modified: archiva/trunk/archiva-modules/archiva-web/archiva-webapp-js/src/site/site.xml URL: http://svn.apache.org/viewvc/archiva/trunk/archiva-modules/archiva-web/archiva-webapp-js/src/site/site.xml?rev=1234700r1=1234699r2=1234700view=diff == --- archiva/trunk/archiva-modules/archiva-web/archiva-webapp-js/src/site/site.xml (original) +++ archiva/trunk/archiva-modules/archiva-web/archiva-webapp-js/src/site/site.xml Mon Jan 23 08:34:50 2012 @@ -28,7 +28,7 @@ skin groupIdorg.apache.maven.skins/groupId artifactIdmaven-fluido-skin/artifactId -version1.0/version +version1.1/version /skin publishDate format=-MM-dd position=right / -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: i18n in new UI?
On 23/01/2012, at 8:04 PM, Olivier Lamy wrote: Hello, I have started some doc (really work in progress :-) ). I will basically focus on provided documentation with code samples. Resource bundle are loaded only once when user go to the application. For static content some explanations can be read here (http://people.apache.org/~olamy/archiva/docs/ref/1.4-M3-SNAPSHOT/archiva-web/archiva-webapp-js/template-loading.html) Ok, I think I'll need to look closer at the js webapp overall to see how it fits together. By default locale is the browser locale except if you have the query parameter ?request_lang=en (due to my bad experience with selenium tests which failed on my fr machine I did that to be able to force locale :-) ). 2012/1/23 Brett Porter br...@apache.org: Hi, I haven't had time to wade through all the UI changes yet, but in fixing the JDK 5 compatibility problem this morning, I saw that there is a class serving all the i18n resources over REST, which are then used in jquery. I'm curious how this architecture works? My expectation would have been that there are no localized strings in the static content (HTML/JS), and that the REST calls would return localized content as requested. Where are the keyed requests coming from? Also, how does this perform with caching and behave with allowing users to select the locale? I did notice that the call generating it is potentially quite inefficient. There are 2 calls to convert properties to a string (one for redback, which has subcalls, one for archiva), which both converted back to properties, merged and then back to a string. I'd hope the resource bundles could just be loaded once (presuming they can be updated as may be needed in an OSGi scenario later). I miss you here :-). There is only on rest call. I have tried to reuse redback i18n. There are two properties load (one in en and an other one in the request locale except if en is the default). Note it's more 2*2 (redback then archiva) In DefaultCommonServices.getAllI18nResources( locale ): - redback properties are loaded and converted to string - archiva properties are loaded and converted to string - redback string is converted back to properties - archiva string is converted back to properties and added to the same properties instance - the combined properties is converted back to a string The class just seemed very confusing - it would be better to just gather all the required properties in one instance, then write them out to the request with properties.store()? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: svn commit: r1234639 - /archiva/trunk/archiva-modules/archiva-web/archiva-rest/archiva-rest-services/src/main/java/org/apache/archiva/rest/services/DefaultCommonServices.java
On 23/01/2012, at 10:55 AM, Olivier Lamy wrote: Thanks Brett ! I tried animal sniffer to prevent that but have a weird issue and didn't get time to investigate. see https://gist.github.com/1659445 In the test repository, there are fake files - so that's a 0-byte JAR, just to test there being a file there. it probably should be an empty JAR instead of a 0-byte file. But animal sniffer shouldn't be trying to check signatures on that stuff anyway - it's just that it's in target/classes so it can be easily JARred and reused. I think I'll change the test-repository to a ZIP which is more correct (the faster solution would be to skip animal sniffer in that project, which I can also do). - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
i18n in new UI?
Hi, I haven't had time to wade through all the UI changes yet, but in fixing the JDK 5 compatibility problem this morning, I saw that there is a class serving all the i18n resources over REST, which are then used in jquery. I'm curious how this architecture works? My expectation would have been that there are no localized strings in the static content (HTML/JS), and that the REST calls would return localized content as requested. Where are the keyed requests coming from? Also, how does this perform with caching and behave with allowing users to select the locale? I did notice that the call generating it is potentially quite inefficient. There are 2 calls to convert properties to a string (one for redback, which has subcalls, one for archiva), which both converted back to properties, merged and then back to a string. I'd hope the resource bundles could just be loaded once (presuming they can be updated as may be needed in an OSGi scenario later). Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: UI refactoring
On 13/01/2012, at 7:14 PM, Olivier Lamy wrote: Hello, To follow up on this topic. It looks I have made some progress on this part :-). You can have a look at this capture: http://screencast.com/t/dEPpB3rzk Cool :) Most of needed redback screen are implemented (still missing reset password). You can test on trunk running (on top directory): mvn tomcat:run -pl :archiva-webapp-js -am -Pjs -Pdev -am I have created a top jira entry http://jira.codehaus.org/browse/MRM-1497 (with sub task for each page/screen to rewrite). Do not hesitate to add if I missed some. Is there a reason you created a new version? Should be part of 1.4 since it's on trunk, and maybe have ui-rewrite as a label? So now I have to document how it works :-). Do you prefer wiki/confluence page or a something in the archiva web site ? Fine either way... website would mean part of the doxia site inside webapp-js, right? Last time we talked about this, Deng preferred confluence and I preferred the doxia site (more recently, I'm writing all this sort of thing in Markdown (either as a README.md, or as part of a doxia site since that works now). We should choose one and move the remaining docs there. Do you have a preference? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Archiva memory settings and stability
On 05/01/2012, at 7:08 PM, Olivier Lamy wrote: 2012/1/5 Brett Porter br...@apache.org: Hi, In MRM-1549, the -Xms was increased to 512m. This is very high for a starting point - would it be better to use the default settings, but let it grow to the upper setting? It is quite costly on memory when I run it on my local machine. Not xmas RAM ? :-) Hehe, no problem on the main machine (except for the VMs it has going too), but it's more useful on the laptop when I'm offline and need to conserve RAM and CPU... :) A couple of years back I did a lot of profiling to try and get it as lean as possible, so that we could run a minimal instance - this is something I'd like to do again before 1.4. Between the large number of classes to load and other memory use it's becoming impractical to run that way again :) I usually like having -Xms to prevent later slower allocation. But as it's something easily configurable: no problem. Understood - maybe we should also really consider again two distributions (minimal proxy full application). I guess I can tweak the settings locally as well. BTW removing xmlrpc will decrease number of loaded classes. (and moving to a plain html/js will remove struts classes loading too: more longer task :-) ). Right... Also, I've noticed that the latest milestones are still not very stable on vmbuild, restarting once or twice a day. Is anyone else seeing similar problems? No I'm not aware of that. Any logs or stacktrace or dump available ? I need to poke at it some more (I think you also have access still?). I think it's just a lot of GC but I could be wrong. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Archiva memory settings and stability
Hi, In MRM-1549, the -Xms was increased to 512m. This is very high for a starting point - would it be better to use the default settings, but let it grow to the upper setting? It is quite costly on memory when I run it on my local machine. A couple of years back I did a lot of profiling to try and get it as lean as possible, so that we could run a minimal instance - this is something I'd like to do again before 1.4. Between the large number of classes to load and other memory use it's becoming impractical to run that way again :) Also, I've noticed that the latest milestones are still not very stable on vmbuild, restarting once or twice a day. Is anyone else seeing similar problems? Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Archiva memory settings and stability
On 05/01/2012, at 5:57 PM, Jean-Baptiste Onofré wrote: Hi Brett, I didn't see the issue in Karaf as Karaf already tunes the JVM memory configuration. Can you elaborate on this? I presume it has more efficient class loading, but otherwise would be the same. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: svn commit: r1213916 - /archiva/branches/1.4-M2-RC/archiva-modules/archiva-base/pom.xml
Is there a reason that matters? Maven should figure it out... On 14/12/2011, at 7:29 AM, ol...@apache.org wrote: Author: olamy Date: Tue Dec 13 20:29:48 2011 New Revision: 1213916 URL: http://svn.apache.org/viewvc?rev=1213916view=rev Log: reorder module build archiva-consumers need indexer Modified: archiva/branches/1.4-M2-RC/archiva-modules/archiva-base/pom.xml Modified: archiva/branches/1.4-M2-RC/archiva-modules/archiva-base/pom.xml URL: http://svn.apache.org/viewvc/archiva/branches/1.4-M2-RC/archiva-modules/archiva-base/pom.xml?rev=1213916r1=1213915r2=1213916view=diff == --- archiva/branches/1.4-M2-RC/archiva-modules/archiva-base/pom.xml (original) +++ archiva/branches/1.4-M2-RC/archiva-modules/archiva-base/pom.xml Tue Dec 13 20:29:48 2011 @@ -36,8 +36,8 @@ modulearchiva-checksum/module modulearchiva-plexus-bridge/module modulearchiva-policies/module -modulearchiva-consumers/module modulearchiva-indexer/module +modulearchiva-consumers/module modulearchiva-repository-layer/module modulearchiva-xml-tools/module modulearchiva-proxy-common/module @@ -49,4 +49,4 @@ modulearchiva-repository-admin/module modulearchiva-security-common/module /modules -/project \ No newline at end of file +/project -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: [VOTE] Apache Archiva 1.4-M2
+1, with reservations Separated installation and configuration (ARCHIVA_BASE) won't work under some installations due to tmpdir being set incorrectly. I'm fixing now, and probably not critical to re-release, but worth noting in the announcement. I checked the signature on the source bundle and tested building it. There were intermittent test failures, but overall they did pass. I also upgraded vmbuild.a.o/archiva - Brett On 15/12/2011, at 9:12 AM, Olivier Lamy wrote: Hello, I'd like to release Apache Archiva 1.4-M2. We fixed 23 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17842styleName=TextprojectId=10980Create=Create Staging repository is available here: http://vmbuild.apache.org/archiva/repository/archiva-releases-stage/ Documentation: http://archiva.apache.org/docs/1.4-M2/ (wait sync) Builds are available here: http://people.apache.org/builds/archiva/1.4-M2/ Vote open for 72H. [+1] [0] [-1] Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Removing xmlrpc services in trunk
Ok with me. - Brett On 17/12/2011, at 12:36 AM, Olivier Lamy wrote: Hello, As now we have some REST services (in both redback and archiva), any objections to remove xmlrpc services ? This will reduce the number of jars we have in our distro and reduce the code to maintain. Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: Building fails in Consumers Archetype
] Downloading: file:///home/pablaasmo/.m2/repository/org/apache/maven/plugins/maven-plugins/18/maven-plugins-18.pom [INFO] Downloaded: file:///home/pablaasmo/.m2/repository/org/apache/maven/plugins/maven-plugins/18/maven-plugins-18.pom (13 KB at 2539.3 KB/sec) [INFO] Downloading: file:///home/pablaasmo/.m2/repository/org/apache/maven/maven-parent/16/maven-parent-16.pom [INFO] Downloaded: file:///home/pablaasmo/.m2/repository/org/apache/maven/maven-parent/16/maven-parent-16.pom (23 KB at 5681.6 KB/sec) [INFO] Downloading: file:///home/pablaasmo/.m2/repository/org/apache/apache/7/apache-7.pom [INFO] Downloaded: file:///home/pablaasmo/.m2/repository/org/apache/apache/7/apache-7.pom (15 KB at 4697.3 KB/sec) [INFO] Downloading: file:///home/pablaasmo/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.jar [INFO] Downloaded: file:///home/pablaasmo/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.jar (23 KB at 5749.3 KB/sec) [INFO] Downloading: file:///home/pablaasmo/.m2/repository/org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.pom [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.4.3/maven-resources-plugin-2.4.3.pom [INFO] [INFO] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] [INFO] [INFO] Total time: 0.479s [INFO] [INFO] Finished at: Mon Nov 28 14:01:15 CET 2011 [INFO] [INFO] Final Memory: 3M/179M [INFO] [INFO] [INFO] [ERROR] Plugin org.apache.maven.plugins:maven-resources-plugin:2.4.3 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.4.3: Could not transfer artifact org.apache.maven.plugins:maven-resources-plugin:pom:2.4.3 from/to central (http://repo1.maven.org/maven2): Error transferring file: Connection refused - [Help 1] [INFO] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-resources-plugin:2.4.3 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.4.3 -- Per Arnold Blåsmo Senior Design Engineer, Atmel Norway Tel: (+47) 72897-651 / Mobile: (+47) 901-63-657 / Fax: (+47) 72-88-43-99 e-mail: per-arnold.blaa...@atmel.com / g-talk: pablaa...@gmail.com / www.atmel.com The information contained in this email message may be privileged, confidential and/or protected from unauthorized disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. Please immediately notify the sender by reply if you received this email in error. Thank you for your cooperation. -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
regular build failures
Hi, I'm guessing Olivier can help with this. The builds regularly fail with this: Nov 16, 2011 6:07:13 AM hudson.remoting.Channel$ReaderThread run SEVERE: I/O error in channel channel java.io.StreamCorruptedException at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1332) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1087) channel stopped Destroying 1 processes Destroying process.. Destroyed 1 processes ERROR: Maven JVM terminated unexpectedly with exit code 0 Is that a Jenkins problem, or is Maven dying due to some other constraint (like, OOME)? It's a pain to get failures all the time when nothing is broken. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/
Re: Broken unit tests and Jira location
On 13/11/2011, at 9:45 AM, Olivier Lamy wrote: 2011/11/13 Jean-Baptiste Onofré j...@nanthrax.net: Hi guys, I completed the first step for OSGi support in Archiva (Karaf features) yesterday evening. However, I saw that the unit tests are broken in the archive-rest-services. I'm checking it and I will submit a patch for that. My bad. I have just fixed that. I raised: http://jira.codehaus.org/browse/MRM-1557 I have another quick question. Currently our Jira is hosted at Codehaus. As Archiva is an Apache projects, do we plan to move the Jira to the main Apache one ? We already discussed about that long ago. Recently I work with mark @asf to import a jira a project (tomcat maven plugin). It was not too complicated with using swizzle. I can take the point: get a dump with swizzle and ask for a load @asf jura. I had been working with Ben for some time to get a dump out of codehaus so we could do that. Does swizzle retain everything? What happens to issue keys, etc.? I am half-way inclined to start a new JIRA project at Apache and use that for 1.4 release onwards. A clean start might help us focus on what is important to our current users, and we can change the issue key that way. I still haven't convinced myself it's a good idea yet though :) - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/
dropping Maven 2 build support
On Jenkins, the Maven 2.x builds are chronically broken. I suggest we should just require Maven 3 to build - anyone object? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/
Re: [RESULT] [VOTE] Apache Archiva 1.4-M1
BTW, I put back 1.3.5 to the distribution area today, and on the site earlier (Without realising it had been removed). IMO - we should keep pushing that as the stable version until the milestones have had some more testing. - Brett On 26/10/2011, at 6:39 PM, Olivier Lamy wrote: Hello, The vote has passed with the following result: +1 (binding): Maria Odea B. Ching, Brett Porter, Olivier Lamy +1 (non binding): Jean-Baptiste Onofre I will continue the release process. Thanks, -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: [VOTE] Apache Archiva 1.4-M1 release
+1 Checked the signature, built the source and upgraded my local instance. I think we still need to tune the performance some more - but regular milestone releases are a good place to start :) - Brett On 19/10/2011, at 1:03 AM, Olivier Lamy wrote: Hello, I'd like to release Apache Archiva 1.4-M1. We fixed 126 issues: http://s.apache.org/se The staged repo is here: http://vmbuild.apache.org/archiva/repository/staged-archiva/ Various build are available here: http://people.apache.org/builds/archiva/1.4-M1/ . Docs are available http://archiva.apache.org/docs/1.4-M1 Release Notes: http://archiva.apache.org/docs/1.4-M1/release-notes.html [+1] [0] [-1] Here my +1. Thanks -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: 1.4-M1 Release
I'm ok with releasing now, but we should probably limit how much we advertise it at first. I'd really like to do some more exhaustive testing on the metadata repository with a large repository. Each milestone can go a bit wider if we release regularly. I updated the release notes. I noted that the new style has some glitches though - like the pre-formatted inline text is not a fixed width? - Brett On 12/10/2011, at 2:17 AM, Olivier Lamy wrote: So only 4 issues left. Do we move those to 1.4-M2 ? (as this release include some changes we will have probably some issues to fix not too much I hope :-) ). I have started working on the release notes: http://people.apache.org/~olamy/archiva/docs/1.4-M1-SNAPSHOT/release-notes.html (btw jira issues not included as I'm not sure about the 4) I will release redback to not have any more snapshot deps. WDYT ? 2011/9/26 Deng Ching och...@apache.org: On Mon, Sep 26, 2011 at 6:46 AM, Olivier Lamy ol...@apache.org wrote: 2011/9/25 Deng Ching och...@apache.org: On Sun, Sep 25, 2011 at 4:41 AM, Olivier Lamy ol...@apache.org wrote: Hello, I'd like to release a 1.4-M1 within weeks (2/3). So certainly some jira will be move from 1.4-M1 to M2. I have started some release on dependencies we have : * on Maven land (vote for maven-indexer started, next week will start a release for wagon) * redback : no problem to wait a vote :-) * jackarabbit : will be next week (see http://markmail.org/message/uk2g7qqshbojrl7q ) I will work on a nice feature I'd like to see in this release (https://jira.codehaus.org/browse/MRM-1524 ). Then some docs especially on REST services (see http://archiva.apache.org/docs/1.4-SNAPSHOT/adminguide/webservices/rest.html ) I like the idea about using snippet from unit tests) The previous xmlrpc services are still there right? Yes unit test still working even in redback. I like to deprecate those and remove those in future releases. Let me know if it looks fine ? Looks good to me :) If there's anything I can help out with, just let me know.. Maybe you can navigate in jira and see if you can fix issues open marked with fix version 1.4-M1 :-) Ok, I'll try to work on some of the issues there :) Thanks, Deng -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Cleanup of staged repo on vmbuild for the coming release
On 28/09/2011, at 12:28 AM, Olivier Lamy wrote: Hello, I'm not sure I have enough karma to deploy to: http://vmbuild.apache.org/archiva/repository/staged-archiva . BTW this staged repo still contains a 1.3.5 release. Is-it possible to: * ensure I have enough karma to deploy to the staged repo. * cleanup this stage repo which contains an already released version. Both done. I will probably release parent and archive both in the same time: no issue with that ? No issue, though it might be easier to just release the parent up front. We don't actually have multiple things released from the parent so maybe it's just better to fold it back in again? Is the list in 1.4-M1 the target now or were you aiming to push more things to M2? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: 1.4-M1 Release
Sounds like a good timeframe. I'll try and get more of the stuff assigned to me cleaned up :) On 25/09/2011, at 6:41 AM, Olivier Lamy wrote: Hello, I'd like to release a 1.4-M1 within weeks (2/3). So certainly some jira will be move from 1.4-M1 to M2. I have started some release on dependencies we have : * on Maven land (vote for maven-indexer started, next week will start a release for wagon) * redback : no problem to wait a vote :-) * jackarabbit : will be next week (see http://markmail.org/message/uk2g7qqshbojrl7q ) I will work on a nice feature I'd like to see in this release (https://jira.codehaus.org/browse/MRM-1524 ). Then some docs especially on REST services (see http://archiva.apache.org/docs/1.4-SNAPSHOT/adminguide/webservices/rest.html) I like the idea about using snippet from unit tests) Let me know if it looks fine ? Thanks, -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: http://jira.codehaus.org/browse/MRM-1173
Looks like some Javascript in proxyConnectorForm.jspf On 19/09/2011, at 7:19 AM, Benson Margulies wrote: This looks about my size. Could someone point me at where to start reading? -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: things to work on
On 16/09/2011, at 8:58 AM, Benson Margulies wrote: http://jira.codehaus.org/browse/MRM/fixforversion/17269 justs three things. Hehe, JIRA is showing the top 3 in the list - if you click the eyeball there were 33. I confess. The one with the missing class I don't understand how to repro. I think Olivier already said he'd look at that. The one with the cookie is a nasty, complex, mess dating back to 2008. How does it block a release? I'd brought it forward because I had a lead on it in May, but I can push it back . The one with the redirect problem, well, I might be able to chew on it, but is it really a blocker either? Like several others in the list - these all need testing because I believe they've been fixed by upgrading Wagon, then they can be closed (if there's still a problem, it could be pushed out). - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Unit test failure in current trunk
What's the surefire output say? It's ok here, and in several CI environments. - Brett On 12/09/2011, at 10:28 PM, Benson Margulies wrote: On my mac ... is this expected? Tests in error: testStoreConfigurationUser(org.apache.maven.archiva.configuration.ArchivaConfigurationTest): Configuration can not be saved when it is loaded from two sources Tests run: 37, Failures: 0, Errors: 1, Skipped: 0 -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Unit test failure in current trunk
Checkout clean of any old target files? Same result run in an IDE? What about if you build the 1.3.5 sources (that code hasn't changed in a long time)? I can't see what would cause this without stepping in with a debugger. - Brett On 12/09/2011, at 11:05 PM, Benson Margulies wrote: On Mon, Sep 12, 2011 at 9:01 AM, Brett Porter br...@apache.org wrote: What's the surefire output say? It's ok here, and in several CI environments. The -output file is completely dull. - Brett On 12/09/2011, at 10:28 PM, Benson Margulies wrote: On my mac ... is this expected? Tests in error: testStoreConfigurationUser(org.apache.maven.archiva.configuration.ArchivaConfigurationTest): Configuration can not be saved when it is loaded from two sources Tests run: 37, Failures: 0, Errors: 1, Skipped: 0 -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Archiva issue with LDAP (MRM-1488)
Did you do this with ehcache or the technique Brent outlined? If it's the former, I'm worried about it not closing the resources - we should test it with a lot of concurrent different users. On 26/08/2011, at 12:57 PM, Deng Ching wrote: I made some changes to the impl, btw. Instead of just caching the ldap users, I've also cached the ldap connections. Not all ldap servers return a hashed password (some return just a masked string, eg. **) for the userPassword attribute of an ldap user so we can't do a comparison on it. You need to bind to the ldap server to authenticate, so I just cached the ldap connection of a user. For the ldap connections, I've set the TTL to 15secs., then 2 mins. TTL for the ldap users. I ran a 'clean install' on archiva-parent against an Archiva repo using JDO and LDAP for authentication, and these are the results: - JDO: 7:04.998s - LDAP: 7:17.382s Thanks, Deng On Thu, Aug 25, 2011 at 10:07 AM, Deng Ching och...@apache.org wrote: On Thu, Aug 25, 2011 at 1:44 AM, Brent Atkinson brent.atkin...@gmail.comwrote: Hi everyone, I actually ran into this when fixing the connection leaks. I realized it was probably building in too many assumptions, but I created and held onto the LdapCtxFactory in redback's LdapConnection for a very specific reason: connection pooling. The sun JNDI ldap implementation can pool connections sharing the same credentials *and config options* as long as they are created from the same LdapCtxFactory. http://download.oracle.com/javase/jndi/tutorial/ldap/connect/pool.html Thanks Brent! We'll look into that. On Wed, Aug 24, 2011 at 8:57 AM, Wendy Smoak wsm...@gmail.com wrote: On Wed, Aug 24, 2011 at 2:45 AM, Deng Ching och...@apache.org wrote: We're planning to use EhCache for this so we can also set a TTL (time-to-live) for the cached objects. A password change done from the webapp would flush the user in the cache. If you're using LDAP, would users be doing password changes from the webapp? Making that TTL configurable by the admin would be good, then they can trade off between extra calls to LDAP and 'how come my new password doesn't work?'. Agreed. We'll add this functionality as well :) Thanks, Deng -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Archiva issue with LDAP (MRM-1488)
On 24/08/2011, at 4:45 PM, Deng Ching wrote: Hi, Jev and I are currently working on MRM-1488 (Using Archiva as proxy for downloading artifacts is very slow when used with LDAP authentication). The problem we saw here was that for each artifact request, authentication happens which in turn results to a call to the LDAP server. To fix this, we're planning to use an in-memory cache for the LDAP credentials. For every authentication request made, Redback will: 1. look for the user in the cache 2. if user is found in the cache, compare credentials - if it matches, return successful - if it doesn't match, reject it The credentials will only be there if you've stored them from a previous request as you can't get them back out of LDAP. You'll certainly want to hash this and compare the hash rather that storing the cleartext/base64 password in memory. 3. if user is not found in the cache - retrieve user from LDAP server - check provided credentials against the retrieved user - if it matches, return successful and add retrieved user to the cache - if it doesn't match, reject it The current code looks for the user, doesn't get any details, then tries authentication. This is presumably to check it matches the filter. It'd be good to check if we can do that ourselves, or as part of the authenticate call, rather than retrieving the user for the authn step. Are you doing this at the redback level, similar to the keys/rbac/users caching? We're planning to use EhCache for this so we can also set a TTL (time-to-live) for the cached objects. I think Olivier recently changed the caching strategy in trunk, so we should stick with that. A password change done from the webapp would flush the user in the cache. Also, in the logs, we've noticed a number of calls to the LDAP server (search for users then authenticate) which may not be necessary so we'll also check if we can improve those. Any thoughts or comments? Thanks, Deng -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: [vote] opening Archiva sandbox to other Apache committers
This vote has passed with 8 x +1 votes: Brett, Olivier, Jean-Baptiste (not currently a committer), Fabrice, Deng, James, Wendy, Dennis. I'll look into the permissions. Cheers, Brett On 19/08/2011, at 6:00 PM, Brett Porter wrote: Some other Apache committers have expressed interest in doing some experiments with Archiva, and I thought the most helpful way to enable that would be to open the sandbox to all Apache committers, as some other projects have done. I believe in general we should have a low barrier to entry for those that can help, and this is one way to enable with that. I'd expect we would vote for them to be Archiva committers if the work is adopted or they want to help with other things. I'll close this vote after 72h or a majority of committers vote affirmative: [ ] +1 open the sandbox to all Apache committers [ ] 0 abstain [ ] -1 Thanks, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Archiva refactoring
On 20/08/2011, at 3:33 AM, Olivier Lamy wrote: Is this duplication of remote type code, or business logic? I would have thought the actual remote stuff would be a pretty thin layer, and that most would live in search or the repository API, or a repository admin API (which is probably a combination of the current configuration module + the code that is in the web app now) dupe are wrappers and some thin logic (bean/datas validation too). Have a look at the addManagedRepo part in webapp and xmlrpc (and now in rest part :-) ) BTW not critical or a big issue just a cleanup to do :-). That's why I wanted to move some of those dups in a new module (archiva-remote-layer ? Maye I'm not really good enough in marketing to find the good name :-) ) Let me know A lot of this particular one is staging, which I aim to reduce (I'm part way through removing the additional managed repository configuration as it should be implicit). I do think most of this is the repository admin, so a repository admin API would make sense… ManagedRepositoryAdmin.createManagedRepository(…) ManagedRepositoryAdmin.deleteManagedRepository(…) RemoteRepositoryAdmin.create... … etc. That's instead of calling it a remote layer - because a lot of this has nothing to do with being remote (except that a user requested it… but a Java app embedding Archiva could request these too). The tricky bit is perhaps that security is isolated to the web modules at the moment, and these modules to cover security operations too - these could either stay in the current code (if it's a 1-liner), or be added to archiva-security I guess. Does that make sense? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
[vote] opening Archiva sandbox to other Apache committers
Some other Apache committers have expressed interest in doing some experiments with Archiva, and I thought the most helpful way to enable that would be to open the sandbox to all Apache committers, as some other projects have done. I believe in general we should have a low barrier to entry for those that can help, and this is one way to enable with that. I'd expect we would vote for them to be Archiva committers if the work is adopted or they want to help with other things. I'll close this vote after 72h or a majority of committers vote affirmative: [ ] +1 open the sandbox to all Apache committers [ ] 0 abstain [ ] -1 Thanks, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
snapshots publishing to Archiva
Hi, I've configured the CI builds for trunk to publish snapshots to http://vmbuild.apache.org/archiva/repository/snapshots Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: using archiva as a p2 repository
On 18/08/2011, at 5:53 AM, Johannes Utzig wrote: Sorry for the long background story, but now finally to my questions. I'd greatly appreciate if somebody could help me out with these: 1. I think this would be a very helpful feature for users of tycho and archiva and I'd like to make this (once finished) available as open source. I was wondering if this is something you'd be interested in hosting directly as an apache archive component Yes! Is it against 1.3.x or trunk? 2. I could not find a way in the consumer API to determine if the 'Process All Artifacts' checkbox in 'admin/repositories.action' was activated before the scan got triggered. A full scan is the perfect time to throw away the old artifacts.jar and content.jar, but if the checkbox is not activated, I end up with an incomplete repository. At the moment I have overridden isProcessUnmodified() and return true. That works, but is unfortunately very very expensive for this kind of consumer if the repository is reasonably large. If I understand correctly, it might be better to add a hook to allow the custom code to remove the old files at the start of the scan when that is checked, and not otherwise - rather than putting it in the consumer API itself? 3. I also could not find a way to get an event when a file is deleted. How can a consumer find out when an artifact gets deleted? Especially with snapshots being always unique since maven 3, the p2 files will quickly explode when old snapshot entries don't get deleted regulary… Implementors of archiva-modules/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/events/RepositoryListener.java (though it may not be consistently used for some deletions). - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Archiva refactoring
Thanks Olivier, I'll try and look at updating the page over the weekend. - Brett On 05/08/2011, at 2:56 AM, Olivier Lamy wrote: Hello, I have started add content in https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap . Next step I will create related jira entries and probably related page for some items. Feel free to fix content in the page and/or add comments. 2011/8/4 Brett Porter br...@apache.org: On 04/08/2011, at 8:33 AM, Olivier Lamy wrote: 2011/8/3 Brett Porter br...@apache.org: On 04/08/2011, at 1:50 AM, Olivier Lamy wrote: Hi Folks, I'd like to continue working on the refactoring. Most of the part (removing plexus stuff is mostly done). What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out? Nothing except more testing and releasing redback and companions. Cool - let me know if there's something I can help with there. I had it in mind that it was still a work in progress. what the bugs regarding metadata ? Things I broke with changes to the repository API :) Now the next step is probably to expose our apis (redback, archiva) tru REST services. IMHO with this we will be able to refactor ui more easily (and maybe write different ui technologies) Cool! Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there? Perso I'd like to remove xmlrpc ones :-). But if it's used they can stay. No real ideas about who consume those. I'm using them, so I can help make sure they still work at least for the next release. I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch? Yup that's the goal to use standard jax-rs (and NOT spring annotations) My idea is to expose services on both xml and json. Great - was going to suggest both those things. My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :) Agree the war is huge. (with removing xmlrpc we can maybe cleanup :P ). An other idea I have is to provide a tomcat install rather than the jetty (asf dogfood again), an embeded archiva version (ie runnable for testing) and/or something easy to install/run with a simple : java -jar archiva.war :-) Agree these are all good things. I like the Jetty one, but having a few different distributions (including slim ones with less functionality) has long been a goal of mine. BTW my plan is to start with redback. (with providing sample ui with other techs). At the end we will have to choose the ui tech we will use. As I remember we talked about gwt or vaadin. IMHO if we try to add an ui plugin mechanism it will be more easy with vaadin. I like the look of vaadin (still haven't used it in anger though) - the concern I heard raised from Emmanuel was that it was network heavy. And with this there is the question about this plugin mechanism (dynamic or not ?). If dynamic the only solution will be using osgi (but a more long term feature :-) ). This might be something good to just start doing and have some bits dynamic and lots of legacy, then gradually break it up... An other long term is to move to shiro to not have to maintain redback. Agree, or at least make Redback a wrapper around Shiro so it's a lot smaller. Back to that list you mentioned before, if we can let go of some features it might get easier. Sure a lot of ideas !. Now time to do at least a small percentage :-) On 04/08/2011, at 8:52 AM, Olivier Lamy wrote: I will sum up this here https://cwiki.apache.org/confluence/display/ARCHIVA/Features+Dev (after sleeping :-) ) Also: https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap Thanks! - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Brett Porter br...@apache.org http://brettporter.wordpress.com/
Re: Archiva refactoring
On 04/08/2011, at 1:50 AM, Olivier Lamy wrote: Hi Folks, I'd like to continue working on the refactoring. Most of the part (removing plexus stuff is mostly done). What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out? Now the next step is probably to expose our apis (redback, archiva) tru REST services. IMHO with this we will be able to refactor ui more easily (and maybe write different ui technologies) Cool! Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there? You will find as you go that there is some struts actions with too much logic in them, and some where the code is duplicated in the xmlrpc that will need refactoring. I'd like to make sure this effort keeps trunk working, though :) Hopefully it has less impact. For redback - what parts are you going to expose as REST? That might be a good place to be selective so we can consider chopping some parts out. I think about using cxf (ASF dogwood) I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch? My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :) No objections ? (btw I will start first with red back) +1 - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Archiva refactoring
On 04/08/2011, at 8:33 AM, Olivier Lamy wrote: 2011/8/3 Brett Porter br...@apache.org: On 04/08/2011, at 1:50 AM, Olivier Lamy wrote: Hi Folks, I'd like to continue working on the refactoring. Most of the part (removing plexus stuff is mostly done). What's still left to be done for that? Anything that would block us shipping if the other metadata related bugs were sorted out? Nothing except more testing and releasing redback and companions. Cool - let me know if there's something I can help with there. I had it in mind that it was still a work in progress. what the bugs regarding metadata ? Things I broke with changes to the repository API :) Now the next step is probably to expose our apis (redback, archiva) tru REST services. IMHO with this we will be able to refactor ui more easily (and maybe write different ui technologies) Cool! Is your plan to start by mirroring the xmlrpc ones? Will you be leaving them there? Perso I'd like to remove xmlrpc ones :-). But if it's used they can stay. No real ideas about who consume those. I'm using them, so I can help make sure they still work at least for the next release. I'm fine with that - though I presume you're using JAX-RS and it wouldn't be too hard to switch? Yup that's the goal to use standard jax-rs (and NOT spring annotations) My idea is to expose services on both xml and json. Great - was going to suggest both those things. My only concern with CXF is it has a lot of dependencies, and Archiva already needs a diet - something we need to keep an eye on :) Agree the war is huge. (with removing xmlrpc we can maybe cleanup :P ). An other idea I have is to provide a tomcat install rather than the jetty (asf dogfood again), an embeded archiva version (ie runnable for testing) and/or something easy to install/run with a simple : java -jar archiva.war :-) Agree these are all good things. I like the Jetty one, but having a few different distributions (including slim ones with less functionality) has long been a goal of mine. BTW my plan is to start with redback. (with providing sample ui with other techs). At the end we will have to choose the ui tech we will use. As I remember we talked about gwt or vaadin. IMHO if we try to add an ui plugin mechanism it will be more easy with vaadin. I like the look of vaadin (still haven't used it in anger though) - the concern I heard raised from Emmanuel was that it was network heavy. And with this there is the question about this plugin mechanism (dynamic or not ?). If dynamic the only solution will be using osgi (but a more long term feature :-) ). This might be something good to just start doing and have some bits dynamic and lots of legacy, then gradually break it up... An other long term is to move to shiro to not have to maintain redback. Agree, or at least make Redback a wrapper around Shiro so it's a lot smaller. Back to that list you mentioned before, if we can let go of some features it might get easier. Sure a lot of ideas !. Now time to do at least a small percentage :-) On 04/08/2011, at 8:52 AM, Olivier Lamy wrote: I will sum up this here https://cwiki.apache.org/confluence/display/ARCHIVA/Features+Dev (after sleeping :-) ) Also: https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+Roadmap Thanks! - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: [jira] Commented: (MRM-1482) Exsiting Network Location Access for JAR files
On 28/07/2011, at 1:44 AM, Daivish Shah wrote: Hi Dev Team, Can you help me to resolve issue # MRM-1482 ? As i am looking to setup custom repository structure and it should show as maven standards. As described in following discussion i want to resolve this issue ? Can you please help me out in doing this ? Let me know if you need any more inputs from my side. Thanks Brett for your help and guidance. No problem. The below was a fairly thorough description for Archiva 1.3.x. Is there a point in this where you've gotten stuck? It does require code customisation, but we'd be happy to adopt the changes you make so they are present in future versions. - Brett Thanks, Daivish. On Tue, Jul 26, 2011 at 6:01 PM, Brett Porter (JIRA) j...@codehaus.orgwrote: [ https://jira.codehaus.org/browse/MRM-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274315#comment-274315] Brett Porter commented on MRM-1482: --- Here are the steps to just support a custom managed repository type, building on Archiva 1.3.x. If you wanted to make the modification to trunk (which has changed but is not released yet) or make it flexible, please discuss it with us on dev@archiva.apache.org and we'd be happy to help incorporate your patch. The first step is to make sure you can checkout and build Archiva: http://archiva.apache.org/developers/building.html Instead of the location there, you will want to check out the branch for your purposes: http://svn.apache.org/repos/asf/archiva/branches/archiva-1.3.x Once you can build and run it, try copying the class above to a new one in the same directory and change the legacy references to, say, custom. As part of changing this, you'll also need alternatives for these: - AbstractLegacyRepositoryContent - LegacyPathParser You'll also need to add custom as valid values in these: - archiva-webapp/src/main/resources/org/apache/maven/archiva/web/action/admin/ConfigureRepositoryAction-validation.xml - archiva-webapp/src/main/webapp/WEB-INF/jsp/admin/include/repositoryForm.jspf If you can then build and run archiva and create a managed repository of type custom, you are ready to edit the code you copied to read files in the format you expect. Hopefully, how to do that is obvious from the code there. If you have any questions, feel free to ping us on dev@archiva.apache.org. Exsiting Network Location Access for JAR files -- Key: MRM-1482 URL: https://jira.codehaus.org/browse/MRM-1482 Project: Archiva Issue Type: New Feature Components: repository scanning Affects Versions: 1.3.5 Environment: Windows Reporter: daivish shah Priority: Critical Hi, I have one quick Question for you guys. I am having one issue to adopt Archiva and Maven. My company needs following features available with Archiva. I am trying to force my company to choose Archiva but they have one critical question for you guys. My company is looking for a tool, Which can provide existing network path location as Maven Local Repository. Example is as followed. Existing network Path : C:\networkfolder\ErrorLogging\1.0\Java\ErrorLogClient.jar And my MAVEN repository should show-up path something like this. http://localhost:8080/archiva/browse/ErrorLogClient/ErrorLogClient/1.0/ErrorClient-1.0.jar Is there any work around for this, That Archiva can provide me ? The company has more then 100 products which is using something like this so we have to start with only 1 project for now. And for that there are so many dependency with each projects so we can't create a new network location and where we point as a MAVEN repository so i am looking for something which can provide me to use existing network path which actually has different kind of directory structure which is archiva is expecting at this moment. Can you please reply me as soon as possible. AS i need to figure it out can i choose Archiva for this or not ? Let me know if you are confused or not clear with my requirement. Thanks, Daivish. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: svn commit: r1141261 - /archiva/trunk/archiva-modules/archiva-web/archiva-security/src/main/resources/META-INF/redback/redback.xml
Thanks - seems I made a typo in the one above, will fix... On 30/06/2011, at 5:40 AM, ol...@apache.org wrote: Author: olamy Date: Wed Jun 29 21:40:31 2011 New Revision: 1141261 URL: http://svn.apache.org/viewvc?rev=1141261view=rev Log: add missing operation Modified: archiva/trunk/archiva-modules/archiva-web/archiva-security/src/main/resources/META-INF/redback/redback.xml Modified: archiva/trunk/archiva-modules/archiva-web/archiva-security/src/main/resources/META-INF/redback/redback.xml URL: http://svn.apache.org/viewvc/archiva/trunk/archiva-modules/archiva-web/archiva-security/src/main/resources/META-INF/redback/redback.xml?rev=1141261r1=1141260r2=1141261view=diff == --- archiva/trunk/archiva-modules/archiva-web/archiva-security/src/main/resources/META-INF/redback/redback.xml (original) +++ archiva/trunk/archiva-modules/archiva-web/archiva-security/src/main/resources/META-INF/redback/redback.xml Wed Jun 29 21:40:31 2011 @@ -30,6 +30,11 @@ namearchiva-merge-stage/name descriptionMerge Stage Repository/description /operation +operation + idarchiva-merge-repository/id + namearchiva-merge-repository/name + descriptionArchiva Merge Repository/description +/operation operation idarchiva-delete-artifact/id namearchiva-delete-artifact/name -- Brett Porter br...@apache.org http://brettporter.wordpress.com/
recent build speed
Hi, Is it just me, or are the tests much slower on trunk recently? It may be that I'm on my laptop - but it seems to be a bit on vmbuild as well. Is there something changed in the way the components are initialised that might be causing this? I can take a look later in the week, but thought others might have seen it. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/
Re: [continuum] BUILD FAILURE: Archiva (trunk) - Apache Archiva - Default Maven 2 Build Definition
It looks like there's a component teardown problem in here, given the build failure on Continuum. - Brett On 27/06/2011, at 5:08 AM, Continuum@vmbuild wrote: Changed: olamy @ Sun 26 Jun 2011 20:54:21 + Comment: [MRM-1345] update use of Nexus indexer to use Maven indexer remove the per-lookup component refactor test to use only NexusIndexer facade Files changed: /archiva/trunk/archiva-modules/archiva-base/archiva-common/pom.xml ( 1139940 ) /archiva/trunk/archiva-modules/archiva-base/archiva-common/src/main/java/org/apache/maven/archiva/common/utils/ArchivaNexusIndexerUtil.java ( 1139940 ) /archiva/trunk/archiva-modules/archiva-base/archiva-consumers/archiva-lucene-consumers/pom.xml ( 1139940 ) /archiva/trunk/archiva-modules/archiva-base/archiva-indexer/pom.xml ( 1139940 ) /archiva/trunk/archiva-modules/archiva-base/archiva-indexer/src/main/java/org/apache/archiva/indexer/search/NexusRepositorySearch.java ( 1139940 ) /archiva/trunk/archiva-modules/archiva-base/archiva-indexer/src/main/resources/META-INF/plexus/components.xml ( 1139940 ) /archiva/trunk/archiva-modules/archiva-base/archiva-indexer/src/test/java/org/apache/archiva/indexer/search/NexusRepositorySearchTest.java ( 1139940 ) /archiva/trunk/archiva-modules/archiva-scheduler/archiva-scheduler-indexing/pom.xml ( 1139940 ) /archiva/trunk/pom.xml ( 1139940 ) Changed: olamy @ Sun 26 Jun 2011 20:54:44 + Comment: [MRM-1345] update use of Nexus indexer to use Maven indexer fix junits Files changed: /archiva/trunk/archiva-modules/archiva-base/archiva-indexer/src/main/java/org/apache/archiva/indexer/search/NexusRepositorySearch.java ( 1139941 ) /archiva/trunk/archiva-modules/archiva-base/archiva-indexer/src/main/java/org/apache/archiva/indexer/search/SearchResultHit.java ( 1139941 ) /archiva/trunk/archiva-modules/archiva-base/archiva-indexer/src/main/java/org/apache/archiva/indexer/search/SearchResultLimits.java ( 1139941 ) /archiva/trunk/archiva-modules/archiva-base/archiva-indexer/src/main/java/org/apache/archiva/indexer/search/SearchResults.java ( 1139941 ) /archiva/trunk/archiva-modules/archiva-base/archiva-indexer/src/test/java/org/apache/archiva/indexer/search/NexusRepositorySearchTest.java ( 1139941 ) -- Brett Porter br...@apache.org http://brettporter.wordpress.com/
Re: svn commit: r1138081 - in /archiva/trunk/archiva-modules/archiva-web: archiva-webapp-test/ archiva-webapp-test/src/test/testng/org/apache/archiva/web/test/ archiva-webapp-test/src/test/testng/org/
On 22/06/2011, at 5:39 PM, Olivier Lamy ol...@apache.org wrote: Hello, Yup I have seen it too. I will work on now (after morning coffee :-) ) BTW I have some other issues with indexer, searching doesn't work anymore :-(. Something else I'd like to do is to upgrade to last indexer (asf one) : eating our own dogfood :-) I will open a jira for this. There should already be one available in the 1.4 bucket I think. Cheers, Brett
Re: Is there a way to automatically delete all the -SNAPSHOT versions when a non-SNAPSHOT version is uploaded?
On 21/06/2011, at 6:34 AM, Wendy Smoak wrote: On Mon, Jun 20, 2011 at 4:29 PM, Jarrod Roberson jar...@vertigrated.com wrote: I have a highly distributed team and not everyone pays attention to their emails as good as they should and don't tend to read wiki pages for comprehension either. thus returning an error that the -SNAPSHOT version you are trying to publish is at a release and no longer allowed to be updated would notify them of their mistake. Archiva already responds with a 409 when you try to deploy a release that already exists (assuming you've turned on that option) so it sounds feasible. Someone more familiar with the code can give you a pointer when they wander by. You can look in ArchivaDavResourceFactory (under the archiva-webdav module), where SC_CONFLICT appears. Let us know if we can provide any assistance! Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: auto generating an archetype-catalog.xml when navigating to a root/archetype-catalog.xml
On 17/06/2011, at 6:13 AM, Jarrod Roberson wrote: I am trying to add this feature to Archiva, but I can't figure out where to start? This is a critical feature I need to add for our environment in order to enabled my distributed team to create projects from a standard set of company archetypes? What I need to know is: 1. How to search all the repositories for artifacts of packaging type maven-archetype? Are you working against trunk (unreleased, and significant changes to the repository APIs), or trying to patch Archiva 1.3.x? The place to point you will be different for each, but on trunk you could look at: https://svn.apache.org/repos/asf/archiva/trunk/archiva-modules/plugins/repository-statistics/src/main/java/org/apache/archiva/metadata/repository/stats/DefaultRepositoryStatisticsManager.java That counts all objects of a certain type, which would help you do the same here. There's two alternatives implemented depending on whether you store the metadata in JCR or not. Alternatively, you could search the maven repository index that is typically generated (this would be the same in both versions) 2. How / Where to add a simple Servlet so that it will respond to http://[archiva]/archetype-catalog.xml with the results of all the available archetypes I find in the available repositories? Do you want to generate it dynamically, or have it a flat file that is updated whenever a new archetype is added to the repository (or occasionally repopulated by a scan)? I need to combine the internal and snapshot ( and any others ) repositories for this to really be useful. But I am only using internal and snapshot right now. This should just appear as the normal catalog at the root of a repository group, right? If it's dynamic, you'd just widen the search criteria, if they are generated then the group request would need to merge the files. You'll find a similar situation for metadata files in ArchivaDavResourceFactory.java (archiva-webdav module). I forked the project on GitHub and will contribute my solution back there when I get it working. Great, welcome! Please pardon our dust as Olivier is doing quite a bit of trunk cleanup at the moment. I hope that doesn't get in your way :) - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: auto generating an archetype-catalog.xml when navigating to a root/archetype-catalog.xml
On 17/06/2011, at 12:03 PM, Jarrod Roberson wrote: On Thu, Jun 16, 2011 at 8:41 PM, Brett Porter br...@apache.org wrote: On 17/06/2011, at 6:13 AM, Jarrod Roberson wrote: I am trying to add this feature to Archiva, but I can't figure out where to start? This is a critical feature I need to add for our environment in order to enabled my distributed team to create projects from a standard set of company archetypes? What I need to know is: 1. How to search all the repositories for artifacts of packaging type maven-archetype? Are you working against trunk (unreleased, and significant changes to the repository APIs), or trying to patch Archiva 1.3.x? I want to patch up 1.3.x where X is the latest. Ok. In that case, I recommend writing a consumer that will hook into the arrival / departure of artifacts and updates the archetype-catalog at the time. That will work across both versions, and makes the request for the catalog fast. An example of handling an added artifact: MetadataUpdaterConsumer.java An example of handling a removed artifact: DatabaseCleanupRemoveArtifactConsumer Note that you'll need to make sure you are working from the right codebase - I'm not sure if the github mirrors retain the tags branches from svn. This should just appear as the normal catalog at the root of a repository group, right? I am just dumping it at the root of the application in my case /opt/archiva/apps/archiva/archetype-catalog.xml There is a repository/ element in each entry that points back to which repository the archetype lives in. But that won't take into account, for example, security - if the requester can only see a subset of the repositories. Thanks for the help, I will report back what I get done. There is a bug open for this 1284, maybe I can get that closed. Thanks! PS: I decided I might could do this with mvn archetype:crawl and a cron job, but I can't get mvn archetype:crawl to generate a file, it walks the internal and snapshots directory structures and spews out all the artifacts, but never generates a file. I am using Maven 3.0.3 by the way. I'm not familiar with it... - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: svn commit: r1128782 - in /archiva/trunk: ./ archiva-modules/archiva-base/archiva-proxy/src/test/java/org/apache/maven/archiva/proxy/
On 14/06/2011, at 6:04 PM, Olivier Lamy wrote: Hello, Not really accidental, it's just a shortcut for people who wants to try git svn. As I have to play this script a lot : I had some issues with git svn with cygwin arg :-), I have added the script to setup the clone from github or git.a.o Just do : git clone git://github.com/apache/archiva.git; cd archiva ; ./init-git-svn.sh And you have everything ready for hacking. The script contains only : cd .git;wget http://git.apache.org/authors.txt; cd .. git config svn.authorsfile .git/authors.txt git svn init --prefix=origin/ --tags=tags --trunk=trunk --branches=branches https://svn.apache.org/repos/asf/archiva git svn rebase see http://wiki.apache.org/general/GitAtApache You prefer I remove it ? Sorry, I was sure that that was included in the original clone from those repos - I must have added it and forgotten I did :) That's fine... though maybe it could go on the wiki or dev docs instead? It's just a bit more likely to bitrot in svn, or need to be copied for windows, etc. :) - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: svn commit: r1128782 - in /archiva/trunk: ./ archiva-modules/archiva-base/archiva-proxy/src/test/java/org/apache/maven/archiva/proxy/
On 29/05/2011, at 8:14 AM, ol...@apache.org wrote: Author: olamy Date: Sat May 28 22:14:41 2011 New Revision: 1128782 URL: http://svn.apache.org/viewvc?rev=1128782view=rev Log: no need of this configuration as it s done in setup and avoid null in directory as unit tests use getName for directories Added: archiva/trunk/init-git-svn.sh (with props) Accidental commit? Also, why not clone from the existing one at Apache (or the github clone?) I think they retain the svn metadata - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: svn commit: r1129260 - /archiva/parent/pom.xml
Does this change anything unexpected? I know it has different repositories, etc. - Brett On 31/05/2011, at 3:05 AM, ol...@apache.org wrote: Author: olamy Date: Mon May 30 17:05:10 2011 New Revision: 1129260 URL: http://svn.apache.org/viewvc?rev=1129260view=rev Log: upgrade to last ASF parent Modified: archiva/parent/pom.xml Modified: archiva/parent/pom.xml URL: http://svn.apache.org/viewvc/archiva/parent/pom.xml?rev=1129260r1=1129259r2=1129260view=diff == --- archiva/parent/pom.xml (original) +++ archiva/parent/pom.xml Mon May 30 17:05:10 2011 @@ -24,7 +24,7 @@ parent groupIdorg.apache/groupId artifactIdapache/artifactId -version4/version +version9/version /parent groupIdorg.apache.archiva/groupId -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: [continuum] BUILD FAILURE: Archiva (trunk) - Apache Archiva - Default Maven 2 Build Definition
On 20/05/2011, at 11:24 PM, Olivier Lamy wrote: Hello, Yup I'm aware of that. The remove of plexus(-spring) in redback introduces some failures in Archiva. I'm working on (it was quiet long with redback : I now imagine with Archiva :-) ). It's also broken Continuum's build... might need some direction on how to fix that with minimal effort. I will name spring bean with something like : * @plexus.component role=org.apache.maven.archiva.policies.PreDownloadPolicy * role-hint=cache-failures */ @Service(preDownloadPolicy#cache-failures) public class CachedFailuresPolicy implements PreDownloadPolicy Will be more easy for various piece of codes which use lookupMap from plexus. Objections ? Sounds fine to me! -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
Re: Release Archiva 1.3.5
Go for it! (and let's really, truly make this the last 1.3.x release :D) - Brett On 16/05/2011, at 4:07 PM, Deng Ching wrote: Hi, I think we're all set to release Archiva 1.3.5. This release would contain the fixes for the security vulnerabilities that were reported previously. Below are all the issues that will be included in this release: * [MRM-1457] - Cpu usage 100% * [MRM-1467] - Archiva does not start up on Solaris 64-bit. * [MRM-1469] - Uploading large artifacts is dreadfully slow * [MRM-1463] - Better Layout for Artifact Download Box * [MRM-1460] - Upgrade Archiva to Redback 1.2.8 * [MRM-1468] - Fix cross-site scripting vulnerability in Archiva. Any objections to releasing 1.3.5? Thanks, Deng -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
