[RESULT][VOTE] Move to Attic

[Olivier Lamy]

Hi,
The result is
+1 JB Onofre, Martin, Eric, Frederik, Olivier

All done. I will finish the procedure to move the project to Attic.

Thanks a lot to all the people who have participated in the project
for very long time (some veteran knows :))

Cheers
Olivier

Re: [VOTE] Move to Attic

[Olivier Lamy]

my +1

On Tue, 30 Jan 2024 at 11:19, Olivier Lamy  wrote:
>
> Hi,
> It's more of a procedural vote, as this has already been discussed and agreed.
>
> Moving to Attic
>
> +1
> -1 (please provide ideas to restart some activities)
>
> Vote open for 72h
>
> Cheers
> Olivier

[VOTE] Move to Attic

[Olivier Lamy]

Hi,
It's more of a procedural vote, as this has already been discussed and agreed.

Moving to Attic

+1
-1 (please provide ideas to restart some activities)

Vote open for 72h

Cheers
Olivier

Re: Moving to Attic

[Olivier Lamy]

Hi
If some are happy to help/volunteer. The plan could be to have it
maintained outside of Apache (some GitHub repo and changing Maven
coordinate) to ease contributions and have new maintainers.


On Wed, 22 Nov 2023 at 00:28, Paul Spencer  wrote:
>
> Terence,
> As one who has been using Archiva for years, primarily because it just works 
> without requiring much maintenance, having a list of migration options from 
> those with more subject area knowledge would be very helpful.
>
> Paul Spencer
>
> > On Nov 19, 2023, at 9:47 PM, Terence Kent  wrote:
> >
> > That’s the move, IMO.
> >
> > That said, there are a fair amount of legacy deployments still kicking
> > around. For reference, every time a security patch is released somebody
> > pings our docker repo within a few days. So folks are using it and watching
> > for releases.
> >
> > Providing the community with some examples of how to migrate to other
> > options (say Reposilite) would be responsible. I’ve been meaning to do that
> > myself for a few months and just haven’t found the time.
> >
> > On Sun, Nov 19, 2023 at 6:26 PM Olivier Lamy  wrote:
> >
> >> Hi,
> >> I can only see a little (almost none) activity with the project now.
> >> So, it's time to call for an Attic move.
> >>
> >> Please let me know me what do you think about this?
> >> Is there any volunteers who would like to help?
> >> Please note there is still possibility to continue the project out of
> >> Apache (some github forks) but this cannot be called anymore Apache
> >> Archva.
> >>
> >> Cheers,
> >> Olivier
> >>
>

Moving to Attic

[Olivier Lamy]

Hi,
I can only see a little (almost none) activity with the project now.
So, it's time to call for an Attic move.

Please let me know me what do you think about this?
Is there any volunteers who would like to help?
Please note there is still possibility to continue the project out of
Apache (some github forks) but this cannot be called anymore Apache
Archva.

Cheers,
Olivier

Re: Archiva 2.2.10 : 400 Bad Request when downloading an artifact

[Olivier Lamy]

Hi
I wonder what is the real path of the repository on disk? Does it
contain "special characters"?

On Wed, 10 May 2023 at 03:54, Marco Ferretti  wrote:
>
>
>
> On May 8 2023, at 10:10 am, Olivier Lamy  wrote:
> > Hi
> > I can see this root cause in the stack trace
> > > Caused by: 
> > > org.apache.jackrabbit.spi.commons.conversion.MalformedPathException: 
> > > 'junit;junit-[4.13.1,).jar' is not a valid path. '�' not a valid name 
> > > character.
> >
> > This sounds strange.
> > Maybe you can simply stop Archiva, delete the jackrabbit data as they
> > seem to be corrupted then restart.
> >
> I have tried removing the jcr directory and restart archiva 2.2.10 with the 
> exact same result. I have even tried the same with archiva 2.2.8 successfully.
> Here's the result :
> -- archiva 2.2.8, jcr directory deleted and automatically rebuilt :
>
> wget 
> http://artifact.axiante.com/repository/internal/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> URL transformed to HTTPS due to an HSTS policy
> --2023-05-08 11:13:52-- 
> https://artifact.axiante.com/repository/internal/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> Resolving artifact.axiante.com (artifact.axiante.com)... 34.122.158.86
> Connecting to artifact.axiante.com 
> (artifact.axiante.com)|34.122.158.86|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 261809 (256K) [application/java-archive]
> Saving to: ‘commons-lang-2.4.jar’
>
> commons-lang-2.4.jar 
> 100%[=>]
>  255,67K 223KB/s in 1,1s
>
> -- archiva 2.2.10, jcr directory deleted and automatically rebuilt
> -- archiva 2.2.10, jcr directory deleted and moved from archiva 2.2.8
> -- archiva 2.2.10, jcr directory deleted, repository directory moved from 
> archiva 2.2.8, jcr directory moved from archiva 2.2.8
> -- archiva 2.2.10, jcr directory deleted, repository directory moved from 
> archiva 2.2.8, jcr rebuilt on startup
> wget 
> http://artifact.axiante.com/repository/internal/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> URL transformed to HTTPS due to an HSTS policy
> --2023-05-08 11:16:31-- 
> https://artifact.axiante.com/repository/internal/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
> Resolving artifact.axiante.com (artifact.axiante.com)... 34.122.158.86
> Connecting to artifact.axiante.com 
> (artifact.axiante.com)|34.122.158.86|:443... connected.
> HTTP request sent, awaiting response... 400 Bad Request
> 2023-05-08 11:16:34 ERROR 400: Bad Request.
>
> the log always has
> Caused by: 
> org.apache.jackrabbit.spi.commons.conversion.MalformedPathException: 
> 'org.bouncycastle;bc-fips-[1.0.2,2.0.0).jar' is not a valid path. '�' not a 
> valid name character.
> at 
> org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:327)
>  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> at 
> org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:122)
>  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> at 
> org.apache.jackrabbit.spi.commons.conversion.ParsingPathResolver.getQPath(ParsingPathResolver.java:90)
>  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> at 
> org.apache.jackrabbit.spi.commons.conversion.CachingPathResolver.getQPath(CachingPathResolver.java:98)
>  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> at 
> org.apache.jackrabbit.spi.commons.conversion.CachingPathResolver.getQPath(CachingPathResolver.java:77)
>  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> at 
> org.apache.jackrabbit.spi.commons.conversion.DefaultNamePathResolver.getQPath(DefaultNamePathResolver.java:82)
>  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> at org.apache.jackrabbit.core.SessionImpl.getQPath(SessionImpl.java:648) 
> ~[jackrabbit-core-2.9.1.jar:2.9.1]
> at 
> org.apache.jackrabbit.core.session.SessionContext.getQPath(SessionContext.java:338)
>  ~[jackrabbit-core-2.9.1.jar:2.9.1]
> at org.apache.jackrabbit.core.NodeImpl.resolveRelativePath(NodeImpl.java:238) 
> ~[jackrabbit-core-2.9.1.jar:2.9.1]
> at 
> org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:223)
>  ~[jackrabbit-core-2.9.1.jar:2.9.1]
> at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2281) 
> ~[jackrabbit-core-2.9.1.jar:2.9.1]
> at org.apache.jackrabbit.commons.JcrUtils.getOrAddNode(JcrUtils.java:952) 
> ~[jackrabbit-jcr-commons-2.9.1.jar:?]
> at org.apache.jackrabbit.commons.JcrUtils.getOrAddNode(JcrUtils.java:930) 
> ~[jackrabbit-jcr-commons-2.9.1.jar:?]
> at 
> org.apache.archiva.metadata.repository.jcr.JcrMetadataRepository.updateProjectVersion(JcrMetadataRepository.java:319)
>  ~[met

Re: Archiva 2.2.10 : 400 Bad Request when downloading an artifact

[Olivier Lamy]

 > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> >  [?:1.8.0_362]
> > at 
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> >  [?:1.8.0_362]
> > at java.lang.Thread.run(Thread.java:750) [?:1.8.0_362]
> > Caused by: javax.jcr.RepositoryException: Failed to resolve path 
> > junit;junit-[4.13.1,).jar relative to node 
> > /repositories/internal/content/org/javassist/javassist/3.28.0-GA/dependencies
> > at 
> > org.apache.jackrabbit.core.NodeImpl.resolveRelativePath(NodeImpl.java:240) 
> > ~[jackrabbit-core-2.9.1.jar:2.9.1]
> > at 
> > org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:223)
> >  ~[jackrabbit-core-2.9.1.jar:2.9.1]
> > at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2281) 
> > ~[jackrabbit-core-2.9.1.jar:2.9.1]
> > at org.apache.jackrabbit.commons.JcrUtils.getOrAddNode(JcrUtils.java:952) 
> > ~[jackrabbit-jcr-commons-2.9.1.jar:?]
> > at org.apache.jackrabbit.commons.JcrUtils.getOrAddNode(JcrUtils.java:930) 
> > ~[jackrabbit-jcr-commons-2.9.1.jar:?]
> > at 
> > org.apache.archiva.metadata.repository.jcr.JcrMetadataRepository.updateProjectVersion(JcrMetadataRepository.java:319)
> >  ~[metadata-store-jcr-2.2.10.jar:?]
> > ... 23 more
> > Caused by: 
> > org.apache.jackrabbit.spi.commons.conversion.MalformedPathException: 
> > 'junit;junit-[4.13.1,).jar' is not a valid path. '�' not a valid name 
> > character.
> > at 
> > org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:327)
> >  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> > at 
> > org.apache.jackrabbit.spi.commons.conversion.PathParser.parse(PathParser.java:122)
> >  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> > at 
> > org.apache.jackrabbit.spi.commons.conversion.ParsingPathResolver.getQPath(ParsingPathResolver.java:90)
> >  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> > at 
> > org.apache.jackrabbit.spi.commons.conversion.CachingPathResolver.getQPath(CachingPathResolver.java:98)
> >  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> > at 
> > org.apache.jackrabbit.spi.commons.conversion.CachingPathResolver.getQPath(CachingPathResolver.java:77)
> >  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> > at 
> > org.apache.jackrabbit.spi.commons.conversion.DefaultNamePathResolver.getQPath(DefaultNamePathResolver.java:82)
> >  ~[jackrabbit-spi-commons-2.9.1.jar:?]
> > at org.apache.jackrabbit.core.SessionImpl.getQPath(SessionImpl.java:648) 
> > ~[jackrabbit-core-2.9.1.jar:2.9.1]
> > at 
> > org.apache.jackrabbit.core.session.SessionContext.getQPath(SessionContext.java:338)
> >  ~[jackrabbit-core-2.9.1.jar:2.9.1]
> > at 
> > org.apache.jackrabbit.core.NodeImpl.resolveRelativePath(NodeImpl.java:238) 
> > ~[jackrabbit-core-2.9.1.jar:2.9.1]
> > at 
> > org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:223)
> >  ~[jackrabbit-core-2.9.1.jar:2.9.1]
> > at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2281) 
> > ~[jackrabbit-core-2.9.1.jar:2.9.1]
> > at org.apache.jackrabbit.commons.JcrUtils.getOrAddNode(JcrUtils.java:952) 
> > ~[jackrabbit-jcr-commons-2.9.1.jar:?]
> > at org.apache.jackrabbit.commons.JcrUtils.getOrAddNode(JcrUtils.java:930) 
> > ~[jackrabbit-jcr-commons-2.9.1.jar:?]
> > at 
> > org.apache.archiva.metadata.repository.jcr.JcrMetadataRepository.updateProjectVersion(JcrMetadataRepository.java:319)
> >  ~[metadata-store-jcr-2.2.10.jar:?]
> > ... 23 more
>
> Thanks for any advice you can provide.
> Marco
> On May 5 2023, at 2:56 am, Olivier Lamy  wrote:
> > Hi
> > Can you see anything in archiva.log file?
> > does it happen for every artifacts or only few?
> >
> > On Thu, 27 Apr 2023 at 19:30, Marco Ferretti  
> > wrote:
> > >
> > > Hi,
> > > I have been using Archiva since version 2.2.7 without an issue. I have 
> > > bumped into the updates of Archiva (2.2.10) and decided I needed to 
> > > upgrade.
> > > I am using a stand-alone installation proxied by an Apache server (mainly 
> > > to manage certs).
> > >
> > > After installing (unzipping), copying the repository and data directory, 
> > > and checking the differences in wrapper.conf and jetty.xml I fired the 
> > > new version.
> > > I can browse my repos but I can't download jars/pom/etc. What I am 
> > > getting is an HTTP error 400 with any jar I try; here's an exerpt from 
> > > request.log :
> > >
> > > 127.0.0.1 - - [27/Apr/2023:08:04:18 +] "GET 
> > > /rep

Re: Archiva 2.2.10 : 400 Bad Request when downloading an artifact

[Olivier Lamy]

Hi
Can you see anything in archiva.log file?
does it happen for every artifacts or only few?

On Thu, 27 Apr 2023 at 19:30, Marco Ferretti  wrote:
>
> Hi,
> I have been using Archiva since version 2.2.7 without an issue. I have bumped 
> into the updates of Archiva (2.2.10) and decided I needed to upgrade.
> I am using a stand-alone installation proxied by an Apache server (mainly to 
> manage certs).
>
> After installing (unzipping), copying the repository and data directory, and 
> checking the differences in wrapper.conf and jetty.xml I fired the new 
> version.
> I can browse my repos but I can't download jars/pom/etc. What I am getting is 
> an HTTP error 400 with any jar I try; here's an exerpt from request.log :
>
> 127.0.0.1 - - [27/Apr/2023:08:04:18 +] "GET 
> /repository/internal/junit/junit/3.8.1/junit-3.8.1.jar HTTP/1.1" 400 1422 
> "https://artifact.axiante.com/; "Mozilla/5.0 (X11; Linux x86_64) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36"
> I have then tried to upgrade one version at a time with the following results:
> 2.2.7: works (the starting version)
>
> 2.2.8: works (the current version being served)
>
> 2.2.9: same as above, error 400 when trying to download artifacts
>
> 2.2.10: same as 2.2.9
>
> I have checked file permissions, memory, jcr logs and made sure I did a 
> systemctl daemon-reload before running the server (I am using symlinks to 
> keep my installations tight)
> As far as I am aware, there are a few major changes between 2.2.8 and 2.2.9 
> (namely spring), and checking (using diff) the wrapper I can see that 
> activation.jar has been upgraded from version 1.1 to 1.1.1.
> Also, to complete the description of my problem, I am using OpenJDK 1.8.0_362 
> on the machine that is serving Archiva.
>
> Can anyone point me somewhere? I have been trying to upgrade for a couple of 
> days, went through a lot of documentation, and checked Google: the only 
> (slightly) related issue I have found was with versions <1.4 and artifacts 
> upload.
> TIA
> Marco
>

n/a: CVE-2023-28158: Apache Archiva privilege escalation

[Olivier Lamy]

Description:

Privilege escalation via stored XSS using the file upload service to upload 
malicious content.
The issue can be exploited only by authenticated users which can create 
directory name to inject some XSS content and gain some privileges such admin 
user.

This issue is being tracked as n/a 

Credit:

sandr0 (sandr0.xyz)  (finder)

References:

https://archiva.apache.org/
https://www.cve.org/CVERecord?id=CVE-2023-28158
https://issues.apache.org/jira/browse/n/a

[ANN] Apache Archiva 2.2.10

[Olivier Lamy]

Hi,
The Apache Archiva team is pleased to announce release 2.2.10.
Release notes available here:
https://archiva.apache.org/docs/2.2.10/release-notes.html
The branch 2.x is focused on bugs only.
This release fix one issue:
- Potential NullPointerException when using the upload file service

Regards
Apache Archiva Team

Re: Non-canonical repository paths and default config

[Olivier Lamy]

Hi
Sounds definitely like a bug!
Do you have time to create a PR for this?

Thanks
Olivier

On Mon, 2 Jan 2023 at 03:23, machens  wrote:
>
> Hello there!
>
>
>
> In Archiva's (v2.2.9) default configuration, repositories "internal" and
> "snapshots" have a path like this:
>
>./repositories/internal
>
> Prefix "./" causes all repo-api requests to fail with status code "Bad
> Request" (see below for an explanation and code reference).
>
> When looking at the folders created in the working directory, I also
> believe, the current default configuration for repo "Directory" and
> "Index Directory" has not been updated since paths have been reworked.
>
>
>
> Cheers
>   Holger M.
>
>
>
>
>
> Explanation of the Bad Request responses
> 
> The server validates requests by checking if the given canonicalized
> resource path is equal to an absolute path and replies with Bad Request
> (400) if not. Unfortunately, the absolute path contains the user
> configured repository directory path, which may not be canonical. Found
> that in ArchivaDavResourceFactory (see snippet below).
>
>
> ArchivaDavResourceFactory:605
> ---
> LogicalResource logicalResource = new LogicalResource(path);
> File resourceFile = new File(
>managedRepositoryContent.getRepoRoot(), path);
> if(!resourceFile.getCanonicalPath().equals(resourceFile.getAbsolutePath()))
> {
>throw new DavException( HttpServletResponse.SC_BAD_REQUEST );
> }
> ---
>
>

Re: Archiva 2.2.9 and Tomcat 9.0

[Olivier Lamy]

Hi
This should be similar but the problem can be java11 which will need
some extra setup if you are using Archiva 2.x.
You will probably need to add (manually some jaxb jars).
Let us know or provide a PR for the documentation?


On Wed, 26 Oct 2022 at 04:21, Thad Humphries  wrote:
>
> Can the Archiva 2.2.9 be deployed to Tomcat 9.0 following the directions
> for Tomcat 6 and 7? (
> https://archiva.apache.org/docs/2.2.9/adminguide/webapp.html)
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 111-13)

[ANN] Apache Archiva 2.2.9

[Olivier Lamy]

Hi

The Apache Archiva team is pleased to announce the release of Archiva 2.2.9
Archiva is available for download from the web site.
http://archiva.apache.org/download.cgi

Archiva is an application for managing one or more remote
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/mailing-lists.html

Apache Archiva 2.2.9 is a security release including a fix for

  * [MRM-2051}: upgrade dom4j
  * upgrade spring 4.2.9
  * [MRM-2050]: upgrade commons-fileupload and commons-io due to cves
  * [MRM-2049]: upgrade httpclient due to cves
  * [MRM-2048]- upgrade xerces due to CVE

** As this release contains security fixes, we highly recommend to update
to the new version. **


See the release notes for more information:
http://archiva.apache.org/docs/2.2.9/release-notes.html

And security related information:
http://archiva.apache.org/security.html

Enjoy
The Apache Archiva team

Re: Cassandra setup

[Olivier Lamy]

On Mon, 11 Jul 2022 at 22:06, Christoph Thelen  wrote:

> Hi all,
>
> I'm trying to run Archiva 2.2.8 standalone with Cassandra for Metadata as
> described here:
> https://archiva.apache.org/docs/2.2.8/adminguide/repositories-content-storage.html
> . First I tried Cassandra 4.0.4, but Archiva could not connect. Is it
> correct that Archiva needs Thrift (which was removed in Cassandra 4)?
>

oh yes we need some update there.


> Next try was Cassandra 3.11.13, but Archiva stopped with the following
> exception:
>
> "InvalidRequestException(why:unconfigured table metadatafacet)"
>
> I have created a keyspace in Cassandra, but nothing else. Do I have to
> create some tables by hand?
>

normally not keyspace should work. maybe you could try with some debug
level activated to have more details?

cheers
Olivier


>
> Thanks for your help,
> --
> Chris
>
>
> Hilscher Gesellschaft für Systemautomation mbH   |  Rheinstrasse 15  |
> 65795 Hattersheim  |  Germany  |  www.hilscher.com >
> Sitz der Gesellschaft / place of business: Hattersheim  |  Geschäftsführer
> / managing director: Sebastian Hilscher, Hans-Jürgen Hilscher
> Handelsregister / commercial register: Frankfurt B 26873  |  Ust. Idnr. /
> VAT No.: DE113852715
> Registergericht / register court: Amtsgericht Frankfurt/Main
>
> Important Information:
> This e-mail message including its attachments contains confidential and
> legally protected information solely intended for the addressee. If you are
> not the intended addressee of this message, please contact the addresser
> immediately and delete this message including its attachments. The
> unauthorized dissemination, copying and change of this e-mail are strictly
> forbidden. The addresser shall not be liable for the content of such
> changed e-mails.
>
> Wichtiger Hinweis:
> Diese E-Mail einschließlich ihrer Anhänge enthält vertrauliche und
> rechtlich geschützte Informationen, die nur für den Adressaten bestimmt
> sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies
> bitte dem Absender umgehend mit und löschen Sie diese Nachricht und ihre
> Anhänge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede
> Veränderung der E-Mail ist untersagt. Der Absender haftet nicht für Inhalte
> von veränderten E-Mails.
>

Re: 2.2.8 security release

[Olivier Lamy]

Hi
Yes sorry for the delay, I sent the announcement this morning.

regards
Olivier

On Sat, 28 May 2022 at 19:14, Bram Van Dam  wrote:

> It seems like Apache Archiva 2.2.8 was released on 25 May 2022, with a
> critical security fix for CVE-2022-29405 -- where any registered user
> can reset any other user's password.
>
> I couldn't find an announcement on any of the Archiva mailing lists, so
> I figured I'd send one myself.
>
> Release notes can be found here:
>
> https://archiva.apache.org/docs/2.2.8/release-notes.html
>
>   - Bram
>

[ANN] Apache Archiva 2.2.8 released

[Olivier Lamy]

The Apache Archiva team is pleased to announce the release of Archiva 2.2.8
Archiva is available for download from the web site.
http://archiva.apache.org/download.cgi

Archiva is an application for managing one or more remote
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/mailing-lists.html

Apache Archiva 2.2.8 is a security release including a fix for
CVE-2022-29405 Apache Archiva Arbitrary user password reset vulnerability

** As this release contains security fixes, we highly recommend to update
to the new version. **


See the release notes for more information:
http://archiva.apache.org/docs/2.2.8/release-notes.html

And security related information:
http://archiva.apache.org/security.html

Enjoy
The Apache Archiva team

Re: Cant get rest service copyArtifact to work

[Olivier Lamy]

Hi
Any stack trace in the server log?


On Fri, 1 Nov 2019 at 20:57, Anders Nyström  wrote:

> Hi,
>
> I am trying to use the rest service copyArtifact, but I can't get it to
> work. Feels like I have tried everything. I am trying to do this with
> groovy and this is how my code looks at the moment. The info in
> artifactTransferRequest is from the response of searchArtifacts
>
> def copyArtifact() {
>   def baseUrl = "..."
>   def request = new RESTClient(baseUrl + "/restServices/archivaServices/")
>   request.headers['Authorization'] = "Basic " +
> ("username:pass".bytes.encodeBase64().toString())
>   request.handler.failure = { response ->
> println "Unexpected failure: ${response.status}"
>   }
>   def copyArtifactResponse = request.post(
> path: "repositoriesService/copyArtifact",
> contentType: JSON,
> requestContentType: XML,
> body: {
>   artifactTransferRequest {
> targetRepositoryId  "tagged-releases"
> packaging   "dll"
> fileExtension   "dll"
> type"dll"
> artifactId  "bla4"
> groupId "se..."
> version "2020.1"
> repositoryId"release"
> context "release"
> url "..."
>   }
> }
>   )
>
>   println "Status: " + copyArtifactResponse.status
>   if (copyArtifactResponse.data) {
> println("Content Type: " + copyArtifactResponse.contentType)
> println("Headers: " + copyArtifactResponse.getAllHeaders())
> println("Body:\n" +
> JsonOutput.prettyPrint(JsonOutput.toJson(copyArtifactResponse.data)))
>   }
> }
>
>
> Here is the response I get:
> Unexpected failure: 500
> Caught: java.lang.NullPointerException: Cannot get property 'status' on
> null object
> java.lang.NullPointerException: Cannot get property 'status' on null object
>
> Regards
> Anders
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: OSGi R5 support in Apache Archiva

[Olivier Lamy]

Hi
Not sure what do you mean with generating and service OSGI R5?


On Tue, 25 Jun 2019 at 00:08, Jelle Nelis  wrote:

> Hi all,
>
> Quick question, is there a plugin to support generating and service an
> OSGi R5 index through Apache Archiva? If not, are there any efforts
> towards this goal?
>
> Kind regards,
>
> Jelle
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Apache Archiva Slack channel

[Olivier Lamy]

Hi
There is an ASF slack feel free to join https://s.apache.org/slack-invite

Cheers
-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Log Rotation

[Olivier Lamy]

On Mon, 11 Mar 2019 at 21:32, Oz  wrote:

> Greetings fellow Archiva users!
>
> I have installed Archiva on Ubuntu 18.04, it is a standalone installation
> with a separate base directory as described in this page:
> http://archiva.apache.org/docs/2.2.3/adminguide/standalone.html
> This is all working well.
>
> We have a corporate log retention policy and we use Linux logrotate to
> implement consistent log rotation all log files.
>
> I would like to customize the logging, specifically the log file name and
> disable log rotation.  I would like to disable log file rotation by
> Archiva/log4j2 and use Linux logrotate.
>
> It appears that the Archiva web application has its own log4j2
> configuration file in the directory:
> apps/archiva/WEB-INF/classes/log4j2.xml
>
> Is it advisable to modify this configuration file or should I create my
> own log4j2 configuration file in ARCHIVA_BASE/conf/ directory?
>
> Then specify this configuration file in the wrapper.conf using the
> following method:
>
> wrapper.java.additional.x=-Dlog4j.configurationFile=%ARCHIVA_BASE%/conf/myLog4j2.xml
>
>
> Will this work?  Any advise will be greatly appreciated.
>

I guess yes


>
> Thanks
> Oz
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Setting Artifact Name and Description

[Olivier Lamy]

Hi
Does your poms have xml tags with some content for name and description?

On Fri, 30 Nov 2018 at 20:10, Slowlearner  wrote:

> Hi there, I have successfully installed Archiva on my development PC as a
> dry
> run for a wider implementation however I have come up against a problem
> which I imagine is simple to resolve but I can find nothing about it on the
> wider web or these forums.
>
> I have uploaded an asset into a managed internal repository and it is
> accessible through the site - all good - however, whilst the artifact has
> Artifact and Group ID set, the Name and Description fields are empty and I
> can find no way to set them.
>
> Any advice gratefully received.
>
>
>   ..alex
>
>
>
> --
> Sent from: http://archiva.996284.n3.nabble.com/User-f10698.html
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Interested in a Docker Image & Kubernetes Chart?

[Olivier Lamy]

gt; >> would
> >> > > consider it as stable.
> >> > > If you like, you can use a current snapshot version in your
> >docker
> >> image
> >> > > or provide an option for using it.
> >> > > The zip files can be found at:
> >> > >
> >> > >
> >>
> >
> https://archiva-repository.apache.org/archiva/repository/snapshots/org/apache/archiva/archiva-jetty/2.2.4-SNAPSHOT/
> >> > > But it's still a snapshot version so, if there is development
> >going
> >> on, it
> >> > > may be broken every now and then, so it may be not a
> >> > > good idea, if the file is downloaded dynamically during container
> >> > > start/build.
> >> > >
> >> > > Regards
> >> > >
> >> > > Martin
> >> > >
> >> > > Am Freitag, 19. Oktober 2018, 02:08:52 CEST schrieb Terence Kent:
> >> > > > Hello,
> >> > > >
> >> > > > In early 2015, we made our Archiva docker image public. It's
> >had a
> >> small
> >> > > > following on github/dockerhub and we field questions on it from
> >time
> >> to
> >> > > > time. As best we can tell, it's the de-facto docker image for
> >> Archiva.
> >> > > >
> >> > > > We recently moved to Kubernetes and were faced with the
> >decision of
> >> > > > dropping the archiva image and moving to another repository
> >manager,
> >> or
> >> > > > re-upping and modernizing the image. We chose to re-up and
> >modernize
> >> the
> >> > > > image and we now have a "version 2" image with an companion
> >helm
> >> chart to
> >> > > > make it easy to run in Kubernetes.
> >> > > >
> >> > > > I wanted to reach out to see if you had any interest in making
> >our
> >> image
> >> > > > your official one and pulling it the Archiva source. I think
> >it's
> >> > > > reasonable to assume new Archiva deployments are likely to be
> >> > > > containerized, and Kubernetes is the most popular container
> >> orchestration
> >> > > > platform. If our small image and chart can save you time, we'd
> >be
> >> quite
> >> > > > happy hand it over.
> >> > > >
> >> > > > Here's the project links for reference:
> >> > > >
> >> > > >  - https://github.com/xetus-oss/docker-archiva
> >> > > >  -
> >> https://github.com/xetus-oss/helm-charts/tree/master/xetusoss-archiva
> >> > > >
> >> > > > Let me know,
> >> > > > Terence
> >> > > >
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
>
> --
> This message was sent from mobile phone.



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Error 403 when proxying with Nginx

[Olivier Lamy]

Hi
Which Archiva version are you using?
Do you have anything in Archiva logs?
In your archiva.xml you should have some elements such





false



true



true







See the details here:
http://archiva.apache.org/redback/configuration.html#REST_security_settings

HTH
Olivier


On 12 August 2017 at 18:55, Martin Pola <mar...@kottnet.net> wrote:

> Hello,
>
> I am trying to access Archiva through HTTPS, and from what I have
> understood the easiest way to accomplish that is by having another,
> HTTPS-enabled, web server acting as a proxy.
>
> My Archiva instance listens on 127.0.0.1:8080 and my Nginx server block
> looks like this:
>server
>{
>listen [...]:443 ssl;
>server_name [...]
>underscores_in_headers on;
>
>ssl on;
>ssl_certificate /etc/letsencrypt/live/[...]/fullchain.pem;
>ssl_certificate_key /etc/letsencrypt/live/[...]/privkey.pem;
>
>location /
>{
>include proxy_params;
>proxy_pass http://127.0.0.1:8080;
>}
>}
>
> The included file `proxy_params` contains these lines:
>proxy_set_header Host $http_host;
>proxy_set_header X-Real-IP $remote_addr;
>proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>proxy_set_header X-Forwarded-Proto $scheme;
>
> When I try to visit the proxy, Archiva doesn't load. Having opened the
> web browser's developer toolkit, the error appears to have been caused
> by a GET request to
>/restServices/archivaServices/commonServices/getAllI18nResources
> which the server responded to with error 403 Forbidden. If I try to
> visit Archiva directly, through http://127.0.0.1:8080, the equivalent
> GET request does not return any error. From what I can tell, the same
> request headers seem to be sent, and the same response headers are
> received.
>
> What could be causing the issue, and how should I proceed to resolve it?
>
> Kind regards,
> Martin Pola
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: clean remote proxy caches?

[Olivier Lamy]

Hi,
No I don't see anything to help via the ui. (well a rm on the machine will
work better :-) )
Anyway sounds like a good new feature to implement.
Feel free to create a jira entry for that! (and the best with a pull
request :-) )
Cheers
Olivier

On 14 June 2017 at 18:23, Kristian Rink <kawazu...@gmail.com> wrote:

> Folks;
>
> our archiva VM currently is running low on disk space, and I found that
> (obviously) most of the space is allocated by archiva having a proxy
> configuration and caching maven central.
>
> This is generally useful but I would like to clean it up a bit. Is
> there a way to wipe all *remote* / cached artifacts older than 
> days? I generally like the caching feature but I do not need caching
> for, say,  different release versions of remote artifacts...
>
> TIA and all the best,
> Kristian
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: help with upgrade -- CSRF / Redback / proxy

[Olivier Lamy]

Maybe we should rewrite the configuration as it's a mix of legacy
properties xml etc...
I guess it's not really clear :-)
Maybe for 3.0.0?

On 1 June 2017 at 15:20, Martin Stockhammer <marti...@apache.org> wrote:

> Hi,
>
> it is mentioned in the release notes. But not clear enough, I think. I
> will improve the docs.
>
> Greetings
>
> Martin
>
> Am 1. Juni 2017 05:02:14 MESZ schrieb Adam Brin <
> ab...@digitalantiquity.org>:
> >Martin,
> >Thank you, that really helped.  It might be nice to identify some of
> >this
> >in the upgrade notes for 2.2.3, I definitely missed all of this when I
> >went
> >to try and figure out what was broken.
> >
> >- adam
> >
> >On Wed, May 31, 2017 at 1:15 PM, Martin <marti...@apache.org> wrote:
> >
> >> Yes, thats the right place to configure it.
> >>
> >> redback properties have been moved to  archiva.xml
> >> Inside the
> >> 
> >> 
> >> ...
> >> 
> >> 
> >> Element.
> >>
> >> This section is also changed, when you change the Redback Runtime
> >> properties
> >> by the WebUI:
> >> http://archiva.apache.org/docs/2.2.3/adminguide/redback-
> >> runtime-configuration.html#Runtime_properties
> >>
> >> But in this case editing via WebUI only works, if you have a browser
> >behind
> >> the reverse proxy. So you may want to edit the archiva.xml manually
> >>
> >> In your case this should be:
> >> 
> >> ...
> >> 
> >> ...
> >>   
> >> 
> >>   false
> >>   false
> >>   
> >> true
> >>   
> >> 
> >> http://dev.server.com:9
> >>   
> >> ...
> >> 
> >> ...
> >> 
> >>
> >> Info about configuration files can be found at:
> >>
> >http://archiva.apache.org/docs/2.2.3/adminguide/configuration-files.html
> >>
> >>
> >> Greetings
> >>
> >> Martin
> >>
> >>
> >> Am Mittwoch, 31. Mai 2017, 21:41:02 CEST schrieb Niranjan Babu Bommu:
> >> > I had same problem when I upgarded archiva, issue was fixed by
> >adding
> >> > rest.baseUrl in archiva.xml and restart archiva
> >> >
> >> > <https://archiva-repository.apache.org/>
> >> > rest.baseUrl=.https://dev.server.com/archiva
> >> >
> >> >
> >> > On Wed, May 31, 2017 at 2:35 PM, Adam Brin
> ><ab...@digitalantiquity.org>
> >> >
> >> > wrote:
> >> > > Hi,
> >> > >
> >> > >  We proxy our archiva install behind nginx such that
> >> > >
> >> > > https://dev.server.com/archiva/ —> http://localhost:9/ . I’ve
> >been
> >> > > trying to read the documentation on how to update, but I’m
> >afraid, I’m
> >> a
> >> > > bit lost.  A few questions:
> >> > >
> >> > > Where is the redback config stored, is it in
> >> apps/archiva/WEB-INF/classes/
> >> > > org/apache/archiva/redback-security.properties ?   If so, can
> >this be
> >> > > added to the doc, and also, moved into the conf/ directory? If
> >not,
> >> where
> >> > > is it?
> >> > > when I start archiva and go to the URL, I get the following
> >warning…
> >> > > Referer Header does not match: refererUrl=https://dev.server.
> >> com/archiva/,
> >> > > targetUrl=http://dev.tdar.org. Matches: Host=true, Port=false .
> >But, I
> >> > > don’t see how to fix the port issue according to the doc (
> >> > > http://archiva.apache.org/redback/configuration.html#
> >> > > REST_security_settings).
> >> > >
> >> > > help?
> >> > >
> >> > > thanks
> >>
> >>
> >>
> >
> >
> >--
> >_
> >Adam Brin
> >Director of Technology, Digital Antiquity
> >480.965.1278
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Trouble getting rest working

[Olivier Lamy]

Hi,
This rest service need authz

On 10 January 2017 at 17:08, Roberts, Geoffry C. (Ctr) <
geoffry.robe...@nist.gov> wrote:

> All,
>
> I am new to archiva.  Ultimately, I need to have ansible download an
> artifact from archiva and run it.  For now, I’ll settle for getting
> anything restful working.
>
> I have artifacts deployed to my respository, but when I run
>
> $> wget http:///restServices/archivaServices/
> searchService/getAllGroupIds<http://%3chost:port%3e/
> restServices/archivaServices/searchService/getAllGroupIds>,  I get a 403
> forbidden error.   Am I doing things correctly?
>
> Thanks
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Rebuilding the repository

[Olivier Lamy]

Hey
Did  you delete all files from the repo or only few?
I would delete all otherwise the jackrabbit db will be really corrupted!

On 28 September 2016 at 20:46, <m...@mherrn.de> wrote:

> Hi Martin,
>
> > a rescan (directories scanning action) does not help?
>
> I have done that and now the server has massive load since days (the IO
> connection is unfortunately very bad, so that may be the main cause).
> However the problems about missing bundles still persists.
> I have to recheck this with a new empty repository.
>
> If this doesn't help, do you have an idea on how to best recreate the
> repostory then?
>
> > For 2: would be great if you can create a issue in the Jira.
>
> OK, I will do that.
>
> Best regards
> Marco
>
>
>
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva to Attic? Asking contribution

[Olivier Lamy]

Hi Mehul,
First you need to understand Apache Archiva is an opensource project
maintained by volunteers (which accept help :-) ).
So depending on those volunteers spare time, the activity can vary a lot.
I was just asking other here.
It looks we may have find Martin who looks happy to help.
I cannot promise you anything on the project.
Remember it's opensource depending on committer spare time.

Olivier



On 13 September 2016 at 22:24, Mehul Sanghvi <mehul.sang...@gmail.com>
wrote:

> I just joined the users mailing list a couple of days, to start looking at
> Archiva.  I am coming from a Nexus
> background, but to get things like staging repositories, we have to pay for
> all the other junk that we don't want.
>
> Based on this email thread, it seems Archiva might be starting to head down
> on the road toward the archives.
>
> Should I still consider a move to Archiva ?
>
> cheers,
>
>   mehul
>
>
> On Mon, Sep 12, 2016 at 3:24 PM, Martin Stockhammer <m.stockham...@web.de>
> wrote:
>
> > Hi Olivier,
> >
> > I like archiva, because it's simple and lightweight comparing to nexus
> and
> > artifactory.
> > It has some advantages to the other two main repository implementations:
> > - You can deploy it on any application server (e.g. we use it on
> WebSphere)
> > - it does not claim to be a "multipurpose all providing" repository, it's
> > only
> >  a simple maven repository with a basic set of permission roles
> > - it's completely open source
> >
> > There are some issues that could/should be solved but I think it's ok,
> when
> > there are no major changes the next time.
> > I'm willing to help (I have already sent some pull requests via github)
> and
> > looking forward to suggestions what could be improved.
> >
> > I must say, it was very easy to setup the build environment. The maven
> > build
> > and tests are working very well. And the code where I had to investigate
> > some
> > issues was clear and understandable (great work!).
> >
> > So if I can help, feel free to contact me. I'm subscribed to the mailing
> > lists
> > already.
> >
> > Greetings
> >
> > Martin
> >
> >
> > > Hi everyone,
> > > I'm a bit sad to say I don't have anymore a lot of time to contribute
> to
> > > the project.
> > > We have a very limited number of contributor.
> > > So we ask if you are interested to help/contribute to the project.
> > > Otherwise we will have to move the project to the Attic land [1]
> > > Let us know if you are interested!
> > >
> > >
> > > Cheers
> > > --
> > > Olivier Lamy on behalf of Apache Archiva PMC
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> > > [1] http://attic.apache.org/
> >
>
>
>
> --
> Mehul N. Sanghvi
> email: mehul.sang...@gmail.com
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva 2.2.x, resetting password

[Olivier Lamy]

On 17 August 2016 at 09:08, Thad Humphries <thad.humphr...@gmail.com> wrote:

> Thanks. I tried something similar before (see
> http://www.mail-archive.com/users@archiva.apache.org/msg02910.html) by
> creating a ~/.m2/security.properties file, but I set
> security.policy.password.previous.count to -1. Maybe zero will work for me
> this time.
>
> Frankly, I'm not familiar enough with the nits of Archiva administration to
> follow you on your fix. I am not running  Archiva under Tomcat but simply
> starting it on port 8080:
>
> $ cd /opt/apache-archiva-2.2.0
> $ nohup bin/archiva console start &
>
> I may be stuck rebuilding it (or switching to Nexus).
>

mvn clean install -DskipTests
This doesn't work?
We will be definitely very happy to have more people to help (fixing issues
etc...)
Yup that's an open source project which doesn't any company supporting it
so it relies on contributor spare time.
Personally I have a very limited one ATM.
I'm pretty sure if you provide patches or pull request you will quickly
gain commit karma.

Cheers
Olivier



>
> On Tue, Aug 16, 2016 at 6:32 PM, Jörg Schaible <joerg.schai...@gmx.de>
> wrote:
>
> > Hi Thad,
> >
> > Thad Humphries wrote:
> >
> > > Despite earlier efforts to get Archiva to stop requiring password
> reset,
> > > it's done it again. Now neither user nor admin can get in and the
> "Reset
> > > Password" button seems to do nothing.
> > >
> > > How can I clear the old passwords and reset the admin and users? Or (as
> > > done at least once before) must I blow it all away an reinstall?
> > >
> > > Can't this "feature" be disable? There is *at most* only two of using
> > > this.
> >
> > I had also a very annoying fight with this and I am only one. I found
> > finally a location to turn the expiration off (at least I hope so):
> >
> >  %< ===
> > $ sudo cat /var/lib/archiva/security.properties
> > security.policy.password.previous.count=0
> > security.policy.password.expiration.enabled=false
> >  %< ===
> >
> > However, I was in the same situation as you and I finally created a new
> DB
> > for the Archiva users, configured Archiva to use that one instead and let
> > it
> > recreate an admin and guest user (note, you have to turn off password
> > expiration before). Then I exported the two JDOUSER* tables, dropped
> > anything in these tables of the original DB and imported the data. After
> > that I configured Archiva to use the original User DB again. Now I could
> > login as admin again and was able to recreated my user.
> >
> > Note: Always shut down Tomcat before you change something in the DB.
> >
> > Hope this works for you also.
> >
> > Cheers,
> > Jörg
> >
> >
>
>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 121-24)
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Is there an easier way to import remote repository certificates into trustStore?

[Olivier Lamy]

Hi
This doesn't exists
Maybe add an option for remote repositories to automatically import certs?

On Monday, 27 June 2016, Carsten Klein  wrote:

> For example a plugin for archiva that lets me specify the keystore and a
> passphrase and automated import of the certificates from remote
> repositories?
>
> Regards
>
> Carsten
>


-- 
Olivier

[ANN] Apache Archiva 2.2.1 Released

[Olivier Lamy]

The Apache Archiva team is pleased to announce the release of Archiva
2.2.1. Archiva is available for download from the web site.

Archiva is an application for managing one or more remote
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

Apache Archiva 2.2.1 is a bugs fix release:

NOTE: jdk 1.7 is now prerequisite with Apache Archiva 2.2.1

Compatibility Changes

If upgrading from earlier versions of Archiva, the list of libraries
in wrapper.conf has changed. If you have customized your copy of
wrapper.conf, please update it for compatibility with the version
distributed with the current release.
As the database storage has been removed, you can remove the JNDI
entry for jdbc/archiva.

Refer to the Upgrading Archiva guide for more information.

Release Notes

** Improvement
* [MRM-1201] - Artifact upload success message should mention the classifier
* [MRM-1906] - Allowing filtering of LDAP groups

** Bug * [MRM-1873] - archiva doesn't recognise ldap-group to ldap-users
mapping * [MRM-1877] - Checksum files always recreated * [MRM-1879] - Bug
in create-missing-checksum consumer * [MRM-1886] - View Artifact Content
Action does not Work * [MRM-1887] - Syntax error in DOAP file release
section; wrong bug- database URL * [MRM-1892] - Only One Page of Proxy
Connector Rules Shown * [MRM-1893] - Please delete old releases from
mirroring system * [MRM-1896] - Invalid link to license * [MRM-1914] -
Maven cannot find dependency Have fun! -- The Apache Archiva Team

Re: Archvia takes abour 30~50 mins to start up

[Olivier Lamy]

Hi
Have you try removing the file call metadata-store-jcr* (from WEB-INF/lib)
with an other one call metadata-store-file*
Version must match you can find it here:
http://repo.maven.apache.org/maven2/org/apache/archiva/metadata-store-file/

Olivier

On 17 May 2016 at 04:37, Charlie Kim <charl...@yahoo-inc.com.invalid> wrote:

> Hi there again.I've tried removing ${appserver.base}/data/jcr but it takes
> forever to delete themIs there way to disable jcr completely?Thanks
>
>   From: Charlie Kim <charl...@yahoo-inc.com.INVALID>
>  To: "users@archiva.apache.org" <users@archiva.apache.org>
>  Sent: Friday, March 18, 2016 8:11 AM
>  Subject: Re: Archvia takes abour 30~50 mins to start up
>
> Hi there, any update on this?Thanks.
>
>   From: Charlie Kim <charl...@yahoo-inc.com>
>  To: "users@archiva.apache.org" <users@archiva.apache.org>
>  Sent: Monday, March 14, 2016 5:28 PM
>  Subject: Re: Archvia takes abour 30~50 mins to start up
>
> Thank Oliver,What about
> https://github.com/apache/archiva/blob/8c67ef5e755b9569d5b4edeba152a06d6e66443e/archiva-modules/archiva-web/archiva-webapp/src/main/resources/META-INF/spring-context.xml?I
> tried commenting those beans but getting bunch exceptions related to
> failure to create beans.
> I change to repositorySessionFactory#file but it still looks like it's
> using jcr.2016-03-15 00:27:32,921 INFO
> [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/]]
> Initializing Spring root WebApplicationContext2016-03-15 00:27:41,143 INFO
> [org.apache.archiva.metadata.repository.jcr.ArchivaJcrRepositoryConfig] no
> repository.xml file in path /home/y/var/yarchiva/conf/repository.xml so use
> default from resources path
> org/apache/archiva/metadata/repository/jcr/repository.xml2016-03-15
> 00:27:41,258 INFO  [org.apache.jackrabbit.core.RepositoryImpl] Starting
> repository...2016-03-15 00:27:41,264 INFO
> [org.apache.jackrabbit.core.fs.local.LocalFileSystem] LocalFileSystem
> initialized at path /home/y/var/yarchiva/data/jcr/repository2016-03-15
> 00:27:41,394 INFO  [org.apache.jackrabbit.core.fs.local.LocalFileSystem]
> LocalFileSystem initialized at path
> /home/y/var/yarchiva/data/jcr/version2016-03-15 00:27:42,424 INFO
> [org.apache.jackrabbit.core.fs.local.LocalFileSystem] LocalFileSystem
> initialized at path /home/y/var/yarchiva/data/jcr/version/blobs
>
>   From: Olivier Lamy <ol...@apache.org>
>  To: Charlie Kim <charl...@yahoo-inc.com>
> Cc: "users@archiva.apache.org" <users@archiva.apache.org>
>  Sent: Monday, March 14, 2016 5:00 PM
>  Subject: Re: Archvia takes abour 30~50 mins to start up
>
> Hi
> Sorry to not reply faster!!
> Yup you can remove content from ${appserver.base}/data/jcr.
> You can switch for file based instead of jcr
> See WEB-INF/classes/applicationContext.xml
>
> https://github.com/apache/archiva/blob/1.4-M2-RC/archiva-modules%2Farchiva-web%2Farchiva-webapp%2Fsrc%2Fmain%2Fwebapp%2FWEB-INF%2FapplicationContext.xml#L78
>
> replace with  alias="repositorySessionFactory"/>
>
> I have never tested that. I think you will have to put manually the jar
> from
>
> http://repo.maven.apache.org/maven2/org/apache/archiva/metadata-store-file/1.4-M1/
> (as I'm not sure if it's included in the distribution)
>
> HTH
> Olivier
>
>
>
> On 15 March 2016 at 09:12, Charlie Kim <charl...@yahoo-inc.com> wrote:
>
> > Hi there again,
> >
> > How do I disable jcr repository? It seems like its only used for content
> > storage Prior to version 1.4-M1
> > Do you mean to remove directory ${appserver.base}/data/jcr?
> >
> >
> >
> > --
> > *From:* Charlie Kim <charl...@yahoo-inc.com>
> > *To:* Olivier Lamy <ol...@apache.org>; "users@archiva.apache.org" <
> > users@archiva.apache.org>
> > *Sent:* Tuesday, March 8, 2016 7:53 AM
> > *Subject:* Re: Archvia takes abour 30~50 mins to start up
> >
> > How do I clean it?
> > Also, is there way to disable it from start up?
> > Thank
> >
> >
> > --
> > *From:* Olivier Lamy <ol...@apache.org>
> > *To:* users@archiva.apache.org; Charlie Kim <charl...@yahoo-inc.com>
> > *Sent:* Tuesday, March 8, 2016 2:32 AM
> > *Subject:* Re: Archvia takes abour 30~50 mins to start up
> >
> > Hi
> > That is definitely not expected
> > A workaround is to clean jackarabbit repo.
> > But I don't understand why is it used at startup
> >
> >
> > On 3 March 2016 at 04:54, Charlie Kim <charl...@yahoo-inc.com.invalid>
> > wrote:
> >
> 

Re: Archvia takes abour 30~50 mins to start up

[Olivier Lamy]

Hi
That is definitely not expected
A workaround is to clean jackarabbit repo.
But I don't understand why is it used at startup


On 3 March 2016 at 04:54, Charlie Kim <charl...@yahoo-inc.com.invalid>
wrote:

>
> 2016-03-02 02:01:28,258 INFO
> [org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager]
> cachename=defaultBundleCache[ConcurrentCache@3bdcbb49], elements=1626,
> usedmemorykb=8189, maxmemorykb=8192, access=46736, miss=466732016-03-02
> 02:02:28,553 INFO
> [org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager]
> cachename=defaultBundleCache[ConcurrentCache@3bdcbb49], elements=1636,
> usedmemorykb=8188, maxmemorykb=8192, access=51435, miss=513722016-03-02
> 02:03:29,244 INFO
> [org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager]
> cachename=defaultBundleCache[ConcurrentCache@3bdcbb49], elements=1613,
> usedmemorykb=8188, maxmemorykb=8192,
> 2016-03-02 02:28:34,695 INFO  [org.apache.catalina.startup.Catalina]
> Server startup in 2399206 ms
>
> And sda busy goes up to 100% which I think it's doing indexing stuff.Is
> there way to turn this off or configure it to make it run faster?We are
> running with 1.4-M2.Thanks.
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva failed to stop

[Olivier Lamy]

Hi
I'm not sure about any know issue.
BTW with 2.2 we upgraded Maven Indexer version which change locking
mechanism.
Maybe worth to try it.

Cheers
Olivier

On 29 January 2016 at 11:32, Charlie Kim <charl...@yahoo-inc.com.invalid>
wrote:

>
>
> "localhost-startStop-2" daemon prio=10 tid=0x0becb800 nid=0x7cf6
> waiting on condition [0x7f47ad5d1000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0005914d55d8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> at
> org.apache.maven.index.context.DefaultIndexingContext.lockExclusively(DefaultIndexingContext.java:198)
> at
> org.apache.maven.index.context.DefaultIndexingContext.close(DefaultIndexingContext.java:759)
> at
> org.apache.maven.index.DefaultNexusIndexer.removeIndexingContext(DefaultNexusIndexer.java:222)
>
>
>
> pool-1-thread-1" prio=10 tid=0x0358e800 nid=0x5bbd waiting on
> condition [0x7f47accc9000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0005914d55d8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> at
> org.apache.maven.index.context.DefaultIndexingContext.lockExclusively(DefaultIndexingContext.java:198)
> at
> org.apache.maven.index.context.DefaultIndexingContext.close(DefaultIndexingContext.java:759)
> at
> org.apache.maven.index.context.DefaultIndexingContext.doCommit(DefaultIndexingContext.java:677)
> at
> org.apache.maven.index.context.DefaultIndexingContext.commit(DefaultIndexingContext.java:626)
> at
> org.apache.maven.index.DefaultNexusIndexer.addArtifactToIndex(DefaultNexusIndexer.java:373)
>
>
> Hi there, it seems that Archiva was trying to close indexes on shutdown
> but failed. See
> https://archiva.apache.org/ref/1.4-M4/xref/org/apache/archiva/admin/repository/managed/DefaultManagedRepositoryAdmin.html#138I
> see 2 threads tries to lock.  One tries to add another tries to delete.Is
> there known issue about this?Thanks.We are running 1.4-M2




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: How to increase maximum artifact size for Archiva 2.2?

[Olivier Lamy]

Hi,
Did you get issues with large files?
Otherwise with the jetty container you should have a look at
https://wiki.eclipse.org/Jetty/Howto/Configure_Form_Size

HTH
Olivier


On 17 November 2015 at 08:44, Christopher Penrose <
christopherpenr...@gmail.com> wrote:

> Hi all,
>
> I have successfully configured Archiva 1.3.x to accept artifacts which are
> larger than the default setting via the struts.multipart.maxSize property
> in archiva/apps/archiva/WEB-INF/classes/struts.properties.
>
> This properties file, and its maxSize property are no longer present in
> Archiva 2.2, and I have been unable to find documentation that covers
> artifact size for Archiva 2.x. How can I configure archiva to accept larger
> artifact sizes?
>
> Thanks!
>
> Christopher




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: MariaDB

[Olivier Lamy]

Hi,
I guess jetty.xml is specific to jetty container.
So as you use Glassfish you must have a look at the Glassfish documentation
and how to create datasources with Glassfish.

HTH
Olivier

On 24 November 2015 at 00:26, Andreas Ernst <a...@ae-online.de> wrote:

> Hi Olivier,
>
> Am 22.11.15 um 11:58 schrieb Olivier Lamy:
>
>> jdbc/archiva is not used anymore but users is used.
>> see
>>
>> https://github.com/apache/archiva/blob/master/archiva-jetty/src/main/conf/jetty.xml
>>
>
> i saw that jdbc/archiva is not used anymore.
>
> However, i put jetty.xml into domain/conf, but i does not have any effect:
>
> <...>
>
>   
>
>   
> jdbc/users
> 
>   
>  name="url">jdbc:mariadb://localhost:3306/archiva?autoReconnect=true
> archiva
> archiva
> pw
>   
> 
>   
>
>   
> jdbc/usersShutdown
> 
>   
> archiva
> archiva
> shutdown
>   
> 
>   
>
> <...>
>
> Or should i do this into conf/archiva.xml?
>
> Thanks
>
> Andy
> --
> ae | Andreas Ernst | IT Spektrum
> Postfach 5, 65612 Beselich
> Schupbacher Str. 32, 65614 Beselich, Germany
> Tel: +49-6484-91002 Fax: +49-6484-91003
> a...@ae-online.de | www.ae-online.de
> www.tachyon-online.de
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: MariaDB

[Olivier Lamy]

jdbc/archiva is not used anymore but users is used.
see
https://github.com/apache/archiva/blob/master/archiva-jetty/src/main/conf/jetty.xml

HTH
Olivier

On 20 November 2015 at 01:13, Andreas Ernst <a...@ae-online.de> wrote:

> Hi,
>
> i deployed Archiva on Payara/GlassFish 4.1.1.154. For installation you
> need the Derby DB up and runing.
>
> Now i want to go back to MariaDB.
>
> http://archiva.apache.org/docs/2.2.0/adminguide/databases.html, but i got
> no conf/jetty.xml.
>
> asadmin> list-resource-refs
> jdbc/__TimerPool
> jdbc/__default
> jms/__defaultConnectionFactory
> concurrent/__defaultManagedScheduledExecutorService
> concurrent/__defaultContextService
> concurrent/__defaultManagedThreadFactory
> concurrent/__defaultManagedExecutorService
> mail/Session
> mailSession
> jdbc/archiva
> jdbc/users
> Command list-resource-refs executed successfully.
>
> The jdbc/users is not used. The documentation is not really clear at this
> point.
>
> TIA
> Andy
> --
> ae | Andreas Ernst | IT Spektrum
> Postfach 5, 65612 Beselich
> Schupbacher Str. 32, 65614 Beselich, Germany
> Tel: +49-6484-91002 Fax: +49-6484-91003
> a...@ae-online.de | www.ae-online.de
> www.tachyon-online.de
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Disable password timeout, reset

[Olivier Lamy]

Hi,

On 1 October 2015 at 02:11, Thad Humphries <thad.humphr...@gmail.com> wrote:

> I set up an Archiva 2.2 server a while back, and thought I'd succeeded in
> disabling the requirement to renew the password after so many days, not
> allow reuse of the last X number of passwords, etc. Earlier this week I was
> rudely surprised to find that I had to reset my password. How can I stop
> this?
>
> I am running Archiva on port 8080, starting it with
>
> $ cd /opt/apache-archiva-2.2.0
> $ nohup bin/archiva console start &
>
> I created a ~/.m2/security.properties file based on the one at
> http://archiva.apache.org/docs/2.2.0/adminguide/customising-security.html.
> Mine is shown below. The two properties in bold I thought would disable
> password expiration.
>
> #
> http://archiva.apache.org/docs/2.2.0/adminguide/customising-security.html
> #
>
> https://github.com/apache/archiva-redback-core/blob/master/redback-configuration/src/main/resources/org/apache/archiva/redback/config-defaults.properties
>
> # Security Policies
> #security.policy.password.encoder=
>
>
> *security.policy.password.previous.count=-1security.policy.password.expiration.enabled=false*
> security.policy.password.expiration.days=180
> security.policy.password.expiration.notify.days=10
> security.policy.allowed.login.attempt=10
>
> # Password Rules
> security.policy.password.rule.alphanumeric.enabled=false
> security.policy.password.rule.alphacount.enabled=true
> security.policy.password.rule.alphacount.minimum=1
> security.policy.password.rule.characterlength.enabled=true
> security.policy.password.rule.characterlength.minimum=1
> security.policy.password.rule.characterlength.maximum=8
> security.policy.password.rule.musthave.enabled=true
> security.policy.password.rule.numericalcount.enabled=true
> security.policy.password.rule.numericalcount.minimum=1
> security.policy.password.rule.reuse.enabled=true
> security.policy.password.rule.nowhitespace.enabled=true
>
>
> Maybe that's not enough? In looking a the archiva-redback-core on GitHub, I
> see *two additional settings* under Security Policies:
>
> # turn off the perclick enforcement of various security policies, slightly
> # more heavyweight since it will ensure that the User object on each click
> # is up to date
> security.policy.strict.enforcement.enabled=true
> security.policy.strict.force.password.change.enabled=true
>
> So, if I add these properties to my ~/.m2/security.properties file, set
> both to false, kill Archiva and restart it, will this disable the password
> reset requirement? If not, how can I do so?
>

That should work otherwise you are facing a bug :-(
You can use a file located here as well
${appserver.home}/conf/security.properties


>
> --
> "Hell hath no limits, nor is circumscrib'd In one self-place; but where we
> are is hell, And where hell is, there must we ever be" --Christopher
> Marlowe, *Doctor Faustus* (v. 121-24)
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Issue remote repository https

[Olivier Lamy]

Hi,
Which Archiva version are you using?
Any proxy?
Ensure you use https protocol.


On 25 September 2015 at 23:59, Pozo Torres, Joaquin <jptor...@indra.es>
wrote:

> Hi,
>
> So far I have not had any problems with remote repositories, but now I
> need to add a new remote repository and I have a problem. The difference
> with the previous ones is that this new is https. I've tried everything,
> add the certificate to jre , config proxy etc... but ever the same error.
> "Return code is: 503 , ReasonPhrase:Service Unavailable." And "Connection
> timed out"
>
> The connectivity is tested successfully.
>
> The remote repository is of the ZK EE framework.
>
> Someone who can help me?
>
> Thank you in advance.
>
> 
> Este correo electr?nico y, en su caso, cualquier fichero anexo al mismo,
> contiene informaci?n de car?cter confidencial exclusivamente dirigida a su
> destinatario o destinatarios. Si no es vd. el destinatario indicado, queda
> notificado que la lectura, utilizaci?n, divulgaci?n y/o copia sin
> autorizaci?n est? prohibida en virtud de la legislaci?n vigente. En el caso
> de haber recibido este correo electr?nico por error, se ruega notificar
> inmediatamente esta circunstancia mediante reenv?o a la direcci?n
> electr?nica del remitente.
> Evite imprimir este mensaje si no es estrictamente necesario.
>
> This email and any file attached to it (when applicable) contain(s)
> confidential information that is exclusively addressed to its recipient(s).
> If you are not the indicated recipient, you are informed that reading,
> using, disseminating and/or copying it without authorisation is forbidden
> in accordance with the legislation in effect. If you have received this
> email by mistake, please immediately notify the sender of the situation by
> resending it to their email address.
> Avoid printing this message if it is not absolutely necessary.
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: permission issue on newly created repository

[Olivier Lamy]

Hi,
We are not really supporting anymore 1.x versions.
Did you check roles assignment? (android-* roles as manager and observer?)
Regards
Olivier

On 24 September 2015 at 06:27, Allen Lee <al...@athenahealth.com> wrote:

> Hi,
> I ran Archiva 1.3.9 on Windows 7 and created a new Archiva Managed
> repository "android", but failed to access it with ivy. The same Ivy works
> well with "internal" repository. The following are the error message from
> log files
>
> 2015_09_23.request.log
> 10.32.10.27 -  -  [23/Sep/2015:18:33:07 +] "HEAD
> /archiva/repository/android/org/apache/zookeeper/zookeeper/3.3.6/zookeeper-3.3.6.pom
> HTTP/1.1" 401 0 "-" "Apache Ivy/2.3.0"
> 10.32.10.27 -  -  [23/Sep/2015:18:33:07 +] "HEAD
> /archiva/repository/android/org/apache/zookeeper/zookeeper/3.3.6/zookeeper-3.3.6.jar
> HTTP/1.1" 401 0 "-" "Apache Ivy/2.3.0"
>
> archiva.log
> 2015-09-23 11:33:07,061 [btpool0-2] INFO
> org.apache.maven.archiva.security.ArchivaServletAuthenticator  -
> Authorization Denied
> [ip=10.32.10.27,permission=archiva-read-repository,repo=android] : no
> matching permissions
> 2015-09-23 11:33:07,076 [btpool0-2] INFO
> org.apache.maven.archiva.security.ArchivaServletAuthenticator  -
> Authorization Denied
> [ip=10.32.10.27,permission=archiva-read-repository,repo=android] : no
> matching permissions
>
> Any idea?
>
> Thanks,
> Allen
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Basic Install Question

[Olivier Lamy]

Hi,
Not sure about relative to what. IMHO to $CATALINA_BASE/bin.

Note you can use interpolation in tomcat context file.
So url can contains reference to an env var using ${ } annotation.

something like:
url="jdbc:derby:${ARCHIVA_DB}/archiva;create=true" />



On 11 September 2015 at 07:19, Mark Faine <mark.fa...@gmail.com> wrote:

> Tomcat 7
> Archiva 2.2.0
>
> What I want to do should be very simple, however, I cannot for the life of
> me figure out how.
>
> 1. Installation of Archiva as a deployed (exploded) web application under
> /opt/tomcat/webapps
>
> 2. The repository ,data, groups and other folders are being created in
> $CATALINA_HOME, this is not where they should be, I have tried to find a
> way to set another location but I cannot figure it out.  How can I set the
> location where the folders should be created?
>
> I have my context setup in /opt/tomcat/conf/Catalina/localhost/archiva.xml
>
> 3.  The instructions state:
>
> url="jdbc:derby:/path/to/database/archiva;create=true" />
>
>
> Does /path/to/database need to be canonical, can it be relative?  If
> so, relative to what?
>
>
>
> tl;dr Essentially, I want the archiva app at the path
> /opt/tomcat/webapps/archiva and all of the resources that are
> generated from the app at /opt/archiva   However, I can't seem to
> figure out any configuration that will result in this outcome.
>
>
>
> Also, I'm getting a file created with the file name
> /opt/tomcat/conf/archiva.xml that contains some configuration for archiva,
> it should stay with archiva webapp, or at least with the archiva created
> resources in /opt/archiva
>



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: 404 error when attempting to query artifact

[Olivier Lamy]

Hi,
I think documentation is wrong as now Archiva is per default on / so use

wget 
http://hamlet:8080/restServices/archivaServices/searchService/artifact?g=my-demosa=JavaDemosv=LATEST
http://hamlet:8080/archiva/restServices/archivaServices/searchService/artifact?g=my-demosa=JavaDemosv=LATEST

Please note for this url you will have a redirect to download the artifact.

Olivier


On 17 June 2015 at 06:55, Thad Humphries thad.humphr...@gmail.com wrote:

 I have a ZIP file stored on my Archiva 2.2 server. Anyone here can reach it
 through a browser at

 http://hamlet:8080/#artifact-details-download-content/my-demos/JavaDemos/8.1
 and download it without being logged in by clicking the removable media
 icon.

 I'd like to download this file from a script, so I try the wget described
 at:

 http://archiva.apache.org/docs/2.2.0/userguide/querying-artifacts.html


 but I get a 404 error:

 $ wget 

 http://hamlet:8080/archiva/restServices/archivaServices/searchService/artifact?g=my-demosa=JavaDemosv=LATEST
 

 --2015-06-16 16:42:33--

 http://hamlet:8080/archiva/restServices/archivaServices/searchService/artifact?g=my-demosa=JavaDemosv=LATEST

 Resolving hamlet (hamlet)... 10.1.2.1

 Connecting to hamlet (hamlet)|10.1.2.1|:8080... connected.

 HTTP request sent, awaiting response... 404 Not Found

 2015-06-16 16:42:33 ERROR 404: Not Found.


 What is the problem and how do I correct it?

 --
 Hell hath no limits, nor is circumscrib'd In one self-place; but where we
 are is hell, And where hell is, there must we ever be --Christopher
 Marlowe, *Doctor Faustus* (v. 121-24)




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: unable to get LDAP/Roles Mapping to work in 2.2.0

[Olivier Lamy]

Hi

On 8 May 2015 at 10:09, Wes Wannemacher w...@wantii.com wrote:

 Still trying to figure out what's going on here... I don't really know
 knockout very well, so I'm not sure why this is happening. Anyhow, in
 js/archiva/admin/features/generaladmin/main.js lines 1393-1395:
 saveModifyLdapGroupMapping=function(){
   //save modified ldap group mappings if any
   if(self.modifiesLdapGroupMappings().length0){

 That if test fails. Since it fails, it just ignores the LDAP mappings
 and moves on back to the main Users Runtime Configuration view. The
 modifiesLdapGroupMappings is a ko.observableArray, but when the save
 button is hit, the array is empty :(.


You're in the right place.
I think there is a problem in an observable method that should must
populate this array.
You must have look what happen with the function
: this.modifyLdapGroupMapping=function(roleNames,ldapGroupMapping){
especially this one contains some logs when elements are added to the array




 If I'm heading down the wrong way, please let me know...

 -Wes

 On Thu, May 7, 2015 at 4:17 PM, Wes Wannemacher w...@wantii.com wrote:
  I've been trying to troubleshoot this issue and I'm having trouble
  following the flow of execution. I've set breakpoints in
  DefaultLdapGroupMappingService and DefaultLdapRoleMapperConfiguration.
  Neither one of the breakpoints is reached when I try to save the Ldap
  Group - Archiva Role mapping. Could the problem be in the Javascript?
  I'm not sure how to troubleshoot issues in the Javascript.
 
  Thanks again for your help.
 
  -Wes
 
  On Wed, May 6, 2015 at 11:28 PM, Wes Wannemacher w...@wantii.com
 wrote:
  Hello,
 
  I am new to archiva. I have LDAP working so that I can login with LDAP
  accounts onto my server. Also, when I am in the LDAP/Roles Mapping
  screen, the LDAP groups appear correctly in the LDAP Groups dropdown.
  However, if I setup a mapping and click the Save button, the mapping
  will be gone by the time I leave the screen and come back.
  Additionally, the mapping does not work (members of the LDAP group are
  not granted the Role that I mapped). I have tried creating a
  security.properties file with the following contents (per the redback
  docs):
 
  ldap.config.groups.role.archiva_admin=Archiva System Administrator
 
  However, this does not grant members of the archiva_admin group the
  Archiva System Administrator role. Additionally, I added the following
  snippet (on a whim) to the archiva.xml file:
  role
  archiva_adminArchiva System Administrator/archiva_admin
  /role
 
  That is added inside the:
  ldap
  config
  groups
  section. It does make a property show up in the Properties tab of the
  Users Runtime Configuration but it has no effect.
 
  The mapping I would like to setup will be permanent, so it does not
  need to work properly in the UI. I don't mind adding the configuration
  manually into a config file on the server. However, I can't seem to
  find any way to make the mapping work.
 
  -Wes
 
  --
  Wes Wannemacher
 
 
 
  --
  Wes Wannemacher



 --
 Wes Wannemacher




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Search does not return .war artifacts

[Olivier Lamy]

Hi,
This LATEST redirect is really new (last release I believe)

Olivier

On 28 April 2015 at 18:19, John Cooper john.coo...@smartfocus.com wrote:

 I didn't see any examples of that and assumed it was defined  in the POM!

 Thanks, John.

 -Original Message-
 From: Olivier Lamy [mailto:ol...@apache.org]
 Sent: 24 April 2015 23:59
 To: users@archiva.apache.org
 Subject: Re: Search does not return .war artifacts

 Hi,
 You must force packaging to war (i.e p=war)
 Sample:

 curl -I 

 https://archiva-repository.apache.org/archiva/restServices/archivaServices/searchService/artifact?r=snapshotsg=org.apache.archivaa=archiva-webappv=LATESTp=war
 

 HTTP/1.1 307 Temporary Redirect

 Date: Fri, 24 Apr 2015 22:56:24 GMT

 Server: Jetty(8.1.14.v20131031)

 Expires: Thu, 01 Jan 1970 00:00:00 GMT

 Location:

 https://archiva-repository.apache.org/archiva/repository/snapshots/org/apache/archiva/archiva-webapp/2.2.1-SNAPSHOT/archiva-webapp-2.2.1-SNAPSHOT.war

 Cache-Control: max-age=86401, public

 Set-Cookie: JSESSIONID=rbjr03uzr6j11myt9y01wajhx;Path=/

 Via: 1.1 archiva-repository.apache.org

 Content-Type: text/plain



 Note you got a redirect as response so will be easier using wget to
 download the file.

 HTH
 Olivier




 On 24 April 2015 at 21:33, John Cooper john.coo...@smartfocus.com wrote:

  Any ideas why packaging type WAR cannot be found and yet can find and
  download packaging type if set to JAR using the API?
 
  Thanks, John.
 
  -Original Message-
  From: John Cooper
  Sent: 21 April 2015 17:06
  To: users@archiva.apache.org
  Subject: Search does not return .war artifacts
 
  Hi, I've successfully deployed my snapshot  .war files to Archiva
  2.2.0 and I can wget/curl them using the direct http address. When I
  try to use the API to retrieve the latest version only POMs with
  packaging=jar  are found (version 0.1-SNAPSHOT) and download ok.
 
  curl -i -o s3-util.jar -L -u user:password
  http://localhost/restServices/archivaServices/searchService/artifact?r
  =snapshotsg=com.company.backupa=s3-utilv=LATEST
 
% Total% Received % Xferd  Average Speed   TimeTime Time
  Current
   Dload  Upload   Total   SpentLeft
  Speed
0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
 0
0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
 0
  100  333k  100  333k0 0  3538k  0 --:--:-- --:--:-- --:--:--
  3538k
 
  Trying the same for a war packaging type  doesn't find anything
 
  curl -i -o s3-util.war -L -u user:password 
  http://localhost/restServices/archivaServices/searchService/artifact?r
  =snapshotsg=com.company.backupa=s3-utilv=LATEST
  
 
% Total% Received % Xferd  Average Speed   TimeTime Time
  Current
   Dload  Upload   Total   SpentLeft
  Speed
0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
 0
 
  Am I missing something?
 
  Thanks, John.
 
 


 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Search does not return .war artifacts

[Olivier Lamy]

Hi,
You must force packaging to war (i.e p=war)
Sample:

curl -I 
https://archiva-repository.apache.org/archiva/restServices/archivaServices/searchService/artifact?r=snapshotsg=org.apache.archivaa=archiva-webappv=LATESTp=war


HTTP/1.1 307 Temporary Redirect

Date: Fri, 24 Apr 2015 22:56:24 GMT

Server: Jetty(8.1.14.v20131031)

Expires: Thu, 01 Jan 1970 00:00:00 GMT

Location:
https://archiva-repository.apache.org/archiva/repository/snapshots/org/apache/archiva/archiva-webapp/2.2.1-SNAPSHOT/archiva-webapp-2.2.1-SNAPSHOT.war

Cache-Control: max-age=86401, public

Set-Cookie: JSESSIONID=rbjr03uzr6j11myt9y01wajhx;Path=/

Via: 1.1 archiva-repository.apache.org

Content-Type: text/plain



Note you got a redirect as response so will be easier using wget to
download the file.

HTH
Olivier




On 24 April 2015 at 21:33, John Cooper john.coo...@smartfocus.com wrote:

 Any ideas why packaging type WAR cannot be found and yet can find and
 download packaging type if set to JAR using the API?

 Thanks, John.

 -Original Message-
 From: John Cooper
 Sent: 21 April 2015 17:06
 To: users@archiva.apache.org
 Subject: Search does not return .war artifacts

 Hi, I've successfully deployed my snapshot  .war files to Archiva 2.2.0
 and I can wget/curl them using the direct http address. When I try to use
 the API to retrieve the latest version only POMs with packaging=jar  are
 found (version 0.1-SNAPSHOT) and download ok.

 curl -i -o s3-util.jar -L -u user:password
 http://localhost/restServices/archivaServices/searchService/artifact?r=snapshotsg=com.company.backupa=s3-utilv=LATEST

   % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
  Dload  Upload   Total   SpentLeft
 Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
0
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
0
 100  333k  100  333k0 0  3538k  0 --:--:-- --:--:-- --:--:--
 3538k

 Trying the same for a war packaging type  doesn't find anything

 curl -i -o s3-util.war -L -u user:password 
 http://localhost/restServices/archivaServices/searchService/artifact?r=snapshotsg=com.company.backupa=s3-utilv=LATEST
 

   % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
  Dload  Upload   Total   SpentLeft
 Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
0

 Am I missing something?

 Thanks, John.




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Configuring Archiva without setting Tomcat-wide properties

[Olivier Lamy]

Hi David,
Sadly I'm not really it's possible :-(
You need to investigate but there are probably few places where the code
can use System.getProperty(appserver.base) (which is very bad: I agree!!!)




On 8 April 2015 at 02:17, David North dtn-arch...@corefiling.co.uk wrote:

 Hi,

 After some successful experiments with Archiva running using its
 built-in Jetty server, we're working on deployment for real. We
 usually deploy web apps onto Tomcat, and I'd like to do the same here.

 The instructions at
 http://archiva.apache.org/docs/2.2.0/adminguide/webapp.html all work as
 expected. However, I am unhappy about having to set appserver.home and
 appserver.base in a Tomcat-wide manner using system properties (via
 setenv.sh).

 Is it possible to configure these on a per-webapp basis in
 conf/Catalina/localhost/archiva.xml ?

 I see from digging into the source code a bit that Archiva uses Commons
 Configuration to obtain most of its settings, so I was rather hoping it
 would be possible to pass appserver.home and appserver.base in the
 context file using JNDI or similar. Can anyone confirm if this is
 possible and, if so, give an example?

 Thanks,
 David




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Getting maven-metadata.xml to show up

[Olivier Lamy]

On 31 March 2015 at 02:32, Dave Brosius dbros...@mebigfatguy.com wrote:

 We recently upgraded to archiva 2.2.0 (pretty!) and are having problems


 What's the trick to get the maven-metadata.xml file to show. When we
 upload a file thru the gui, checking the generate pom checkbox, the file
 gets send and when we browse to that directory, it shows the file along
 with the pom, but not the other two files. Is there some trick to get that
 to work?


Should be available using the /repository browsing.
As https://archiva-repository.apache.org/archiva/repository/snapshots/

You'd like seeing those metadata files using #browse ui?





 As an aside, you confused the bajeebers out of us with that 'Save Files'
 button. It took us a few hours to figure out how the hell to upload thru
 the gui. Still don't get the point of it.


The idea is to be able to upload multiple files for the same gav



 dave





-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: [IMPORTANT NOTICE] Jira migration from Codehaus to Apache on April 4th

[Olivier Lamy]

Hi,
The project has been migrated to Apache instance.
It's now available here: https://issues.apache.org/jira/browse/MRM

Cheers
Olivier

On 25 March 2015 at 13:56, Olivier Lamy ol...@apache.org wrote:

 Hi,
 As you probably know Codehaus will be shutdown soon [1].
 So we need to migrate our jira project to Apache instance.


 We'll create the exact same Jira projects at ASF  than what we have at
 Codehaus, copy the whole content and mark Codehaus read-only.
 See https://issues.apache.org/jira/browse/INFRA-9116

 How will username migration from Codehaus to ASF happen?

 When migrating existing content, user accounts will be migrated too (that's
 the way Jira works).

 To avoid creating accounts that already exist at Apache, matching will be
 done
 on account's e-mail address. The mapping will look something like:

 for each e-mail/username pair in the Codehaus content
   if the email is associated with a user in the ASF Jira instance, reuse:
 update the username from imported content to the ASF username
   else we'll create a new account in the ASF Jira instance:
 if the username already exists in the ASF Jira instance (another email)
   update the imported username to append -[SUFFIX] to the end
 else
   use the imported username/email as is

 The exact [SUFFIX] still needs to be defined.

 If you want to be sure of your username at Apache Jira, please take a look
 at
 your e-mail at Codehaus and check that it matches the e-mail at your Apache
 Jira account.


 If you have any question, don't hesitate to ask.

 We'll keep you informed as the operation is planned more in details.

 Cheers
 --
 The Archiva Team


 [1] http://www.codehaus.org/




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

[IMPORTANT NOTICE] Jira migration from Codehaus to Apache on April 4th

[Olivier Lamy]

Hi,
As you probably know Codehaus will be shutdown soon [1].
So we need to migrate our jira project to Apache instance.


We'll create the exact same Jira projects at ASF  than what we have at
Codehaus, copy the whole content and mark Codehaus read-only.
See https://issues.apache.org/jira/browse/INFRA-9116

How will username migration from Codehaus to ASF happen?

When migrating existing content, user accounts will be migrated too (that's
the way Jira works).

To avoid creating accounts that already exist at Apache, matching will be
done
on account's e-mail address. The mapping will look something like:

for each e-mail/username pair in the Codehaus content
  if the email is associated with a user in the ASF Jira instance, reuse:
update the username from imported content to the ASF username
  else we'll create a new account in the ASF Jira instance:
if the username already exists in the ASF Jira instance (another email)
  update the imported username to append -[SUFFIX] to the end
else
  use the imported username/email as is

The exact [SUFFIX] still needs to be defined.

If you want to be sure of your username at Apache Jira, please take a look
at
your e-mail at Codehaus and check that it matches the e-mail at your Apache
Jira account.


If you have any question, don't hesitate to ask.

We'll keep you informed as the operation is planned more in details.

Cheers
-- 
The Archiva Team


[1] http://www.codehaus.org/

Re: small bug in create-missing-checksums consumer

[Olivier Lamy]

On 19 March 2015 at 21:11, Isabelle Guimiot isabelle.guim...@gmail.com
wrote:

 Hi,

 I noticed that checksum files were always created again on all the
 artifacts during each repo scanning. In the log, I could see messages like
 :

  Created missing checksum file

 /archiva_install/repositories/internal/com/company/project/myjar/1.2/myjar-1.2.jarsha1

 There's a dot missing at the end of the path, should be myjar-1.2.jar.sha1
 instead of myjar-1.2.jarsha1 , and I think this issue comes from this line
 in the code, file ArtifactMissingChecksumsConsumer.java :

  File checksumFile = new File( this.repositoryDir, path +
 checksumAlgorithm[0].getExt() );

 It should be :

  File checksumFile = new File( this.repositoryDir, path + . +
 checksumAlgorithm[0].getExt() );

 Because without the dot, it doesn't find the checksum file, wrongly thinks
 it's missing, and re-creates it ! It's not a blocker bug, but it slows down
 large repos scanning...


Sounds definitely a bug :-)



 Need a jira for this ?


Yes please (just to have a reminder :-) )


 Thanks !

 Isabelle




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: small bug in create-missing-checksums consumer

[Olivier Lamy]

so I had a bit of time and fixed that.
Thanks for reporting the issue!!

On 23 March 2015 at 10:49, Olivier Lamy ol...@apache.org wrote:



 On 19 March 2015 at 21:11, Isabelle Guimiot isabelle.guim...@gmail.com
 wrote:

 Hi,

 I noticed that checksum files were always created again on all the
 artifacts during each repo scanning. In the log, I could see messages
 like :

  Created missing checksum file

 /archiva_install/repositories/internal/com/company/project/myjar/1.2/myjar-1.2.jarsha1

 There's a dot missing at the end of the path, should be myjar-1.2.jar.sha1
 instead of myjar-1.2.jarsha1 , and I think this issue comes from this line
 in the code, file ArtifactMissingChecksumsConsumer.java :

  File checksumFile = new File( this.repositoryDir, path +
 checksumAlgorithm[0].getExt() );

 It should be :

  File checksumFile = new File( this.repositoryDir, path + . +
 checksumAlgorithm[0].getExt() );

 Because without the dot, it doesn't find the checksum file, wrongly thinks
 it's missing, and re-creates it ! It's not a blocker bug, but it slows
 down
 large repos scanning...


 Sounds definitely a bug :-)



 Need a jira for this ?


 Yes please (just to have a reminder :-) )


 Thanks !

 Isabelle




 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Documentation suggestion for ARCHIVA_BASE and 'Installing as a Service on Linux'

[Olivier Lamy]

Thanks a lot for your investigations!!

I wonder if you could simply create a pull request for that here
https://github.com/apache/archiva ?
The file is located here
https://github.com/apache/archiva/blob/master/archiva-docs/src/site/apt/adminguide/standalone.apt.vm

Olivier

On 11 March 2015 at 02:40, Thad Humphries thad.humphr...@gmail.com wrote:

 I installed Archiva 2.1.1 standalone on Linux (openSUSE) with a separate
 ARCHIVA_BASE, and ran it about a month with nohup. After upgrading to
 2.2.0, I decided to run it as a service. I followed the directions at at
 http://archiva.apache.org/docs/2.2.0/adminguide/standalone.html, including
 adding myself as the RUN_AS_USER environment variable. The service started,
 but it did not pick up my ARCHIVA_BASE environment variable, which I had
 assumed to be the purpose of uncommenting bin/archiva's
 RUN_AS_USER environment variable.

 When I searched for this problem, the first hit I got was

 http://mail-archives.apache.org/mod_mbox/archiva-users/201406.mbox/%3CDE946284-8A9F-4919-9D17-B1683B1700F7%40apache.org%3E
 That pointed me to the solution: In conf/wrapper.conf, about 14 lines down,
 edit set.default.ARCHIVA_BASE=. to your ARCHIVA_BASE environment
 variable, *not* the current directory (so in my case,
 set.default.ARCHIVA_BASE=/u3/archiva).

 Unless bin/archiva is modified to pick up the RUN_AS_USER's
 ARCHIVA_BASE, *strongly
 recommend* that instruction above be added to Installing as a Service on
 Linux in docs/2.2.0/adminguide/standalone.html

 --
 Hell hath no limits, nor is circumscrib'd In one self-place; but where we
 are is hell, And where hell is, there must we ever be --Christopher
 Marlowe, *Doctor Faustus* (v. 121-24)




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: REST API: Artifact's last modified timestamp

[Olivier Lamy]

no.
But you can get it with an http call and read the header 'Last-Modified'.
Sample:
mb-olamy:parent olamy$ curl -I
https://archiva-repository.apache.org/archiva/repository/snapshots/org/apache/archiva/archiva/maven-metadata.xml

HTTP/1.1 200 OK

Date: Mon, 16 Feb 2015 10:22:49 GMT



Cache-Control: max-age=86401, public

Last-Modified: Mon, 16 Feb 2015 10:22:49 GMT




OTH

Olivier

On 14 February 2015 at 02:33, Anton fallout...@freenet.de wrote:

 http://archiva.996284.n3.nabble.com/file/n16528/last_modified.png

 Is it possible to get this information with the REST API?



 --
 View this message in context:
 http://archiva.996284.n3.nabble.com/REST-API-Artifact-s-last-modified-timestamp-tp16426p16528.html
 Sent from the User mailing list archive at Nabble.com.




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Search functionality not working

[Olivier Lamy]

Sounds weird.
Did you force an indexing of the repository?

--
Olivier
On 28 Jan 2015 12:02, Gevorg Hari gevorgh...@gmail.com wrote:

 Hello,

 I'm evaluating Archiva and I'm having the following issue. I uploaded a
 couple of artifacts in the snapshot repository and I can see them in the
 Browse section on the left. However, if I try to search them in the Search
 tab I cannot find them.

 I already tried to do Directory and Index scanning. I cannot find anything
 useful in the archiva.log. How do I debug this issue?

 Thanks!

Re: Archiva 2.2.0 release date ?

[Olivier Lamy]

Anyway remember you can download a master build :-) from
https://builds.apache.org/view/A-D/view/Archiva/job/archiva-master-build/


On 27 January 2015 at 10:19, Olivier Lamy ol...@apache.org wrote:

 Hi
 Happy new year too!
 I reckon I was out of time those last weeks (new $DAYJOB and enjoying
 summer :-) ).
 A more realistic date will be late Feb.
 Sorry for this delay!!


 On 24 January 2015 at 01:10, Isabelle Guimiot isabelle.guim...@gmail.com
 wrote:

 Hi Olivier and happy new year !

 Any realistic release date for Archiva 2.2 ? ;-)

 Thanks ! :-)

 Isabelle

 2014-11-30 22:44 GMT+01:00 Olivier Lamy ol...@apache.org:

  Hi
  I believe in 2/3 weeks sounds reasonable.
  At least for xmas!! :-)
 
  Cheers
  --
  Olivier
  On 28 Nov 2014 20:20, Isabelle Guimiot isabelle.guim...@gmail.com
  wrote:
 
   Hi Archiva Team !
  
   Yesterday, you reorganized the jira issues, deleted 2.1.2 and moved
  issues
   to 2.2.0 / 2.3.0 versions. Do you know approximately the 2.2.0 release
  date
   ? I hope it will be soon, we are still using 1.4-M4 because of blocker
  bugs
   on 2.x, that have been fixed and committed, but not released yet...
  
   Thanks a lot for all that you do !
  
   Isabelle
  
 




 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva 2.2.0 release date ?

[Olivier Lamy]

Hi
Happy new year too!
I reckon I was out of time those last weeks (new $DAYJOB and enjoying
summer :-) ).
A more realistic date will be late Feb.
Sorry for this delay!!


On 24 January 2015 at 01:10, Isabelle Guimiot isabelle.guim...@gmail.com
wrote:

 Hi Olivier and happy new year !

 Any realistic release date for Archiva 2.2 ? ;-)

 Thanks ! :-)

 Isabelle

 2014-11-30 22:44 GMT+01:00 Olivier Lamy ol...@apache.org:

  Hi
  I believe in 2/3 weeks sounds reasonable.
  At least for xmas!! :-)
 
  Cheers
  --
  Olivier
  On 28 Nov 2014 20:20, Isabelle Guimiot isabelle.guim...@gmail.com
  wrote:
 
   Hi Archiva Team !
  
   Yesterday, you reorganized the jira issues, deleted 2.1.2 and moved
  issues
   to 2.2.0 / 2.3.0 versions. Do you know approximately the 2.2.0 release
  date
   ? I hope it will be soon, we are still using 1.4-M4 because of blocker
  bugs
   on 2.x, that have been fixed and committed, but not released yet...
  
   Thanks a lot for all that you do !
  
   Isabelle
  
 




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Jenkins deployment from Archiva

[Olivier Lamy]

Hi,
If you use the Maven Job type with Jenkins you can activate the post build
step to deploy to Archiva (Deploy artifacts to Maven repository).
Note you will have to store username/password within Jenkins to deploy to
Archiva.
I recommend you use the plugin ConfigFileProvider to store and share
between jobs.



On 23 January 2015 at 05:33, Malcolm G. Davis malc...@nuearth.com wrote:

 I would like to create Jenkins job that deploys a war from Archiva.

 Is there a specific Jenkins steps or Maven configuration that will read a
 war from Archiva and deploy to an application server?

 I know many want to auto-deploy after a successful build, but there are
 internal QA steps that need to be followed, and there is tracking and
 sign-off that needs to occur.   The war is required to deploy from Archiva.

 Thanks,
 Malcolm




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Jenkins deployment from Archiva

[Olivier Lamy]

depends on your target app server.
If there is a maven plugin to deploy it that will be easy.


On 23 January 2015 at 10:24, Malcolm G. Davis malc...@nuearth.com wrote:

 I'm not looking to deploy to Archiva, I have deploying to Archiva working.

 I want to deploy from Archiva to an application server.

 Working: Jenkins - Archiva

 Need: Archiva - Jenkins - Application server

 Is there a sample Maven pom.xml that will pull from Archiva internal
 (release) and send to an application server?

 Thank you,
 Malcolm

 btw: The Archiva user name  password can be stored in the Maven super
 pom, avoiding the need to configure Jenkins

 -Original Message-
 From: Olivier Lamy [mailto:ol...@apache.org]
 Sent: Thursday, January 22, 2015 5:06 PM
 To: users@archiva.apache.org
 Subject: Re: Jenkins deployment from Archiva

 Hi,
 If you use the Maven Job type with Jenkins you can activate the post build
 step to deploy to Archiva (Deploy artifacts to Maven repository).
 Note you will have to store username/password within Jenkins to deploy to
 Archiva.
 I recommend you use the plugin ConfigFileProvider to store and share
 between jobs.



 On 23 January 2015 at 05:33, Malcolm G. Davis malc...@nuearth.com wrote:

  I would like to create Jenkins job that deploys a war from Archiva.
 
  Is there a specific Jenkins steps or Maven configuration that will
  read a war from Archiva and deploy to an application server?
 
  I know many want to auto-deploy after a successful build, but there
  are internal QA steps that need to be followed, and there is tracking and
  sign-off that needs to occur.   The war is required to deploy from
 Archiva.
 
  Thanks,
  Malcolm
 
 


 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Jenkins deployment from Archiva

[Olivier Lamy]

Perso I use tomcat so the tomcat-maven-plugin works fine for that purpose.
The other solution is to use the Jenkins plugin to deploy at the end of
your build. This plugin:
https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin



On 23 January 2015 at 12:05, Malcolm G. Davis malc...@nuearth.com wrote:

 Hello Olivier,

 If it is easy, can you have an example?

 Any app server example will do, and I switch out the app server deployment
 plugin you use for my specific situation.

 Thank you,
 Malcolm

 -Original Message-
 From: Olivier Lamy [mailto:ol...@apache.org]
 Sent: Thursday, January 22, 2015 5:58 PM
 To: users@archiva.apache.org
 Subject: Re: Jenkins deployment from Archiva

 depends on your target app server.
 If there is a maven plugin to deploy it that will be easy.


 On 23 January 2015 at 10:24, Malcolm G. Davis malc...@nuearth.com wrote:

  I'm not looking to deploy to Archiva, I have deploying to Archiva
 working.
 
  I want to deploy from Archiva to an application server.
 
  Working: Jenkins - Archiva
 
  Need: Archiva - Jenkins - Application server
 
  Is there a sample Maven pom.xml that will pull from Archiva internal
  (release) and send to an application server?
 
  Thank you,
  Malcolm
 
  btw: The Archiva user name  password can be stored in the Maven super
  pom, avoiding the need to configure Jenkins
 
  -Original Message-
  From: Olivier Lamy [mailto:ol...@apache.org]
  Sent: Thursday, January 22, 2015 5:06 PM
  To: users@archiva.apache.org
  Subject: Re: Jenkins deployment from Archiva
 
  Hi,
  If you use the Maven Job type with Jenkins you can activate the post
  build step to deploy to Archiva (Deploy artifacts to Maven repository).
  Note you will have to store username/password within Jenkins to deploy
  to Archiva.
  I recommend you use the plugin ConfigFileProvider to store and share
  between jobs.
 
 
 
  On 23 January 2015 at 05:33, Malcolm G. Davis malc...@nuearth.com
 wrote:
 
   I would like to create Jenkins job that deploys a war from Archiva.
  
   Is there a specific Jenkins steps or Maven configuration that will
   read a war from Archiva and deploy to an application server?
  
   I know many want to auto-deploy after a successful build, but there
   are internal QA steps that need to be followed, and there is tracking
 and
   sign-off that needs to occur.   The war is required to deploy from
  Archiva.
  
   Thanks,
   Malcolm
  
  
 
 
  --
  Olivier Lamy
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 


 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva 'Find artifact' functionality

[Olivier Lamy]

Hi,

On 30 October 2014 03:39, Isabelle Guimiot isabelle.guim...@gmail.com wrote:
 Hi Olivier,

 Thanks for your answer. In my case, I don't really need this function in
 the GUI. If you could provide a new service in your REST api, searching
 from a checksum code, it would be perfect to me !

Yup not so complicated. Can you create a jira entry for that?


 And while I think of it, do you know approximately when you will release
 2.1.2 ? I know you already fixed and committed some blocker issues, but
 there are still many issues open : do you think you could move some of them
 in 2.1.3, and release a 2.1.2 version by the end of this year, with all the
 jiras that are already closed ?

Sure makes sense.


 Thanks a lot !

 Isabelle


 2014-10-29 11:29 GMT+01:00 Olivier Lamy ol...@apache.org:

 On 29 October 2014 20:35, Isabelle Guimiot isabelle.guim...@gmail.com
 wrote:
  Hello everyone !
 
  I remember there was a nice functionality in archiva 1.3.x, called find
  artifact, which could help us find jars in the whole repo, using a local
  jar file and its checksum files.
 
  Through a google request, I found this existing page in the doc:
  http://archiva.apache.org/docs/2.1.1/userguide/find-artifact.html
 
  ...but it seems to be an old page, referring to archiva 1.3 .

 Yes it is

 
 
  Did you remove this function in archiva 2.x ? If yes, what is the reason
 ?
  Will it be back in the future versions ? Or is there any other way to
  easily get that kind of information ?

 Was done using an applet and didn't have time to migrate this page.
 Currently no other way. If you need that maybe we can add a search
 from checksum values. ( not sure about implementing back this applet)


 
  Thanks for your help !
 
  Isabelle



 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva 'Find artifact' functionality

[Olivier Lamy]

On 29 October 2014 20:35, Isabelle Guimiot isabelle.guim...@gmail.com wrote:
 Hello everyone !

 I remember there was a nice functionality in archiva 1.3.x, called find
 artifact, which could help us find jars in the whole repo, using a local
 jar file and its checksum files.

 Through a google request, I found this existing page in the doc:
 http://archiva.apache.org/docs/2.1.1/userguide/find-artifact.html

 ...but it seems to be an old page, referring to archiva 1.3 .

Yes it is



 Did you remove this function in archiva 2.x ? If yes, what is the reason ?
 Will it be back in the future versions ? Or is there any other way to
 easily get that kind of information ?

Was done using an applet and didn't have time to migrate this page.
Currently no other way. If you need that maybe we can add a search
from checksum values. ( not sure about implementing back this applet)



 Thanks for your help !

 Isabelle



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Premature end of Content-Length delimited message body

[Olivier Lamy]

Weird
Any proxy in the middle?

--
Olivier
On 24 Oct 2014 00:31, Nerderman,Adam nerde...@oclc.org wrote:

 We've been seeing this error periodically when some of our uses that are
 trying to download artifacts far away from where the server is
 geographically since upgrading from Archiva 1.3.5 to 2.1.1.


 Has anyone else seen this error? Is there something with Archiva or a
 configuration that would have changed to start causing this at all? I tried
 looking through the logs, but I don't even see anything that seemingly
 matches up with the times these occur.


 The full message from Maven:


 03:11:09,858 INFO  - [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-dependency-plugin:2.1:copy (default-cli) on
 project maven-artifact-fetch: Unable to resolve artifact. Could not
 transfer artifact groupId:artifactId:tar.gz:1.35.0-20141023.070314-19
 from/to snapshots (http://url/archiva/repository/snapshots): GET request
 of:
 groupId/artifactId/1.35.0-SNAPSHOT/artifactId-1.35.0-20141023.070314-19.tar.gz
 from snapshots failed
 03:11:09,858 INFO  - [ERROR] groupId:artifactId:tar.gz:1.35.0-SNAPSHOT
 03:11:09,858 INFO  - [ERROR]
 03:11:09,858 INFO  - [ERROR] from the specified remote repositories:
 03:11:09,858 INFO  - [ERROR] snapshots (
 http://url/archiva/repository/snapshots, releases=false, snapshots=true),?
 03:11:09,859 INFO  - [ERROR] central (http://repo.maven.apache.org/maven2,
 releases=true, snapshots=false): Premature end of Content-Length delimited
 message body (expected: 41149736; received: 692224

Re: Time to dockerize archiva?

[Olivier Lamy]

done

On 16 October 2014 08:52, jieryn jie...@gmail.com wrote:
 Can you expose the /apache-archiva/conf as a volume so that we can
 persist our configuration.

 Thanks.

 On Fri, Oct 3, 2014 at 12:10 AM, Olivier Lamy ol...@apache.org wrote:
 I pushed everything here: https://registry.hub.docker.com/u/olamy/archiva/

 let me know if you have any other issues.

 Cheers
 Olivier

 On 3 October 2014 12:14, Olivier Lamy ol...@apache.org wrote:
 fixed!


 On 3 October 2014 07:13, Bk Lau bklau2...@gmail.com wrote:
 Olivier:

 I saw a line in the Dockerfile:

 VOLUME [quot;/archiva-dataquot;]

 Is this supposed to be
 VOLUME [/archiva-data]

 ??

 Thanks,

 --bk



 On Thu, Oct 2, 2014 at 8:17 AM, Olivier Lamy ol...@apache.org wrote:

 Hi,
 I finally started that the Dockerfile is here:
 http://svn.apache.org/repos/asf/archiva/docker-file/trunk/ (git repo
 here: https://github.com/olamy/archiva-docker)
 Do not hesitate to contribute if you have any issues with.

 Cheers
 Olivier

 On 12 September 2014 15:58, Olivier Lamy ol...@apache.org wrote:
  Hi,
  Sounds a really good idea!!
  Yup we can track that with a JIRA and we will definitely accept pull
  requests or patch :-)
 
  Cheers
  Olivier
 
  On 12 September 2014 02:06, Jay Vyas jayunit...@gmail.com wrote:
  hi archiva.
 
  I think its finally time to start curating easy to use vagrant/docker
  deployers for archiva.  Should we curate this concept and create a 
  JIRA?
 
  I think it will really enhance the user experience.
 
  With shared folders, we can even allow the core data to be stored on 
  the
  host machine, and have archiva itself the app to be run in a container,
 so
  that the archiva services can go up/down at a whim.
 
 
 
  --
  Jay Vyas
  http://jayunit100.blogspot.com
 
 
 
  --
  Olivier Lamy
  http://twitter.com/olamy | http://linkedin.com/in/olamy



 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy



 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Correct configuration using network proxy

[Olivier Lamy]

Hi,

On 1 October 2014 12:17, Jamie Cavanaugh [DATACOM]
jamie.cavana...@datacom.co.nz wrote:
 Hi,

 We have archiva set up as a mirror for remote repositories, using a network 
 proxy (because we are behind a corporate firewall). This seems to work when 
 building projects and browsing the repositories, but I've noticed that 
 Archiva's UI is really slow.

 For example, when viewing the Repositories page, the 'Remote Check' column 
 sits spinning and in the logs there are several errors:

 2014-10-01 15:12:09,516 [http-8080-1] INFO  
 org.apache.archiva.rest.services.DefaultRemoteRepositoriesService [] - 
 TransferFailedException :Could not read response body.
 2014-10-01 15:12:10,032 [http-8080-3] INFO  
 org.apache.archiva.rest.services.DefaultRemoteRepositoriesService [] - 
 TransferFailedException :Could not read response body.
 2014-10-01 15:12:10,032 [http-8080-2] INFO  
 org.apache.archiva.rest.services.DefaultRemoteRepositoriesService [] - 
 TransferFailedException :Could not read response body.
 2014-10-01 15:12:10,667 [http-8080-5] INFO  
 org.apache.archiva.rest.services.DefaultRemoteRepositoriesService [] - 
 TransferFailedException :Could not read response body.
 2014-10-01 15:14:10,051 [http-8080-4] INFO  
 org.apache.archiva.rest.services.DefaultRemoteRepositoriesService [] - 
 TransferFailedException :Could not read response body.

 It appears that this page doesn't use the proxy configuration from the proxy 
 connector.

 Is there a way to tell Archiva to use the network proxy when checking the 
 status of these repositories?

Maybe with fixing what looks to be a bug :-)
Can you create an issue in Jira? And the best attach a patch or a pull
request? :P



 Thanks,
 Jamie

 Jamie Cavanaugh

 Technical Lead  |  Datacom Systems (Wellington) Ltd  |  68-86 Jervois Quay, 
 Wellington 6011, New Zealand
 jamie.cavana...@datacom.co.nzmailto:jamie.cavana...@datacom.co.nz   |  Ph: 
 +64 4 460 1527  |  Fax: +64 4 460 1511  |  Mob: +64 27 298 5043
 www.datacom.co.nzhttp://www.datacom.co.nz/  |  PO Box 6376, Wellington 6140

 Winner of Hi-Tech New Zealand Company of the Year Award 2010
 Finalist for Hi-Tech New Zealand Company of the Decade Award 2011




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: RepositoryGroup URL is not build using the Application URL

[Olivier Lamy]

Hi,
Sounds like a bug :-)
Mailing list doesn't accept attachment. Maybe you can create a jira
issue with it?
Cheers
Olivier

On 24 September 2014 01:19, Alex Hinrichs brown...@gmx.de wrote:
 Hi,

 I've noticed that the link to a Repository Group shown in the edit dialog is 
 shown correctly but the underlying URL does not use the defined Application 
 URL as prefix but the current URL of the browser.

 The page shown in the attached screenshot was called using a direct URL of 
 http://bgh-build-dev:8081/repo; but the Application URL was defined as 
 https://intranet.mycomp.com/repo; which points to our intranet proxy that is 
 routing the request to the direct URL.

 Alex



-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Re: Deployment of Archiva 2.1.1 on JBoss 7.1.1 / Wildfly 8.1 failed

[Olivier Lamy]

Good catch Jonathan.
I will fix that!!


On 11 September 2014 01:41, Jonathan Sharp forjsh...@gmail.com wrote:
 Hi Olivier  Alex,

 There is still a redback resource file
 (archiva-redback-core/redback-integrations/redback-common-integrations/src/main/resources/META-INF/tld/plexus-security-system.tld)
 in the redback source which contains only references to a bunch of
 nonexistent tag classes.

 -Jon

 On Wed, Sep 10, 2014 at 7:45 AM, brown...@gmx.de wrote:

 Hi,

 I've used a _clean_ installation of JDK and JBoss / Wildfly and deployed
 the WAR downloaded from the Archiva site without any changes. For deploying
 the three JARs separately I took the ones from the extracted standalone
 installation of 2.1.1.

 Sorry for not replying to the answer but my subscription failed and I
 didn't received the mail.

 Thanks,
 Alex

  this one looks weird:  java.lang.ClassNotFoundException:
  org.apache.archiva.redback.integration.taglib.jsp.IfConfiguredTag
 
  We don't use anymore jsp in last version as it's only javascript
 application.
  Is it an update of Archiva? Maybe you should cleanup the previous
 version.




-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

[ANN] Apache Archiva 2.1.1 Released

[Olivier Lamy]

The Apache Archiva team is pleased to announce the release of Archiva
2.1.1. Archiva is available for download from the web site.

Archiva is an application for managing one or more remote
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

Apache Archiva 2.1.1 is a bugs fix release:

NOTE: jdk 1.7 is now prerequisite with Apache Archiva 2.1.1

Compatibility Changes

If upgrading from earlier versions of Archiva, the list of libraries
in wrapper.conf has changed. If you have customized your copy of
wrapper.conf, please update it for compatibility with the version
distributed with the current release.
As the database storage has been removed, you can remove the JNDI
entry for jdbc/archiva. After upgrading from a previous version, you
will have to run a full scan to populate the new JCR Repository. This
will be done on first start of Archiva.

Refer to the Upgrading Archiva guide for more information.

Release Notes

Bug

[MRM-1832] - RepositoryScannerTest#testDefaultRepositoryScanner fails
on Linux with src release zip
[MRM-1853] - On first start up, you get a perpetual loading indicator.
[MRM-1854] - Last modified date is epoch on directory listing for a group
[MRM-1855] - Loading button never disappears when no one is logged
in in some browsers
[MRM-1856] - archiva-cli does not work


Have fun!
-- 
The Apache Archiva Team

Re: Archiva repository replication

[Olivier Lamy]

Hi,
This doesn't exist currently. Not complicated to do but not yet :-(

Cheers
Olivier

On 1 September 2014 19:14, Avner Tamir avner.ta...@borderfree.com wrote:
 Hi,

 We're in the process of evaluating which artifact repository management 
 options.

 One of the important features for us (due to legal  security constrains) is 
 to be able to replicate repositories between different installations of the 
 artifact management tool.
 This can be done in Artifactory (repository replication)  Nexus (smart 
 proxy) in their commercial version.
 Does Archiva has anything similar to it?

 Thanks,
 Avner Tamir


 

 This email and/or any files transmitted with it are intended solely for the 
 use of the individual or entity to whom they are addressed. This email and/or 
 any files transmitted with this email may contain confidential and/or 
 proprietary information. Accordingly, if you are not the intended recipient 
 you are notified that disclosing, copying, distributing or taking any action 
 in reliance on the contents of this information is strictly prohibited. If 
 you have received this email in error, please advise the sender by reply 
 email and delete the message. Please note that any views or opinions 
 presented in this email are solely those of the author and do not necessarily 
 represent those of Borderfree Group companies. Finally, viruses and other 
 harmful code can be transmitted by email. As such, the recipient should check 
 this email and any attachments for the presence of viruses or malware. 
 Borderfree Group companies disclaims any and all liability for any damage 
 caused by any virus or malware transmitted by this email and/or any files 
 transmitted with this email.

 



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Log in option is not available.

[Olivier Lamy]

Yup thanks for report.
This has been already fixed in source code and we need a bit of time to
release a new version

--
Olivier
On Aug 23, 2014 10:29 PM, murali chevuri murali_chev...@yahoo.com.invalid
wrote:

 Hi,

 Currently I am using apache archiva 2.1.0 version. I am facing below issue
 and included solution also. I checked this issue both in Chrome and IE
 result is same.

 Problem: Except for admin (Who configured the admin user) and for all
 others log in option is not coming.

 Result: User is only seeing the Loading page. Please check the attached
 screenshot.

 My Solution:

 In js/archiva/main.js in 'getUserFromLoginCookie' (line number 1003)
 function without validating the 'cookieContent' variable api is trying to
 do the parsing using 'parseJSON' method. Because of this browser is
 giving java script error 'Unexpected token u JSON' error.

 I added the check condition before parsing, issue was solved. Below is the
 code snippet.

 if (cookieContent === undefined) {
  return null;
 }



 Regards,
 Murali Krishna Chevuri.

Re: Archiva 2.1.0 standalone only works on 127.0.0.1

[Olivier Lamy]

Hi
Open the file conf/jetty.xml

Then find
Call name=addConnector
  Arg
  New class=org.eclipse.jetty.server.nio.SelectChannelConnector
Set name=hostSystemProperty name=jetty.host//Set
Set name=portSystemProperty name=jetty.port
default=8080//Set
Set name=maxIdleTime3/Set
Set name=Acceptors2/Set
Set name=statsOnfalse/Set
Set name=confidentialPort8443/Set
Set name=lowResourcesConnections5000/Set
Set name=lowResourcesMaxIdleTime5000/Set
  /New
  /Arg
/Call


And replace with Set name=host192.168.1.10/Set

HTH
Olivier

On 25 August 2014 06:46, Kenneth Øst kenneth.o...@gmail.com wrote:
 Hi users of Archiva
 I can only get to Archiva from 127.0.0.1. The server has two NIC's and I
 only want to have it started on eg. 192.168.1.10
 What should I do to make it run on that IP instead of only localhost?

 Best regards
 Kenneth



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Issues Viewing Archiva Logs 2.1.0

[Olivier Lamy]

You can change immediateFlush=false to immediateFlush=true in
log4j2.xml (in WEB-INF/classes) must fix that.

Let us know.

Olivier



On 30 July 2014 05:04, Jonathan Sharp forjsh...@gmail.com wrote:
 Hi Bill,

 I also see this behavior with 2.1.0.

 archiva.log is continuously written when testing with 2.0.1.

 -Jon


 On Tue, Jul 29, 2014 at 6:13 AM, Graham,Bill grah...@oclc.org wrote:

 All,

 I am running into an issues viewing the archiva.log file for Archiva
 2.1.0.  I can start up the archiva server without issue, the site is
 accessible and I get a wrapper*.log generated, but the archiva.log file
 does not get populated with information.  I did notice that when I shut the
 server down, the archiva.log file gets all the information written to it
 from when the server started up, to when the server shutdown.

 Has anyone seen this behavior before?  Am I missing a setting somewhere?
  My JVM is listed below.

 Thanks,

 Bill


 /usr/java/jdk1.7/bin/java -version

 java version 1.7.0_11

 Java(TM) SE Runtime Environment (build 1.7.0_11-b21)

 Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)





-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: No sign in possible due to cookie problem [2.1.0 / workaround]

[Olivier Lamy]

On 29 July 2014 00:46, fa-1281595974-...@isys-software.de
fa-1281595974-...@isys-software.de wrote:
 |Hello, i got the problem that the webinterface is not being completely
 loaded.
 The following JavaScript-Error is being thrown and not catched:

 SyntaxError: Unexpected token u
 at Object.parse (native)
 at Function.m.parseJSON
 (http://maven/archiva/js/jquery-1.11.1.min.js?_archivaVersion=2.1.0:4:15739)
 at getUserFromLoginCookie
 (http://maven/archiva/js/archiva/main.js?_archivaVersion=2.1.0:69:18)
 at startArchivaApplication
 (http://maven/archiva/js/archiva/main.js?_archivaVersion=2.1.0:888:16)
 athttp://maven/archiva/js/archiva/archiva.js:119:19
 at Object.i.execCb
 (http://maven/archiva/js/require.min.2.1.11.js:29:311)
 at Object.$.check (http://maven/archiva/js/require.min.2.1.11.js:18:423)
 at Object.$.enable
 (http://maven/archiva/js/require.min.2.1.11.js:23:238)
 at Object.$.init (http://maven/archiva/js/require.min.2.1.11.js:17:68)
 athttp://maven/archiva/js/require.min.2.1.11.js:26:369;

 Lines in main.js relevant to the stacktrace:

 ||   getUserFromLoginCookie=function(){
 || var cookieContent=$.cookie('archiva_login');
 || $.log(archiva_getUserFromLoginCookie cookie
 content:+cookieContent);
 || var user = $.parseJSON(cookieContent); // -- throws the error
 || if(!user){
 ||   return null;
 || }||

 |cookieContent is undefined. It should not be undefined.
 I did the following hack to get the webinterface of archiva useable again:

 |   getUserFromLoginCookie=function(){
 || var cookieContent=$.cookie('archiva_login');
 || $.log(archiva_getUserFromLoginCookie cookie
 content:+cookieContent);
 || if(typeof cookieContent === undefined) { // hack begin
 ||   return null;
 || } // hack end
 || var user = $.parseJSON(cookieContent);
 || if(!user){
 ||   return null;
 || }|

 Does someone has an idea why this is happening?

Yup that's a bug :-)
It's fixed but need a new release.


 I updated recently from archiva 2.0.1 to 2.1.0.

 Thanks,
 Fabian

 --
 iSYS Software GmbH

 Fabian Trampusch
 Abteilung Hama-Webstage

 Tel: +49 (0) 89 46 23 28-0 | Fax  (0) 89 46 23 28-14
 email: f.trampu...@isys-software.de
 Grillparzerstr. 10 | D-81675 Muenchen
 www.isys-software.de

 Sitz der Gesellschaft: München | HRB 111760
 Geschaeftsfuehrer: Prof. Dr. Peter Mandl und Michael Sailer




-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva 2.0.1 - disabling proxies?

[Olivier Lamy]

Hi,
I reckon this is missing in the new ui. :-(
Can you please create a Jira for that. And I will have a look soon.

Cheers
Olivier

On 25 July 2014 01:51, Stallard,David stall...@oclc.org wrote:
 We periodically find that one of our proxy repositories starts to give 
 timeouts on all artifact requests, and this bogs down Archiva as a whole.  In 
 1.3.5 we could just disable a proxy until some later date, but I can't find 
 an equivalent function in the 2.0.1 interface.  Is there a way to disable a 
 proxy without actually deleting it from the list?

 Thanks,
 David




-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva 2.0.1: Unwanted scans running

[Olivier Lamy]

On 23 July 2014 23:28, Stallard,David stall...@oclc.org wrote:
 Brett, we did do some tweaking to the cron schedules for both snapshots
 and internal yesterday, that¹s probably what initiated the scan.  And I¹m
 guessing a directory scan of snapshots is sitting in the queue waiting for
 the internal scan to finish.  We will probably bounce Archiva to stop
 these scans and clear the queues.  Is there any harmful side effect to
 bouncing during a scan?  I think we¹ve done it before without impact.  As
 an enhancement, an admin button to abort an in-progress scan would be
 useful.


I don't see any weird side effect.
Good idea regarding the button to abort. Can you create a jira issue for that?

Thanks
Olivier

 Thanks,
 David


 On 7/23/14, 12:59 AM, Brett Porter br...@apache.org wrote:

 From a quick look at the code, it looks like that scan will happen
whenever the configuration for the repository is changed. Is that what
happened for you?

Not sure if that was intentional or not.

- Brett

On 23 Jul 2014, at 7:13 am, Stallard,David stall...@oclc.org wrote:

 We have roughly 1.6 terabytes of data in our largest Archiva instance
it it grows rapidly.  Because of this amount of data, and/or perhaps
because of limitations of our current hardware (which we are working to
improve), doing a full directory scan degrades performance of Archiva as
a whole and it can take quite a long time to complete...48 hours or more.

 Because of that, we don't do directory scans unless we feel it's
necessary to fix some unusual situation.  The index scans are usually
sufficient.

 Today, a directory scan of the internal repository mysteriously started
up.  Although the System Status page doesn't say what type of scan is
running, I believe it's a directory scan because the Files Processed
number is equal to the New Files number.  This has bogged down the
system as expected and we're getting complaints from users about uploads
and downloads taking a long time.

 Looking in the log to try and find how this scan was started, I found
the following line:

 2014-07-22 11:09:26,770 [pool-5-thread-1] INFO
org.apache.archiva.scheduler.repository.ArchivaRepositoryScanningTaskExec
utor [] - Executing task from queue with job name: RepositoryTask
[repositoryId=internal, resourceFile=null, scanAll=true,
updateRelatedArtifacts=false]

 This seems to indicate that either the scheduler kicked it off, or at
some point in the past a directory scan was added to the queue and it is
just now being processed.  I don't know if the latter is even possible
or not...I thought that the stuff in the queue was individual artifacts
that had been marked by scans for later processing.

 Our Cron Expression for the internal repository is the following, which
should not have kicked off a scan at the time shown above.  However,
even if it did, I believe that the Cron Expression usually kicks off
index scans rather than directory scans?

 0 0 19 * * ?

 So, two questions:


  1.  Any idea why this directory scan might have been started?
  2.  Is there any way to stop a scan after it has started?  I'm
assuming a bounce of Archiva would stop it, but an option that didn't
incur downtime would be preferable.

 Thanks,
 David






-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

[ANN] Apache Archiva 2.1.0

[Olivier Lamy]

Hi,

The Apache Archiva team would like to announce the release of Archiva
2.1.0. Archiva is available for download from the web site (
http://archiva.apache.org )

Archiva is an application for managing one or more remote
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

New in Archiva 2.1.0

Apache Archiva 2.1.0 is a bugs fix release:

NOTE: jdk 1.7 is now prerequisite with Apache Archiva 1.7

Compatibility Changes

If upgrading from earlier versions of Archiva, the list of libraries
in wrapper.conf has changed. If you have customized your copy of
wrapper.conf, please update it for compatibility with the version
distributed with the current release.
As the database storage has been removed, you can remove the JNDI
entry for jdbc/archiva. After upgrading from a previous version, you
will have to run a full scan to populate the new JCR Repository. This
will be done on first start of Archiva.

Refer to the Upgrading Archiva guide for more information.

Release Notes

The Archiva 2.1.0 features set can be seen in the feature tour.

Changes in Archiva 2.1.0

Released: 20th July 2014

Improvement

[MRM-1210] - Dependency tree should include the artifact type
[MRM-1558] - Please provide some UI element which shows degraded
and/or badly connected remote repository
[MRM-1802] - Find a cache solution for browsing part (especially root browsing)
[MRM-1829] - Change default value of of AysncLogger strategy for log4j async
[MRM-1834] - Add limit to index search query to prevent unnecessary calculations
[MRM-1836] - Make search limit (maxCount) configurable via UI
[MRM-1843] - provide mechanism to obtain the latest version of an artifact

Bug

[MRM-887] - Start script has no valid uname option
[MRM-1809] - Users - Manage section sort by name doesn't work as expected
[MRM-1812] - Users - Manage section needs Sort by User Name, Sort by
Full Name, and Sort by Email buttons
[MRM-1813] - Users - Manage section filters don't seem to work
[MRM-1823] - java 1.7 as prerequisite
[MRM-1824] - metadata storage using Cassandra
[MRM-1825] - MD5 hashes are for wrong file name
[MRM-1826] - Force Internet Explorer into Standards Mode
[MRM-1830] - Charset applied to binary repository HTTP responses
[MRM-1833] - Nullpointer when browsing artifacts which have
dependencies with scope import
[MRM-1837] - DefaultArchivaConfiguration holds references to classes
[MRM-1841] - Remember me not working
[MRM-1842] - Remove per default log4j2 Async Logging
[MRM-1846] - Regression in 2.0.1 : uniqueVersion false not supported
[MRM-1849] - Unable to download -SNAPSHOT jars after 2.0.1 Upgrade



Have fun!
-- 
The Apache Archiva Team

Re: Archiva 2.0.1 : regression with maven 2 and uniqueVersion false

[Olivier Lamy]

On 3 July 2014 11:39, Brett Porter br...@apache.org wrote:
 I think this was already fixed in MRM-1846 - Olivier will probably look at a 
 release after he gets back from his holidays.

Sad but I'm now back from holidays :-)

So I will try to release next week.



 On 3 Jul 2014, at 5:14 am, Jeffrey N Hagelberg jnhagelb...@us.ibm.com wrote:



 We're seeing this too.  I've created
 http://jira.codehaus.org/browse/MRM-1849 for it.

 -Jeff Hagelberg




-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: 405 error when uploading to Archiva 2.0.1

[Olivier Lamy]

On 4 June 2014 03:31, Stallard,David stall...@oclc.org wrote:
 If I change the context to “/archiva” and then restart Archiva, when I try to 
 go to th web interface I get this:

 Error 404 - Not Found.
 No context on this server matched or handled this request.
 Contexts known to this server are:

   *   /archiva --- 
 o.e.j.w.WebAppContext{/archiva,file:/svn/maven/apache-archiva-2.0.1/apps/archiva/},/svn/maven/apache-archiva-2.0.1/apps/archivahttp://svnap01qxdu.dev.oclc.org:1/archiva

 There is nothing in archiva.log, but there are messages like this in the 
 request log:


 [ip address] -  -  [03/Jun/2014:14:52:12 +] GET 
 /restServices/archivaUiServices/runtimeInfoService/archivaRuntimeInfo/en?_=1401807132949
  HTTP/1.1 404 1338 http://host:port/; Mozilla/5.0 (Macintosh; Intel Mac OS 
 X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0


The GET request says you are accessing the ui using / the /archiva is missing.
Did you try force refreshing the home page.


 [ip address] -  -  [03/Jun/2014:15:32:53 +] GET / HTTP/1.1 404 802 - 
 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 
 Firefox/29.0



 On 6/3/14, 8:05 AM, Olivier Lamy 
 ol...@apache.orgmailto:ol...@apache.org wrote:

 With changing  to Set name=contextPath/archiva/Set ?
 Sounds weird (I just tested with 2.0.1 and got it working)
 Do you have any errors in log?

 On 3 June 2014 00:15, Stallard,David 
 stall...@oclc.orgmailto:stall...@oclc.org wrote:
 If I want to change the context back to what it was previously so that our
 URLs don’t change, is there something else I need to do besides modify
 contexts/archiva.xml?  I changed the contextPath from “/“ to “/archiva”
 but that gives me a 404 that there is no known context.


 On 5/30/14, 1:27 AM, Olivier Lamy 
 ol...@apache.orgmailto:ol...@apache.org wrote:

 Note: per default archiva is now on root context.
 See http://archiva.apache.org/docs/2.0.1/adminguide/upgrade.html
 section Updated Jetty configuration

 HTH
 Olivier

 On 30 May 2014 07:28, Stallard,David 
 stall...@oclc.orgmailto:stall...@oclc.org wrote:
 It turns out that the URLs are slightly different.  In our 1.3.5
 instance
 with tomcat the URLs look like this:

 http://server:port/archiva/repository/internal/...

 But in the 2.0.1 instance with jetty it looks like this (no ³archiva²
 string):

 http://server:port/repository/internal/Š

 I don¹t know if the string ³archiva² is an inherent difference between
 1.3.5 and 2.0.1, or if it¹s a difference between our tomcat setup and
 our
 jetty setup.  I browsed the 2.0.1 config files a bit but didn¹t see
 where
 this might be defined.

 Once we changed our maven settings.xml to remove ³archiva² from the URL,
 the 405 error went away.  It was replaced with a 401, but hopefully now
 that is something we can work through.



 On 5/29/14, 11:34 AM, Pimentel, Robert 
 robert.pimen...@tgslc.orgmailto:robert.pimen...@tgslc.org
 wrote:

 Is it using the appropriate URL value? Can you provide the error stack
 from maven (mvn -e)? Can you provide a snippet from the Archiva log(s)?

 Thanks,
 Rob

 -Original Message-
 From: Stallard,David [mailto:stall...@oclc.org]
 Sent: Thursday, May 29, 2014 10:24 AM
 To: users@archiva.apache.orgmailto:users@archiva.apache.org
 Subject: Re: 405 error when uploading to Archiva 2.0.1

 Just to add to the below, uploads are working fine through the web
 interface but we get the http 405 error when a maven build tries to
 upload.  Downloads are working fine as well.

 Thanks,
 David

 From: Stallard, Stallard,David
 stall...@oclc.orgmailto:stall...@oclc.orgmailto:stall...@oclc.org
 Date: Tuesday, May 27, 2014 at 2:03 PM
 To: 
 users@archiva.apache.orgmailto:users@archiva.apache.orgmailto:users@archiva.apache.org
 users@archiva.apache.orgmailto:users@archiva.apache.orgmailto:users@archiva.apache.org
 Subject: 405 error when uploading to Archiva 2.0.1

 We are trying to test a maven deploy against our test instance of
 Archiva
 2.0.1, but we are getting http 405 when the build attempts to upload an
 artifact.  It looks like 405 means that the upload method was not
 allowed.

 The new instance is running on the same port as our live instance of
 Archiva 1.3.5 (different host though), so I don't think the application
 being built has a port number that needs to be changed.  The main
 difference is that 1.3.5 is running with tomcat and 2.0.1 is using the
 included jetty.  Could we be missing some setting in jetty.xml which is
 set correctly in our 1.3.5 instance?  Any other ideas?

 Thanks,
 David






 --
 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




-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: 405 error when uploading to Archiva 2.0.1

[Olivier Lamy]

With changing  to Set name=contextPath/archiva/Set ?
Sounds weird (I just tested with 2.0.1 and got it working)
Do you have any errors in log?

On 3 June 2014 00:15, Stallard,David stall...@oclc.org wrote:
 If I want to change the context back to what it was previously so that our
 URLs don’t change, is there something else I need to do besides modify
 contexts/archiva.xml?  I changed the contextPath from “/“ to “/archiva”
 but that gives me a 404 that there is no known context.


 On 5/30/14, 1:27 AM, Olivier Lamy ol...@apache.org wrote:

Note: per default archiva is now on root context.
See http://archiva.apache.org/docs/2.0.1/adminguide/upgrade.html
section Updated Jetty configuration

HTH
Olivier

On 30 May 2014 07:28, Stallard,David stall...@oclc.org wrote:
 It turns out that the URLs are slightly different.  In our 1.3.5
instance
 with tomcat the URLs look like this:

 http://server:port/archiva/repository/internal/...

 But in the 2.0.1 instance with jetty it looks like this (no ³archiva²
 string):

 http://server:port/repository/internal/Š

 I don¹t know if the string ³archiva² is an inherent difference between
 1.3.5 and 2.0.1, or if it¹s a difference between our tomcat setup and
our
 jetty setup.  I browsed the 2.0.1 config files a bit but didn¹t see
where
 this might be defined.

 Once we changed our maven settings.xml to remove ³archiva² from the URL,
 the 405 error went away.  It was replaced with a 401, but hopefully now
 that is something we can work through.



 On 5/29/14, 11:34 AM, Pimentel, Robert robert.pimen...@tgslc.org
wrote:

Is it using the appropriate URL value? Can you provide the error stack
from maven (mvn -e)? Can you provide a snippet from the Archiva log(s)?

Thanks,
Rob

-Original Message-
From: Stallard,David [mailto:stall...@oclc.org]
Sent: Thursday, May 29, 2014 10:24 AM
To: users@archiva.apache.org
Subject: Re: 405 error when uploading to Archiva 2.0.1

Just to add to the below, uploads are working fine through the web
interface but we get the http 405 error when a maven build tries to
upload.  Downloads are working fine as well.

Thanks,
David

From: Stallard, Stallard,David
stall...@oclc.orgmailto:stall...@oclc.org
Date: Tuesday, May 27, 2014 at 2:03 PM
To: users@archiva.apache.orgmailto:users@archiva.apache.org
users@archiva.apache.orgmailto:users@archiva.apache.org
Subject: 405 error when uploading to Archiva 2.0.1

We are trying to test a maven deploy against our test instance of
Archiva
2.0.1, but we are getting http 405 when the build attempts to upload an
artifact.  It looks like 405 means that the upload method was not
allowed.

The new instance is running on the same port as our live instance of
Archiva 1.3.5 (different host though), so I don't think the application
being built has a port number that needs to be changed.  The main
difference is that 1.3.5 is running with tomcat and 2.0.1 is using the
included jetty.  Could we be missing some setting in jetty.xml which is
set correctly in our 1.3.5 instance?  Any other ideas?

Thanks,
David






--
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

Re: Archiva 2.0.1 : regression with maven 2 and uniqueVersion false

[Olivier Lamy]

On 3 June 2014 22:38, Isabelle Guimiot isabelle.guim...@gmail.com wrote:
 We are using Archiva 1.4-M4 and we want to move to Archiva 2.0.1.

 But in 2.0.1, we encounter a blocker issue with maven 2 and tag
 uniqueVersion=false in the snapshots repository.

 It used to work fine with Archiva 1.4-M4, each build was publishing only
 one snapshot called artifact-x.y.z-SNAPSHOT.jar .

 Now in 2.0.1, with the tag uniqueVersion=false, each build publishes a new
 unique snapshot called artifact-x.y.z-null-[buildNumber].jar , which makes
 other builds fail when they have this artifact as a dependency...

 Did I miss anything in Archiva's configuration ? Or do I have to open a
 jira issue to have this bug fixed in the next version ?

yup sounds like a bug. So yes please create an issue in Jira.
Which Maven version are you using?



 Thanks,

 Isabelle



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: LDAP groupOfNames vs groupOfUniqueNames

[Olivier Lamy]

Currently not.
That's not something too complicated to implement.
Can you please create a JIra issue for that?

Olivier

On 22 May 2014 19:06, fa-1281595974-...@isys-software.de
fa-1281595974-...@isys-software.de wrote:
 Hello,

 i would like to ask if redback can be configured in such a way, that it uses
 groupOfNames instead of grupOfUniqueNames.

 Thanks in advance for any responses
 Fabian

 --
 iSYS Software GmbH

 Fabian Trampusch
 Abteilung Hama-Webstage

 Tel: +49 (0) 89 46 23 28-0 | Fax  (0) 89 46 23 28-14
 email: f.trampu...@isys-software.de
 Grillparzerstr. 10 | D-81675 Muenchen
 www.isys-software.de

 Sitz der Gesellschaft: München | HRB 111760
 Geschaeftsfuehrer: Prof. Dr. Peter Mandl und Michael Sailer




-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: networkProxy not working?

[Olivier Lamy]

Sounds an issue (at least in the ui level to display settings in the
table list but should work when editing the proxy connector )
Can you create a jira with some screenshots?
Anyway you can still check the configuration in the archiva.xml file.


Thanks
Olivier

On 20 May 2014 08:40, Rick Richardson rick.richard...@gmail.com wrote:
 First, thank you for making such a great product. It is very
 straightforward and easy to use.  I am sure that my network proxy setting
 issues are temporary and quite possibly related to something I've screwed
 up.

 I am running 2.0.1

 I have a pretty stock standalone deployment. I am trying to use the
 internal/central repo, + I have created a new repo for clojars.

 I have created a new Network Proxy called corpproxy.

 I have set corpproxy to be the network proxy for both the Remote
 Repositories as well as in the Proxy Connectors.  So that when you edit the
 settings, corpproxy shows up selected in the dropdown.

 However.. when you click on the question-mark button under the Proxy
 Connector Settings button, the Network Proxy shows up as none

 When I try to fetch an index or just try to use the repo via maven, it
 fails and I get either a No Route To Host (expected, because our internal
 DNS returns a bogus address for everything external)  or I get a connection
 timed out trying to reach repo.maven.org.  So it is definitely not trying
 to go through the proxy in either case.

 Thoughts?



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Question about users when upgrading from 1.3.5 to 2.0.1

[Olivier Lamy]

On 21 May 2014 00:10, Stallard,David stall...@oclc.org wrote:
 I'm currently upgrading a test instance from 1.3.5 to 2.0.1 in order to iron 
 out the process.  I'm using the standalone install instructions, rather than 
 the upgrade instructions, because I want to switch to the included jetty 
 rather than our old, messy method of moving Archiva war files and whatnot 
 into an existing tomcat structure.

 We already had the data separated from the application, so I've defined 
 ARCHIVA_BASE to point to our existing data area.  This seems to be working, 
 as I can browse the existing artifacts just fine.  However, the users are not 
 showing up in 2.0.1.  I get the Create Admin red button when I first start 
 it up.

 Should it have found my existing admin account and not prompted me to create 
 one?  If so, any idea why it doesn't seem to be using the data/users 
 directory under our existing ARCHIVA_BASE directory?

data/databases/users

or change the path in jetty.xml file.





 Thanks,
 David



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Corrupt index on upgrade?

[Olivier Lamy]

]
 at 
 org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:733)
  ~[spring-beans-4.0.2.RELEASE.jar:4.0.2.RELEASE]
 ... 43 more



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: 2.0.1 with high cpu usage while idle

[Olivier Lamy]

I will remove the per default Async logging in 2.1.0
See http://jira.codehaus.org/browse/MRM-1842



On 3 May 2014 03:36, Miguel Almeida migueldealme...@gmail.com wrote:
 I wanted to clarify my last email -
 http://logging.apache.org/log4j/2.x/manual/async.html explains the
 advantages of async loggers. But it seems to me that there's a huge CPU
 load associated with it (which is not documented there).
 I haven't used log4j's async logging before - is there some optimisation
 missing in archiva, or is such a high load really expected?

 Miguel


 On Fri, May 2, 2014 at 6:21 PM, Miguel Almeida 
 migueldealme...@gmail.comwrote:

 The provided link doesn't offer much information on the difference between
 the different AsyncLogger.WaitStrategy strategies.
 What are the pros and cons of the different options?

 I was already using 1.4-M4 and noticing constant high cpu loads (15% CPU
 usage even on idle periods).

 Cheers,

 Miguel


 On Fri, May 2, 2014 at 12:06 PM, Miguel Almeida migueldealme...@gmail.com
  wrote:

 Original URL provided by Oliver is broken. Link should point to
 http://archiva.apache.org/docs/2.0.1/adminguide/logging.html


 On Thu, Apr 10, 2014 at 7:11 PM, Allen Lee allen@asu.edu wrote:

 Changing the wait strategy to Block in wrapper.conf fixed it for me.
 Thanks Olivier!

 On Wed, Apr 9, 2014 at 5:31 PM, Olivier Lamy ol...@apache.org wrote:
  Maybe because of the async logging from log4j2 (using disruptor).
  Have a look here:
  http://archiva.apache.org/docs/2.0.2-SNAPSHOT/adminguide/logging.html
 
  HTH
  --
  Olivier
 
  On 10 April 2014 05:07, Allen Lee allen@asu.edu wrote:
  I upgraded from Archiva 1.3 to Archiva 2.0.1 recently and noticed that
  archiva's CPU usage is consistently high, around 80-85%. I reniced the
  process and now it's ranging from 15-85% of CPU, on average around
  40-50%. At first I thought it might have been the initial startup
  costs of rescanning repositories but it has remained this way after
  several days now.
 
  The admin system status page doesn't report anything untoward (no
  repository scans happening, etc.). Any suggestions on how to fix this,
  and is this something others have noticed as well?
 
  Thanks in advance!
 
  --
  Allen Lee
  Center for the Study of Institutional Diversity [http://csid.asu.edu]
  School of Human Evolution and Social Change [http://shesc.asu.edu]
  College of Liberal Arts and Sciences
  Arizona State University | P.O. Box 872402 | Tempe, Arizona 85287-2402
  480.727.0401 | Fax: 480.965.7671 | e-mail: allen@asu.edu
 
 
 
  --
  Olivier Lamy
  Ecetera: http://ecetera.com.au
  http://twitter.com/olamy | http://linkedin.com/in/olamy



 --
 Allen Lee
 Center for the Study of Institutional Diversity [http://csid.asu.edu]
 School of Human Evolution and Social Change [http://shesc.asu.edu]
 College of Liberal Arts and Sciences
 Arizona State University | P.O. Box 872402 | Tempe, Arizona 85287-2402
 480.727.0401 | Fax: 480.965.7671 | e-mail: allen@asu.edu







-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Password configuration in security.properties doesn't work

[Olivier Lamy]

Looks to be an issue.
Can you create a jira entry for that?

--
Olivier
On Apr 28, 2014 12:52 PM, 陈飞 diracn...@gmail.com wrote:

 I'm just a newbie to this and try to learn how to use archiva. When trying
 to create the admin's password, archiva doesn't allow setting something
 like '11'. So I try to configure the password police in the
 security.properties, but it doesn't work.

 Here's the security.properties:

 security.policy.password.rule.musthave.enabled=false
 security.policy.password.rule.alphanumeric.enabled=false

 Tried to set the file in  (webapp and standalone both)
  ~/.m2
 and
  {jetty_home}/conf/
 and
  change the file redback-security.properties in the WEB-INF.

 Anyone and any idea why?

Re: Upgrading from 1.3.6 to 2.0.1 with MySQL DB

[Olivier Lamy]

Have a look at the jetty.xml format here
https://git-wip-us.apache.org/repos/asf?p=archiva.git;a=blob;f=archiva-jetty/src/main/conf/jetty.xml;h=2881f23f8d9ea01db7e54f02247489e1a3a20739;hb=master

especially username not user :-)



On 18 April 2014 09:30, Jared Griffith jgriff...@picsauditing.com wrote:
 So should I be pointing the users db to the redback db?

 If so, that's what I have done, and it's giving me errors and never really
 starting up.

 Errors from wrapper.log: http://pastebin.com/uhgUSf1L

 Relevant part from the jetty.xml http://pastebin.com/01v6f1VW


 On Thu, Apr 17, 2014 at 3:19 PM, Olivier Lamy ol...@apache.org wrote:

 With 2.x there is only the users db the Archiva one is not used anymore.

 --
 Olivier
 On Apr 18, 2014 1:57 AM, Jared Griffith jgriff...@picsauditing.com
 wrote:

  I am trying to upgrade my Archiva installation from 1.3.6 to 2.0.1.
  My current installation is using MySQL for both the archiva and user
  (redback) dbs.  I noticed in the documentation that there is only mention
  of the users db for the jetty.xml.  Is everything now just in the archiva
  database, or is there a separate context like there is in 1.3.x ?
 
  --
 
  Jared Griffith
  Linux Administrator, PICS Auditing, LLC
  P: (949) 936-4574
  C: (909) 653-7814
 
  http://www.picsauditing.com
 
  17701 Cowan #140 | Irvine, CA | 92614
 
  Join PICS on LinkedIn and Twitter!
 
  https://twitter.com/PICSAuditingLLC
 




 --

 Jared Griffith
 Linux Administrator, PICS Auditing, LLC
 P: (949) 936-4574
 C: (909) 653-7814

 http://www.picsauditing.com

 17701 Cowan #140 | Irvine, CA | 92614

 Join PICS on LinkedIn and Twitter!

 https://twitter.com/PICSAuditingLLC



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Does running on freebsd require compiling the entire archiva package from source?

[Olivier Lamy]

On 17 April 2014 19:55,  org.apache.arch...@io7m.com wrote:
 On Thu, 17 Apr 2014 09:27:36 +1000
 Olivier Lamy ol...@apache.org wrote:

 Hi,
 This is the java wrapper you can use it as a quick start.
 If your env is not in the packages, you can deploy archiva war in a
 servlet container.
 See http://archiva.apache.org/docs/2.0.2-SNAPSHOT/adminguide/webapp.html

 'Lo.

 Is there another option? What is it that this wrapper actually does?

The wrapper start a servlet container :-)


 I'd rather avoid running a servlet container if at all possible.
Uhm it's a webapp so you will have to start one (embeded or not)

 M



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Performance issues after upgrading to 2.0.1

[Olivier Lamy]

On 17 April 2014 19:14, Sascha Vogt sascha.v...@gmail.com wrote:
 Hi Olivier,

 Am 17.04.2014 01:24, schrieb Olivier Lamy:
 DefaultISMLocking is a jackrabbit class

 Maybe try change the log4j2 async configuration?
 See http://archiva.apache.org/docs/2.0.2-SNAPSHOT/adminguide/logging.html
 Due to various issues reported here, I will change the default.

 We've already changed that, didn't change anything (we have no CPU issue
 here). Also in the meantime I added 4 more cores (so currently 8) -
 average load is at 2, so plenty of free CPU cycles for Archiva.

 Do you have any idea about the other things? Or a starting point where
 we should debug / profile?
Complicated

DefaultISMLocking.acquireReadLock()/aquireReadWriteLock is part of
Jackrabbit framework.
Do you see this usage in more than one thread? Because it's only the
indexing thread using that. Except if you have a lot users using the
ui.
Weird as this should be faster than 1.3.x using a database.
Do  you have any other threads blocking?

-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Upgrading from 1.3.6 to 2.0.1 with MySQL DB

[Olivier Lamy]

With 2.x there is only the users db the Archiva one is not used anymore.

--
Olivier
On Apr 18, 2014 1:57 AM, Jared Griffith jgriff...@picsauditing.com
wrote:

 I am trying to upgrade my Archiva installation from 1.3.6 to 2.0.1.
 My current installation is using MySQL for both the archiva and user
 (redback) dbs.  I noticed in the documentation that there is only mention
 of the users db for the jetty.xml.  Is everything now just in the archiva
 database, or is there a separate context like there is in 1.3.x ?

 --

 Jared Griffith
 Linux Administrator, PICS Auditing, LLC
 P: (949) 936-4574
 C: (909) 653-7814

 http://www.picsauditing.com

 17701 Cowan #140 | Irvine, CA | 92614

 Join PICS on LinkedIn and Twitter!

 https://twitter.com/PICSAuditingLLC

Re: Performance issues after upgrading to 2.0.1

[Olivier Lamy]

On 17 April 2014 02:06, Sascha Vogt sascha.v...@gmail.com wrote:
 Hi,

 Am 16.04.2014 13:51, schrieb Sascha Vogt:
 I also tried playing with the Lock Timeout / Skip Locking setting in the
 Runtime Configuration, imho that didn't change the situation much.

 I had a look into this flag trying to figure out what it is doing, and
 found the following in DefaultArchivaRuntimeConfigurationService:

 FileLockConfiguration fileLockConfiguration = 
 archivaRuntimeConfiguration.getFileLockConfiguration();
 if ( fileLockConfiguration != null )
 {
 fileLockManager.setTimeout( fileLockConfiguration.getLockingTimeout() );
 fileLockConfiguration.setSkipLocking( 
 fileLockConfiguration.isSkipLocking() );
 }

 The line fileLockConfiguration.setSkipLocking(
 fileLockConfiguration.isSkipLocking() ); looks suspicious. Shouldn't
 that be fileLockManager.setSkipLocking...?


Correct I just fixed. This means you cannot activate the experimental
file locking :-) so performance issue on that :-)

DefaultISMLocking is a jackrabbit class

Maybe try change the log4j2 async configuration?
See http://archiva.apache.org/docs/2.0.2-SNAPSHOT/adminguide/logging.html
Due to various issues reported here, I will change the default.






 Greetings
 -Sascha-



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Does running on freebsd require compiling the entire archiva package from source?

[Olivier Lamy]

Hi,
This is the java wrapper you can use it as a quick start.
If your env is not in the packages, you can deploy archiva war in a
servlet container.
See http://archiva.apache.org/docs/2.0.2-SNAPSHOT/adminguide/webapp.html

On 17 April 2014 02:16,  org.apache.arch...@io7m.com wrote:
 'Lo.

 I'd like to install Archiva on a FreeBSD server here. Having downloaded
 the 2.0.1 package, I was surprised to find that it won't run on FreeBSD:

 $ /archiva/apache-archiva-2.0.1/bin/archiva
 Unable to locate any of the following operational binaries:
   /archiva/apache-archiva-2.0.1/bin/./wrapper-freebsd-x86-64
   /archiva/apache-archiva-2.0.1/bin/./wrapper-freebsd-x86-32
   /archiva/apache-archiva-2.0.1/bin/./wrapper

 I have to admit I'm surprised that a package written in Java to support
 Java development apparently depends on native code...

 Do I have to build the whole thing from source in order to run it?

 M



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva 2.0.1 Deployment on glassfish 4 : CDI Deployment Failure

[Olivier Lamy]

On 15 April 2014 06:34, Florent THOMAS mailingl...@mind-and-go.com wrote:
 Hy folks,

 I'm trying to deploy archiva on GF4. I followed this
 https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+on+GlassFish+with+mySQL

 I have this issue :

 /Exception while loading the app : CDI deployment failure:Exception List
 with 2 exceptions: Exception 0 :
 org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied
 dependencies for type [Injector] with qualifiers [@Default] at injection
 point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedMethod]
 @Inject org.eclipse.sisu.locators.DefaultBeanLocator.autoPublish(Injector)]
 at
 org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403)
 at
 org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325)
 at
 org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
 at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208) at
 org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519) at
 org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:505) at
 ../..

 /Does GF4 can support archiva ?

I believe no one tested that :-)
So this need some investigation as not working so easily.



 regards



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: 2.0.1 with high cpu usage while idle

[Olivier Lamy]

Maybe because of the async logging from log4j2 (using disruptor).
Have a look here:
http://archiva.apache.org/docs/2.0.2-SNAPSHOT/adminguide/logging.html

HTH
--
Olivier

On 10 April 2014 05:07, Allen Lee allen@asu.edu wrote:
 I upgraded from Archiva 1.3 to Archiva 2.0.1 recently and noticed that
 archiva's CPU usage is consistently high, around 80-85%. I reniced the
 process and now it's ranging from 15-85% of CPU, on average around
 40-50%. At first I thought it might have been the initial startup
 costs of rescanning repositories but it has remained this way after
 several days now.

 The admin system status page doesn't report anything untoward (no
 repository scans happening, etc.). Any suggestions on how to fix this,
 and is this something others have noticed as well?

 Thanks in advance!

 --
 Allen Lee
 Center for the Study of Institutional Diversity [http://csid.asu.edu]
 School of Human Evolution and Social Change [http://shesc.asu.edu]
 College of Liberal Arts and Sciences
 Arizona State University | P.O. Box 872402 | Tempe, Arizona 85287-2402
 480.727.0401 | Fax: 480.965.7671 | e-mail: allen@asu.edu



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Test error in Archiva 2.0.1

[Olivier Lamy]

yes please!

Thanks
Olivier


On 4 April 2014 19:00, Jeroen Hoek jer...@lable.org wrote:
 Should I refile this bug on Codehaus Jira? I didn't think it was
 possible to register there before the registration link was posted
 this week.

 2014-03-31 13:27 GMT+02:00 Jeroen Hoek jer...@lable.org:
 Hello,

 Running mvn clean install on the Archiva 2.0.1 source zip causes one
 test to fail:


 testDefaultRepositoryScanner(org.apache.archiva.repository.scanner.RepositoryScannerTest)
  Time elapsed: 0.028 sec   FAILURE!
 junit.framework.AssertionFailedError: Processed Count (of invalid
 items) expected:6 but was:5
 at junit.framework.Assert.fail(Assert.java:57)
 at junit.framework.Assert.failNotEquals(Assert.java:329)
 at junit.framework.Assert.assertEquals(Assert.java:78)
 at junit.framework.Assert.assertEquals(Assert.java:234)
 at junit.framework.TestCase.assertEquals(TestCase.java:401)
 at 
 org.apache.archiva.repository.scanner.RepositoryScannerTest.testDefaultRepositoryScanner(RepositoryScannerTest.java:255)


 Results :

 Failed tests:
   RepositoryScannerTest.testDefaultRepositoryScanner:255 Processed
 Count (of invalid items) expected:6 but was:5


 All other tests pass.

 * Ubuntu 13.10
 * java-7-oracle


 Kind regards,

 Jeroen Hoek



 --
 Vriendelijke groeten,

 Jeroen Hoek

 Lable
 ✉ jer...@lable.org
 ℡ 088 44 20 202

 http://lable.org
 KvK № 55984037
 BTW № NL8519.32.411.B.01



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: admin password reset

[Olivier Lamy]

just go here http://xircles.codehaus.org/signup


On 3 April 2014 19:38, Andreas Ernst a...@ae-online.de wrote:
 Am 03.04.14 01:35, schrieb Olivier Lamy:

 I believe there is probably an issue with that.
 I will have a look (if you can create a jira that will be nice :-))
 Anyway, there is a good security practise to use which is too lock the
 admin and having some users with admin role.


 No, i got only an account for JIRA at Apache, but not at Codehaus.

 Can you create one for me?



 On 3 April 2014 00:25, Andreas Ernst a...@ae-online.de wrote:

 Hi,

 how do i reset the admin password, copy and paste the password hash on
 the
 MySQL database does not work.

 The mail config has changed to 2.0.1

 2014-04-02T14:48:26.987283+02:00 mail postfix/smtpd[27037]: NOQUEUE:
 reject:
 RCPT from localhost[127.0.0.1]: 504 5.5.2 root@localhost: Sender
 address
 rejected: need fully-qualified address; from=root@l
 ocalhost to=a...@ae-online.de proto=ESMTP helo=mail.andreas-ernst.de

 I got:

 mail-resource host=localhost description= jndi-name=mailSession
 rom=a...@ae-online.de user=a...@ae-online.de/mail-resource
 mail-resource host=localhost description= jndi-name=mail/Session
 from=a...@ae-online.de user=a...@ae-online.de/mail-resource

 Archiva is running on GlassFish Server Open Source Edition 3.1.2.2 (build
 5).

 TIA
 Andreas
 --
 ae | Andreas Ernst | IT Spektrum
 Postfach 5, 65612 Beselich
 Schupbacher Str. 32, 65614 Beselich, Germany
 Tel: +49-6484-91002 Fax: +49-6484-91003
 a...@ae-online.de | www.ae-online.de
 www.tachyon-online.de





 --
 ae | Andreas Ernst | IT Spektrum
 Postfach 5, 65612 Beselich
 Schupbacher Str. 32, 65614 Beselich, Germany
 Tel: +49-6484-91002 Fax: +49-6484-91003
 a...@ae-online.de | www.ae-online.de
 www.tachyon-online.de



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: admin password reset

[Olivier Lamy]

I believe there is probably an issue with that.
I will have a look (if you can create a jira that will be nice :-))
Anyway, there is a good security practise to use which is too lock the
admin and having some users with admin role.


On 3 April 2014 00:25, Andreas Ernst a...@ae-online.de wrote:
 Hi,

 how do i reset the admin password, copy and paste the password hash on the
 MySQL database does not work.

 The mail config has changed to 2.0.1

 2014-04-02T14:48:26.987283+02:00 mail postfix/smtpd[27037]: NOQUEUE: reject:
 RCPT from localhost[127.0.0.1]: 504 5.5.2 root@localhost: Sender address
 rejected: need fully-qualified address; from=root@l
 ocalhost to=a...@ae-online.de proto=ESMTP helo=mail.andreas-ernst.de

 I got:

 mail-resource host=localhost description= jndi-name=mailSession
 rom=a...@ae-online.de user=a...@ae-online.de/mail-resource
 mail-resource host=localhost description= jndi-name=mail/Session
 from=a...@ae-online.de user=a...@ae-online.de/mail-resource

 Archiva is running on GlassFish Server Open Source Edition 3.1.2.2 (build
 5).

 TIA
 Andreas
 --
 ae | Andreas Ernst | IT Spektrum
 Postfach 5, 65612 Beselich
 Schupbacher Str. 32, 65614 Beselich, Germany
 Tel: +49-6484-91002 Fax: +49-6484-91003
 a...@ae-online.de | www.ae-online.de
 www.tachyon-online.de



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: max file upload size in 2.0

[Olivier Lamy]

Hi
Do you mean uploading files via the ui or deploying files to your maven repo?
I don't see any limitations as previously (with 1.3.x) except the
servlet container you use.
But maybe I miss something.
So do you have any issues?


On 22 March 2014 04:20, Jason Chan lemon.tree@gmail.com wrote:
 Hi,

 How can I set the max file upload size in Archiva 2.0 ?

 Thanks,
 Jason



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Archiva 2.0.0 source not on mirrors yet?

[Olivier Lamy]

Thanks for reporting!
I will fix that

--
Olivier
On Mar 20, 2014 9:01 PM, Jeroen Hoek jer...@lable.org wrote:

 Thanks. It looks like there is a 2.0.0/ too many in the link on the
 downloads page.

 2014-03-20 10:26 GMT+01:00 Andreas Ernst a...@ae-online.de:
  Am 20.03.14 10:01, schrieb Jeroen Hoek:
 
  The link to the source zip for Archiva 2.0.0 on the downloads page
  does not appear to work. I've tried several mirrors:
 
 
 
 http://www.eu.apache.org/dist/archiva/2.0.0/src/2.0.0/apache-archiva-2.0.0-src.zip
 
 
  I got the sources
 
  http://mirrors.ae-online.de/apache/archiva/2.0.0/src/
 
  --
  ae | Andreas Ernst | IT Spektrum
  Postfach 5, 65612 Beselich
  Schupbacher Str. 32, 65614 Beselich, Germany
  Tel: +49-6484-91002 Fax: +49-6484-91003
  a...@ae-online.de | www.ae-online.de
  www.tachyon-online.de



 --
 Vriendelijke groeten,

 Jeroen Hoek

 Lable
 ✉ jer...@lable.org
 ℡ 088 44 20 202

 http://lable.org
 KvK № 55984037
 BTW № NL8519.32.411.B.01

Re: Debugging LDAP connection?

[Olivier Lamy]

most of the code related to ldap is located in some modules here:
https://github.com/apache/redback-core




On 20 March 2014 21:12, Jeroen Hoek jer...@lable.org wrote:

 Hello,

 With Archiva 2.0.0 (standalone) I can connect to my LDAP-server, but
 in the LDAP/Roles Mapping tab no groups are found in the search field.
 If I run ldapsearch from the Archiva host, I do see all the groups.

 BaseDN for groups is set to ou=group,dc=lable,dc=org.
 Running ldapsearch -h HOST -p PORT -x -b ou=group,dc=lable,dc=org
 from the host's CLI yields the groups as expected (all objectClass:
 posixGroup).

 What is the best way to debug the LDAP settings? Am I overlooking
 something?

 --
 Kind regards,

 Jeroen Hoek




-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Debugging LDAP connection?

[Olivier Lamy]

especially here:
https://github.com/apache/redback-core/tree/trunk/redback-common/redback-common-ldap/src/main/java/org/apache/archiva/redback/common/ldap/role

maybe having the package org.apache.archiva.redback.common.ldap in debug
mode can help.

You can have a look here
https://github.com/apache/redback-core/tree/trunk/redback-rbac/redback-rbac-providers/redback-rbac-ldap/src/main/java/org/apache/archiva/redback/rbac/ldap


On 20 March 2014 22:17, Olivier Lamy ol...@apache.org wrote:

 most of the code related to ldap is located in some modules here:
 https://github.com/apache/redback-core




 On 20 March 2014 21:12, Jeroen Hoek jer...@lable.org wrote:

 Hello,

 With Archiva 2.0.0 (standalone) I can connect to my LDAP-server, but
 in the LDAP/Roles Mapping tab no groups are found in the search field.
 If I run ldapsearch from the Archiva host, I do see all the groups.

 BaseDN for groups is set to ou=group,dc=lable,dc=org.
 Running ldapsearch -h HOST -p PORT -x -b ou=group,dc=lable,dc=org
 from the host's CLI yields the groups as expected (all objectClass:
 posixGroup).

 What is the best way to debug the LDAP settings? Am I overlooking
 something?

 --
 Kind regards,

 Jeroen Hoek




 --
 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