Re: [VOTE] Move to Attic

[Martin]

Hi,

+1 

Regards

Martin

Am Dienstag, 30. Januar 2024, 02:19:42 CET schrieb 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
> 
> 




signature.asc
Description: This is a digitally signed message part.

[ANN] Apache Archiva 2.2.7 released

[Martin]

The Apache Archiva team is pleased to announce the release of 
   Archiva 2.2.7
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.7 is a bugfix release and updates to log4j 2.17.0 for 
security reasons


** 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.7/release-notes.html


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

[ANN] Apache Archiva 2.2.6 released

[Martin]

The Apache Archiva team is pleased to announce the release of 
   Archiva 2.2.6
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.6 is a security fix release.


** 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.6/release-notes.html


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

Re: archiva-security-audit.log remains empty

[Martin]

Hi Bram,

indeed, it looks as if the documentation is outdated in this case. I checked 
the code and the mechanism for auditing
is not used anymore. I'm not sure, when this was changed. 
And currently there is no alternative audit mechanism.

The only alternative ( but this is not really an audit log )  would be to 
change the log4j2.xml and set the logger configuration for the logger
org.apache.archiva.redback.rest.services.DefaultLoginService
to debug.

You can redirect the logging of this logger to the archiva-security-audit.log 
by:

  
 

And you should better set the immediateFlush="true" attribute on the appender.

Sorry for that.

Regards

Martin

Am Samstag, 26. Juni 2021, 14:45:39 CEST schrieb Bram Van Dam:
> Greetings,
> 
> I'm running Archiva 2.2.5 and I'm having some difficulty getting audit 
> logging to work.
> 
> The documentation [1] seems to suggest that it should Just Work and log 
> user logins etc, but the file remains empty. Regular logging seems to 
> work reasonably well [2], it's just this one logfile that doesn't seem 
> to want to cooperate.
> 
> I've tried increasing the log level for the redbackAuditLog to debug, 
> but that hasn't made any difference.
> 
> Any pointers in the right direction would be much appreciated :-)
> 
>   - Bram
> 
> [1] https://archiva.apache.org/docs/2.2.5/adminguide/security-logs.html
> 
> [2] archiva.log contains very rudimentary "login failed" events, but 
> doesn't include a remote IP address, only the username. And the request 
> log logs login failures with status code 500, making it very difficult 
> to do any meaningful auditing.
> 
> 

[SECURITY] CVE-2020-9495: Apache Archiva login service is vulnerable to LDAP injection

[Martin]

CVE-2020-9495: Apache Archiva login service is vulnerable to LDAP injection

Severity: Medium

Vendor:
The Apache Software Foundation

Versions Affected:

Apache Archiva all versions before 2.2.5

By providing special values to the archiva login form a attacker is able to 
retrieve user attribute data from the connected LDAP server. 
With certain characters it is possible to modify the LDAP filter used to query 
the users on the connected LDAP server. 
By measuring the response time, arbitrary attribute data can be retrieved from 
LDAP user objects.

Mitigation:

Upgrade to Apache Archiva 2.2.5 or higher

References:
http://archiva.apache.org/security.html#CVE-2020-9495

The newest Archiva version can be downloaded from:
http://archiva.apache.org/download.cgi

[ANN] Apache Archiva 2.2.5 released

[Martin]

The Apache Archiva team is pleased to announce the release of 
   Archiva 2.2.5 
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.5 is a bug fix release.

** 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.5/release-notes.html

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

Re: How Can I regist NAS HDDD as Alias?

[Martin]

Hi,

I think you wrote to the wrong mailing list. This list is about Apache Archiva, 
a artifact repository, not about the HTTPD server.

Please have a look at: 
https://httpd.apache.org/
https://httpd.apache.org/lists.html

Regards

Martin

Am Dienstag, 14. April 2020, 02:29:45 CEST schrieb kohashi50_9...@yahoo.co.jp:
> I have Apache 2.4 HTTPD server installed on Windows 10. I could register the 
> folder of the HDD connected by USB with Alias.
> 
> However, the network drive of the LAN connected HDD cannot be registered as 
> Alias.
> 
> Please tell me how to assign Alias of network drive of LAN connection HDD 
> with Apache2.4.
> 
> Also, please tell me if there is a method other than Alias setting that 
> allows you to register content on a LAN-connected HDD.
> thnak you foe reading my mail
> 
> 
> 
> 
> 
> 
> Alias /v2 "F:\MyVideo2"
> 
> 
> Options Indexes FollowSymLinks
> AllowOverride None
> Require all granted
> 
> 
> Alias /v3 "\\LS210DA0C\\video"
> 
> 
> Options Indexes FollowSymLinks
> AllowOverride None
> Require all granted
> 
> 
> 
> 

Re: Question about Archiva

[Martin]

Hi Karl-Heinz,

there is no explicit functionality to do this. But the configuration is stored 
in archiva.xml and repositories are stored
in the filesystem, so it should be possible to do this. 
You can look at the archiva-jetty submodule. There are the necessary files 
needed to start a jetty server running
archiva.
For publish and proxy functionality this should be sufficient. If you need to 
use search or metadata, archiva has to scan
the repositories after startup, which may be difficult to trigger on demand 
(there are background jobs running after startup).

If you need further help or have questions, don't hesitate to ask.

Regards

Martin


Am Montag, 13. April 2020, 16:43:32 CEST schrieb Karl Heinz Marbaise:
> Hi,
> 
> currently I'm writing a Test tool[1] for Maven Plugins etc. I want to
> know if there is an option to use Archiva as Repository Manager
> programatically without UI setup only via code.
> 
> The functionality I need:
> 
>   * Serving a repository where the content is defined by a directory
> with the appropriate structure.
>   * Providing a repository where artifacts can be published to (
> great would a release and a SNAPSHOT repo).
>   * Proxy functionality to forward request to a defined
> repository (for example Central)
> 
> Or the question is: Can the setup being done programmatically and a
> Servlet container being started via code with limited funcitonality?
> 
> Currently I'm trying to setup MRM[2] programatically without the plugin
> context...
> 
> Kind regards
> Karl-Heinz Marbaise
> Apache Maven PMC
> 
> [1]: https://github.com/khmarbaise/maven-it-extension
> [2]: https://www.mojohaus.org/mrm/index.html
> 
> 
> 
> 

[SECURITY] CVE-2019-0214: Apache Archiva arbitrary file write and delete on the server

[Martin]

CVE-2019-0214: Apache Archiva arbitrary file write and delete on the server

Severity: Medium

Vendor:
The Apache Software Foundation

Versions Affected:
Apache Archiva 2.0.0 - 2.2.3
The unsupported versions 1.x are also affected.  

It is possible to write files to the archiva server at arbitrary locations by 
using the artifact upload mechanism. 
Existing files can be overwritten, if the archiva run user has appropriate 
permission on the filesystem for the target file.

Mitigation:
  It is highly recommended to upgrade to Archiva 2.2.4 or higher, where 
additional validations are implemented to prevent such malicious parameter 
values.
  As intermediate action you may reduce the number of users that are allowed to 
upload to archiva and make sure, that the archiva run user may have only 
  write permission to the directories needed.

References:
http://archiva.apache.org/security.html#CVE-2019-0214

The newest Archiva version can be downloaded from:
http://archiva.apache.org/download.cgi

[SECURITY] CVE-2019-0213: Apache Archiva Stored XSS

[Martin]

CVE-2019-0213: Apache Archiva Stored XSS

Severity: Low

Vendor:
The Apache Software Foundation

Versions Affected:
Apache Archiva 2.0.0 - 2.2.3
The unsupported versions 1.x are also affected.  

It may be possible to store malicious XSS code into central configuration 
entries, i.e. the logo URL. 
The vulnerability is considered as minor risk, as only users with admin role 
can change the configuration, or the communication 
between the browser and the Archiva server must be compromised. 

Mitigation:
  All users are recommended to upgrade to Archiva 2.2.4 or higher, 

References:
http://archiva.apache.org/security.html#CVE-2019-0213

The newest Archiva version can be downloaded from:
http://archiva.apache.org/download.cgi

[ANN] Apache Archiva 2.2.4 released

[Martin]

The Apache Archiva team is pleased to announce the release of 
   Archiva 2.2.4. 
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/mailing-lists.html

Apache Archiva 2.2.4 is a bug fix release.

** 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.4/release-notes.html

Bugs fixed

[MRM-1972] Stored XSS in Web UI Organization Name

[MRM-1966] Repository-purge not working

[MRM-1958] Purge by retention count deletes files but leaves history on 
website.

[MRM-1929] Repository purge is not reflected in index


Have fun! -- The Apache Archiva Team

Re: Binaries distributable for Archiva 2.2.4

[Martin Stockhammer]

Hi,

will be published in the next days.
But it's only a bugfix release. No new features.

Regards

Martin

Am 29. April 2019 21:25:33 MESZ schrieb "Mirabito, Massimo (Max) 
(CDC/DDID/NCHHSTP/OD) (CTR)" :
>Dear All,
>
>We are running Archiva V2.2.3  on Windows. I just noticed that there is
>a 2.2.4 branch on github does anyone know when binaries will be
>available?
>
>Thanks in advance
>max

-- 
This message was sent from mobile phone.

Re: Archiva Security

[Martin]

Hi Ranjith,

could you please check the permissions of the guest user? The guest user is the 
one which is assigned, if the
user is not authenticated.
Other possibility is, that you are already logged in with your browser (there 
are authentication cookies stored in the browser),
because you used the web ui before.
Please logout before testing with your browser. The better alternative is to 
test with curl or wget, both do not send cookies
by default.

Regards

Martin

Am Dienstag, 27. November 2018, 07:25:28 CET schrieb ranjithmnair:
> Hi,
> I am using Archiva, and when i include a dependency uploaded in archiva in a
> maven project, the security is working fine and it is allowing only if the
> credentials are provided in settings.xml.
> But the problem is anyone is able to access the repository
> (internal/snapshot), /using the url we mention in the settings/pom to
> download using maven install/, directly in browser and download the jars. Is
> there a way to prevent that.. *I am talking about this url:
> http://localhost:8080/repository/internal/*.
> Is there a way to password protect this url from accessing externally?
> something like it ask for password which i configured in archiva while
> clicking on http://localhost:8080/repository/internal/
> 
> Thanks very much..
> 
> With Best Regards,
> Ranjith
> 
> 
> 
> --
> Sent from: http://archiva.996284.n3.nabble.com/User-f10698.html
> 
> 

Re: Interested in a Docker Image & Kubernetes Chart?

[Martin Stockhammer]

Hi Terence,

great! Start with small contributions to get an understanding how the process 
works. For getting bigger changes into the project the dev mailing list is the 
best place to start discussing about the details.

Regards

Martin

Am 22. Oktober 2018 21:34:24 MESZ schrieb Terence Kent :
>Martin,
>
>Sounds good! I've got to pickup another project, but as soon as I have
>some
>time I'll pickup the Archiva source and take a look at where the docker
>image would fit. To be honest, I probably should have just done that to
>begin with. There are a few minor things I've been wanting to
>change/fix in
>there for years, I've just been avoiding the effort of getting familiar
>with the project source :-). If I just bite the bullet get familiar
>with
>the source, I can send over a few different pull requests.
>
>Best,
>Terence
>
>
>
>
>
>On Sat, Oct 20, 2018 at 12:13 AM Martin  wrote:
>
>> Hi Terence,
>>
>> thank you for help.
>> As you already know, resources are very limited in this project. So,
>I
>> have to focus on the things that are manageable.
>> Code contribution is very appreciated, so if you have any changes you
>like
>> to get into the project, feel free to create pull
>> requests. If you like, you can even add the complete
>docker/kubernetes
>> part as pull request.
>> If you have any questions, don't hesitate to ask.
>>
>> Regards
>>
>> Martin
>>
>>
>> Am Samstag, 20. Oktober 2018, 01:30:41 CEST schrieb Terence Kent:
>> > Hey Martin,
>> >
>> > Feel free to add a link to our image and chart on the Archiva
>webpage.
>> > Also, I threw together a v2-snapshot
>> > <https://github.com/xetus-oss/docker-archiva/tree/v2-snapshot>
>> branch/tag
>> > of the image that is built using the most recent 2.2.4 snapshot.
>All of
>> our
>> > image tests pass using the current 2.2.4-SNAPSHOT build, as you
>would
>> > expect.
>> >
>> > Looking ahead, whenever you dust off this project to finish out
>2.2.4 or
>> > jump to version 3, I'd really like to see a docker image brought
>into the
>> > project directly. Maintaining the image code separately from the
>project
>> > isn't the greatest idea and since you already have a docker image
>for
>> > testing, I'm sure it's something you've considered. If we're
>available
>> the
>> > next time there's some focus on this project, we'll see if we can
>help
>> out
>> > with that part. We've learned several lessons about running Archiva
>in a
>> > container over the past few years and we'd love to make some small
>> changes
>> > in the source project to make life easier :-).
>> >
>> > Oh, and it'd sure be nice to have an official Kubernetes helm chart
>once
>> > there is an offical docker image. I'm confident that a lot more
>people
>> > would use Archiva if was available there.
>> >
>> > Best,
>> > Terence
>> >
>> > On Fri, Oct 19, 2018 at 12:31 PM Martin 
>wrote:
>> >
>> > > Hi Terence,
>> > >
>> > > thank you for the information. Great work and great to hear, that
>you
>> > > decided to keep archiva, despite the
>> > > slow development.
>> > > I would like to add the link to our archiva web page if you don't
>mind.
>> > > We are using docker images for our integration tests on the
>jenkins
>> > > server, but without kubernetes, maybe I
>> > > can find some configuration on your project that may be useful
>for
>> these.
>> > >
>> > > Our current snapshot version for the stable 2.2 release branch
>> > > (2.2.4-SNAPSHOT) contains some fixes and
>> > > there are not very much changes compared to the 2.2.3 version, so
>I
>> 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
>> > >
>> 

Re: Interested in a Docker Image & Kubernetes Chart?

[Martin]

Hi Terence,

thank you for help.
As you already know, resources are very limited in this project. So, I have to 
focus on the things that are manageable.
Code contribution is very appreciated, so if you have any changes you like to 
get into the project, feel free to create pull 
requests. If you like, you can even add the complete docker/kubernetes part as 
pull request. 
If you have any questions, don't hesitate to ask.

Regards

Martin


Am Samstag, 20. Oktober 2018, 01:30:41 CEST schrieb Terence Kent:
> Hey Martin,
> 
> Feel free to add a link to our image and chart on the Archiva webpage.
> Also, I threw together a v2-snapshot
> <https://github.com/xetus-oss/docker-archiva/tree/v2-snapshot> branch/tag
> of the image that is built using the most recent 2.2.4 snapshot. All of our
> image tests pass using the current 2.2.4-SNAPSHOT build, as you would
> expect.
> 
> Looking ahead, whenever you dust off this project to finish out 2.2.4 or
> jump to version 3, I'd really like to see a docker image brought into the
> project directly. Maintaining the image code separately from the project
> isn't the greatest idea and since you already have a docker image for
> testing, I'm sure it's something you've considered. If we're available the
> next time there's some focus on this project, we'll see if we can help out
> with that part. We've learned several lessons about running Archiva in a
> container over the past few years and we'd love to make some small changes
> in the source project to make life easier :-).
> 
> Oh, and it'd sure be nice to have an official Kubernetes helm chart once
> there is an offical docker image. I'm confident that a lot more people
> would use Archiva if was available there.
> 
> Best,
> Terence
> 
> On Fri, Oct 19, 2018 at 12:31 PM Martin  wrote:
> 
> > Hi Terence,
> >
> > thank you for the information. Great work and great to hear, that you
> > decided to keep archiva, despite the
> > slow development.
> > I would like to add the link to our archiva web page if you don't mind.
> > We are using docker images for our integration tests on the jenkins
> > server, but without kubernetes, maybe I
> > can find some configuration on your project that may be useful for these.
> >
> > Our current snapshot version for the stable 2.2 release branch
> > (2.2.4-SNAPSHOT) contains some fixes and
> > there are not very much changes compared to the 2.2.3 version, so I 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
> > >
> >
> >
> >
> 

Re: deleting old snapshots

[Martin]

Hi Matthew, Terence,

thank you Terence, this is right. These should be the necessary configuration 
points to get it work.
The cron entry is also required, and you have to make sure that the snapshot 
artifact files are named, as maven creates
them, e.g. archiva-checksum-3.0.0-20180409.013311-155.jar

You have to make sure, that the "artifact" file types in the "Repository 
Scanning" configuration match your files, and the types
should not be listed in the "ignored" list.

You can manually run the the scan process by clicking the "Directories 
Scanning" action on the repository. If you activate debug
log, you should see entries from the "RepositoryPurgeConsumer" in archiva.log.

Regards

Martin


Am Freitag, 19. Oktober 2018, 19:22:01 CEST schrieb Terence Kent:
> Stefaan, Matthew,
> 
> I hate "works for me responses", so apologies in advance. However, we are
> seeing artifacts automatically removed according to our repository
> retention settings in our deployment and I wanted to share
> possibly-relevant information.
> 
> We've been using Archiva version 2.2.3 in a docker container for over a
> year now and haven't had any retention-related problems. Here are the parts
> of our configuration that may be relevant.
> 
>1. We have dedicated "snapshots" and "releases" repositories. Only
>snapshots are allowed in the "snapshots" repository, and only "releases" in
>the releases repository.
>2. In each repository we have retention policies, and each repository is
>configured to be scanned.
>3. The "repository-purge" consumer is enabled.
> 
> 
> Also, FWIW, I'm pretty sure the code that applies the retention policy is
> in the "repository-purge" consumer, and the out-most class for the feature
> is found here:
> 
> https://github.com/apache/archiva/blob/9351c66bc89c65357ba72bb84982951919cbc0c4/archiva-modules/archiva-base/archiva-consumers/archiva-core-consumers/src/main/java/org/apache/archiva/consumers/core/repository/RepositoryPurgeConsumer.java
> 
> Best,
> Terence
> 
> 
> 
> 
> 
> 
> On Fri, Oct 19, 2018 at 7:59 AM Matthew Broadhead
>  wrote:
> 
> >
> > https://github.com/apache/archiva/blob/9351c66bc89c65357ba72bb84982951919cbc0c4/archiva-modules/archiva-scheduler/archiva-scheduler-repository/src/main/java/org/apache/archiva/scheduler/repository/ArchivaRepositoryScanningTaskExecutor.java#L181
> >
> > seems that it hasn't been implemented?
> >
> > On 19/10/2018 15:39, Matthew Broadhead wrote:
> > > yes i have activated the "repository-purge" consumer under Repository
> > > scanning -> Consumers.  maybe i also need to activate the
> > > "validate-checksums" consumer as that is the only one not enabled
> > >
> > > in my snapshot repository i have the following values:
> > > Cron Expression  0 0,30 * * * ?
> > > Days Older  30
> > > Retention Count  2
> > > Delete Released Snapshots is checked
> > >
> > > i was going to upgrade to 2.2.3 but if yours is not working either
> > > then there is not much point
> > >
> > > i wonder if there is any way to trigger it from the command line?
> > >
> > > On 19/10/2018 13:52, Stefaan Dutry wrote:
> > >> According to my understanding it should be through the
> > >> repository-purge consumer. (This is located under Administration >
> > >> repository scanning > Consumers)
> > >>
> > >> Then on the repository configuration itself there are settings like
> > >> "Delete Released Snapshots" and "retention count" and "days older"
> > >>
> > >> Unfortunately the automatic purge isn't happening on our systems either.
> > >> (our version is 2.2.3)
> > >>
> > >> see:
> > >> http://archiva.apache.org/docs/2.2.0/adminguide/repositories.html
> > >> * delete released snapshots
> > >> * repository purge by days older
> > >> * repository purge by retention count
> > >> http://archiva.apache.org/docs/2.2.0/adminguide/consumers.html
> > >> * repository-purge
> > >>
> > >> But this is what's specified in the link you provided
> > >>
> > >> Regards,
> > >> Stefaan Dutry
> > >> Op vr 19 okt. 2018 om 13:37 schreef Jay Vyas :
> > >>> Hey Matt: some of us are definetly here.  Archiva saved me when I
> > >>> couldn’t pay for nexus so, I’d definetly say there are a few others
> > >>> in that boat. 

Re: Interested in a Docker Image & Kubernetes Chart?

[Martin]

Hi Terence,

thank you for the information. Great work and great to hear, that you decided 
to keep archiva, despite the
slow development.
I would like to add the link to our archiva web page if you don't mind. 
We are using docker images for our integration tests on the jenkins server, but 
without kubernetes, maybe I
can find some configuration on your project that may be useful for these.

Our current snapshot version for the stable 2.2 release branch (2.2.4-SNAPSHOT) 
contains some fixes and
there are not very much changes compared to the 2.2.3 version, so I 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
> 

Re: deleting old snapshots

[Martin Stockhammer]

Hi Mathew,

sorry resources are very limited. 
To help sort this out, please use version 2.2.3. 
There are some tickets in jira about purging. Have you checked, if the 
snapshots are still in the filesystem? There is an issue about the index not 
updated for purged files.
Can you provide some logs?

Regards

Martin




Am 19. Oktober 2018 15:39:54 MESZ schrieb Matthew Broadhead 
:
>yes i have activated the "repository-purge" consumer under Repository 
>scanning -> Consumers.  maybe i also need to activate the 
>"validate-checksums" consumer as that is the only one not enabled
>
>in my snapshot repository i have the following values:
>Cron Expression  0 0,30 * * * ?
>Days Older  30
>Retention Count  2
>Delete Released Snapshots is checked
>
>i was going to upgrade to 2.2.3 but if yours is not working either then
>
>there is not much point
>
>i wonder if there is any way to trigger it from the command line?
>
>On 19/10/2018 13:52, Stefaan Dutry wrote:
>> According to my understanding it should be through the
>> repository-purge consumer. (This is located under Administration >
>> repository scanning > Consumers)
>>
>> Then on the repository configuration itself there are settings like
>> "Delete Released Snapshots" and "retention count" and "days older"
>>
>> Unfortunately the automatic purge isn't happening on our systems
>either.
>> (our version is 2.2.3)
>>
>> see:
>> http://archiva.apache.org/docs/2.2.0/adminguide/repositories.html
>> * delete released snapshots
>> * repository purge by days older
>> * repository purge by retention count
>> http://archiva.apache.org/docs/2.2.0/adminguide/consumers.html
>> * repository-purge
>>
>> But this is what's specified in the link you provided
>>
>> Regards,
>> Stefaan Dutry
>> Op vr 19 okt. 2018 om 13:37 schreef Jay Vyas :
>>> Hey Matt: some of us are definetly here.  Archiva saved me when I
>couldn’t pay for nexus so, I’d definetly say there are a few others in
>that boat.  Ufortubately nobody has responded yet.  Next step if
>necessary would be filing a JIrA issue on the Apache organization for
>archiva if nobody is able to help on the thread.
>>>
>>>> On Oct 19, 2018, at 4:51 AM, Matthew Broadhead
> wrote:
>>>>
>>>> sorry to chase but is anyone still monitoring this list?  are we
>supposed to move to sonatype nexus oss?  i thought apache created
>maven?
>>>>
>>>>> On 08/10/2018 20:00, Matthew Broadhead wrote:
>>>>> i am using 2.2.0 and i have looked through all the settings but i
>don't understand how to automatically delete old snapshots.
>>>>>
>>>>> i followed this
>https://stackoverflow.com/questions/12315461/how-to-configure-maven-or-apache-archiva-that-it-keeps-only-n-builds-of-an-snaps
>but it didn't work

-- 
This message was sent from mobile phone.

Re: Help with AD LDAP config in 2.2.3

[Martin]

Hi,

I'm not sure, but maybe https://issues.apache.org/jira/browse/MRM-1866 can help.

Do you have both Ldap and Database repository configured?

Regards

Martin

Am Mittwoch, 26. September 2018, 21:16:11 CEST schrieb Candreva, Chris:
> After beating my head against the LDAP config, I finally have it to the point 
> I THINK it's working, but I still can't have LDAP uses log in.
> 
> When I try with my AD account (this email address, so I won't obfuscate it), 
> the following error shows up in a red box above the login form:
> 
> [Could not find object. Type 'org.apache.archiva.redback.users.jdo.JdoUser'. 
> Id: 'cqcj'.]
> 
> And the following is in the archiva.log file:
> 
> 2018-09-26 14:47:55,237 [qtp922390534-27] INFO  
> org.apache.archiva.redback.users.ldap.ctl.DefaultLdapController [] - Found 
> user: cqcj
> 2018-09-26 14:47:55,237 [qtp922390534-27] WARN  
> org.apache.archiva.web.security.ArchivaUserManagerAuthenticator [] - Password 
> is Invalid for user cqcj and userManager 'ldap'.
> 2018-09-26 14:47:55,240 [qtp922390534-27] WARN  
> org.apache.archiva.web.security.ArchivaUserManagerAuthenticator [] - Login 
> for user cqcj and userManager jdo failed. user not found.
> 2018-09-26 14:47:55,244 [qtp922390534-27] INFO  
> org.apache.archiva.redback.authentication.ldap.LdapBindAuthenticator [] - 
> user 'cqcj' authenticated
> 
> I'm stumped. Any help would be greatly appreciated !
> 
> -Chris
> 
> 

Re: Problems with REST API getting artifacts.

[Martin]

Hello,

the 204 is thrown, if the artifact is not found by the search call. So I'm not 
sure, why it is not found.
Is anonymous access allowed to your repository? 
How many repositories do you have? Is it the same, if you set the repository ID 
with the 'r'-Parameter?
Can you find the artifact on the web UI with the given entries?

Is there any info in the log file? If not, could you please change it to debug 
level, and send it to me?

Greetings

Martin

Am Mittwoch, 21. März 2018, 21:54:26 CET schrieb Maury Hammel:
> Hello, I have just getting into Archiva and am having problems attempting to 
> download artifacts using the REST API.  
> 
> I have the standalone distribution of Archiva 2.2.3 installed on CentOS 7 and 
> have started it with the "archiva console" command.
> 
> As noted in the Quick Start guide, I can download an artifact using the 
> following URL from the command line on the same machine:
> 
> % wget 
> "http://localhost:8080/repository/internal/junit/junit/3.8.1/junit-3.8.1.jar;
> 
> My first attempt to down load the same artifact using the REST API generated 
> a "403 Forbidden" error:
> 
> % wget 
> "http://localhost:8080/restServices/archivaServices/searchService/artifact?g=junit=junit=3.8.1;
>  -O junit-3.8.1.jar
> 
> After some reading, I went into conf/archiva.xml, changed 
> rest.csrffilter.enabled to "false" and restarted Archiva.
> 
> Now when attempting the above command, I no longer get the "403 Forbidden" 
> error, I get a "204 No Content" error and an empty file (see wget output 
> below).
> 
> Is there something else (or something different) that I need to change in the 
> Archiva configuration, or is my request formatted incorrectly?
> 
> Thanks in advance.
> 
> 
> --2018-03-21 14:53:33--  
> http://localhost:8080/restServices/archivaServices/searchService/artifact?g=junit=junit=3.8.1
> Resolving localhost (localhost)... ::1, 127.0.0.1
> Connecting to localhost (localhost)|::1|:8080... connected.
> HTTP request sent, awaiting response... 204 No Content
> Length: 0
> Saving to: 'junit-3.8.1.jar'
> 
> [ <=> 
> ] 0   --.-K/s   in 0s
> 
> 2018-03-21 14:53:33 (0.00 B/s) - 'junit-3.8.1.jar' saved [0/0]
> 
> 

Re: DefaultFileLockManager & Lock

[Martin]

Hi,

I'm not sure, what you want to know exactly about these classes. This is a file 
lock, so there can only exist one
lock per file. Please formulate a more detailed question. Maybe I can help then.

Greetings

Martin

P.S: Is '二毛' your name? 

Am Dienstag, 14. November 2017, 16:57:44 CET schrieb 二毛:
> I just read these two file's code, It seems there can only be a single lock 
> for each file.can someone explain this ?

Re: Need help configuring Archiva LDAP configuration with anonymous snapshot deploy

[Martin]

Hi Stefaan,

the cause seems to be plausible. That could explain, why the user was updated.
Regarding your questions, unfortunately I think I cannot provide a proper 
solution:

I know that there are certain parts in the code that use "guest" for the name 
of the guest user and as I
know it cannot be fixed in a few lines of code.
You can try to keep the default guest user as 'guest' and change the filter for 
the ldap query to exclude the 
guest user. But I'm not sure, if this works.

Regarding the 1000 results:
Do you have Active Directory as LDAP server running? As I know AD has a server 
limit for the returned results
per query. The only workaround on the client would be to use paged ldap 
queries. But currently paged queries are not implemented
by archiva, so there is no configuration entry to increase the result size.

So sorry, that I cannot provide more useful help. Feel free to create a JIRA 
ticket for both (or a pull request).

Greetings

Martin


Am Dienstag, 31. Oktober 2017, 09:19:13 CET schrieb stefaan.du...@roularta.be:
> Hello,
> 
> Sorry for my late response. (vacation followed by other priorities at work)
> After we finaly went back to configuring the archiva instance, it no longer 
> started.
> 
> We re-did the configuration.
> Currently we have a setup as follows:
> * UserManager(s) chosen
> * LDAP User Manager
> * Database User Manager
> * RbacManager(s) chosen
> * LDAP RBac Manager
> * Database RBac Manager
> 
> As additional configuration we changed the property "redback.default.guest" 
> to "archivaguest" instead of "guest"
> After this change, we no longer have the problem of the guest user being 
> updated.
> We assume the problem was caused because our LDAP had a user named "guest" 
> which caused it to overwrite the config we had for the guestuser.
> 
> We were able to assign roles to LDAP groups.
> 
> There are still a few minor issues that we have:
> 
> * when starting the application when not logged on: "Unable to find principal 
> archivaguest"
>   This is probably caused because we changed the redback.default.guest 
> property.
>   Is there a configuration we can do to prevent this message.
> 
> * when trying to find a user, it only loads exactly 1000 users from our LDAP 
> system. When the user is not among those 1000, you can't go to the user to 
> check the effective roles of the user. Is this a hard maximum or is this a 
> setting that can be changed? (applying the LDAP group to a user not in this 
> list still works)
> 
> Regards,
> Stefaan Dutry  
> 
> -Oorspronkelijk bericht-
> Van: Martin [mailto:marti...@apache.org] 
> Verzonden: maandag 28 augustus 2017 21:42
> Aan: users@archiva.apache.org
> Onderwerp: Re: Need help configuring Archiva LDAP configuration with 
> anonymous snapshot deploy
> 
> Hi,
> 
> it would be helpful, if you could provide some logs. 
> The removal of the roles from the guest user seems a bit strange. You are 
> running a single instance only, not in a clustered environment?
> 
> By the way, the CSRF prevention that has been introduced with version 2.2.3 
> can be deactivated, if you think the security risk is acceptable. Please look 
> at the release notes.
> 
> Greetings
> 
> Martin
> 
> Am Dienstag, 22. August 2017, 11:50:48 CEST schrieb Stefaan Dutry:
> > In our current setup we only use the LDAP configuration to 
> > authenticate and not for authorisation.
> > 
> > We would like to switch to using LDAP group membership to configure 
> > group membership.
> > 
> > Reasons:
> >   -) Archiva is not able to find all LDAP users in the Users -> Manage 
> > section.
> >   -) The dirty workaround we used to configure user - role management 
> > for those we couldn't find, no longer works with version 2.2.3 
> > (abusing the REST-API)
> > 
> > What we managed to do so far:
> >   -) We managed to connect to LDAP successfully
> >   -) We managed to set up the groups in LDAP and configure the 
> > LDAP/Roles Mappings
> >   -) We switched to only LDAP User Manager and only LDAP RBac Manager 
> > (Users -> Users Runtime Configuration)
> > 
> > Problems we are having:
> >   -) We are no longer able to upload an artifact to the snapshot 
> > repository. We need this because we are using jenkins to start builds 
> > and create snapshots automatically
> >   -) We tried adding the roles to the Guest user, but they seem to be 
> > automatically removed after a certain amount of time (15 min or so)
> >   -) Archiva tends to log me out randomly, even when i'm active.
> > 
> > Version: 2.2.3
> > 
> > Can someone help me find what settings are incorrect.
> > 
> > 
> 
> 
> 

Re: Need help configuring Archiva LDAP configuration with anonymous snapshot deploy

[Martin]

Hi,

it would be helpful, if you could provide some logs. 
The removal of the roles from the guest user seems a bit strange. You are 
running a
single instance only, not in a clustered environment?

By the way, the CSRF prevention that has been introduced with version 2.2.3 can 
be deactivated, if
you think the security risk is acceptable. Please look at the release notes.

Greetings

Martin

Am Dienstag, 22. August 2017, 11:50:48 CEST schrieb Stefaan Dutry:
> In our current setup we only use the LDAP configuration to
> authenticate and not for authorisation.
> 
> We would like to switch to using LDAP group membership to configure
> group membership.
> 
> Reasons:
>   -) Archiva is not able to find all LDAP users in the Users -> Manage 
> section.
>   -) The dirty workaround we used to configure user - role management
> for those we couldn't find, no longer works with version 2.2.3
> (abusing the REST-API)
> 
> What we managed to do so far:
>   -) We managed to connect to LDAP successfully
>   -) We managed to set up the groups in LDAP and configure the
> LDAP/Roles Mappings
>   -) We switched to only LDAP User Manager and only LDAP RBac Manager
> (Users -> Users Runtime Configuration)
> 
> Problems we are having:
>   -) We are no longer able to upload an artifact to the snapshot
> repository. We need this because we are using jenkins to start builds
> and create snapshots automatically
>   -) We tried adding the roles to the Guest user, but they seem to be
> automatically removed after a certain amount of time (15 min or so)
>   -) Archiva tends to log me out randomly, even when i'm active.
> 
> Version: 2.2.3
> 
> Can someone help me find what settings are incorrect.
> 
> 

Re: Error 403 when proxying with Nginx

[Martin Pola]

I didn't receive the reply from Mr. Lamy, but I was able to read it in the WWW 
archives of this mailing list.

Thanks to both of you! It looks like the issue was caused by Archiva's CSRF 
prevention filter. Setting rest.baseUrl resolved the it.

- Martin


On lördag 12 augusti 2017 kl. 13:39:33 CEST you wrote:
> Hi Martin,
> 
> do you use the current version? Archiva 2.2.3?
> There is a CSRF-prevention filter active. You have to add the URL of your
> nginx server to the rest.baseUrl field (you may set a comma separated list
> for multiple URLs).
> 
> See http://archiva.apache.org/docs/2.2.3/release-notes.html
> Note: If your archiva installation is behind a reverse proxy or load
> balancer, it may be possible that the Archiva Web UI does not load after
> the upgrade. If this is the case you may access the WebUI via localhost or
> edit archiva.xml manually. In the "Redback Runtime Configuration"
> properties you have to enter the base URLs of your archiva installation to
> the rest.baseUrl field.
> 
> See  also:
> http://archiva.apache.org/redback/integration/rest.html
> http://archiva.apache.org/redback/
> configuration.html#Cross_Site_Request_Forgery_CSRF_Prevention
> 
> If that does not work please create a JIRA ticket and provide detailed
> logging output.
> 
> Greetings
> 
> Martin
> 
> Am Samstag, 12. August 2017, 10:55:23 CEST schrieb Martin Pola:
> > 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

Re: Error 403 when proxying with Nginx

[Martin]

Hi Martin,

do you use the current version? Archiva 2.2.3?
There is a CSRF-prevention filter active. You have to add the URL of your 
nginx server to the rest.baseUrl field (you may set a comma separated list for 
multiple URLs).

See http://archiva.apache.org/docs/2.2.3/release-notes.html
Note: If your archiva installation is behind a reverse proxy or load balancer, 
it may be possible that the Archiva Web UI does not load after the upgrade. If 
this is the case you may access the WebUI via localhost or edit archiva.xml 
manually. In the "Redback Runtime Configuration" properties you have to enter 
the base URLs of your archiva installation to the rest.baseUrl field.

See  also:
http://archiva.apache.org/redback/integration/rest.html
http://archiva.apache.org/redback/
configuration.html#Cross_Site_Request_Forgery_CSRF_Prevention

If that does not work please create a JIRA ticket and provide detailed logging 
output.

Greetings

Martin

Am Samstag, 12. August 2017, 10:55:23 CEST schrieb Martin Pola:
> 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

Error 403 when proxying with Nginx

[Martin Pola]

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

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

[Martin Stockhammer]

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.

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

[Martin]

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

[SECURITY] CVE-2017-5657: Apache Archiva CSRF vulnerability for REST endpoints

[Martin]

CVE-2017-5657: Apache Archiva CSRF vulnerabilities for various REST endpoints

Severity: Important

Vendor:
The Apache Software Foundation

Versions Affected:
Archiva 2.0.0 - 2.2.1
The unsupported versions 1.x are also affected.  

Several REST service endpoints of Apache Archiva are not protected against 
Cross Site Request Forgery (CSRF) attacks. A malicious site opened in the same 
browser as the archiva site, may send HTML response that performs arbitrary 
actions on archiva services, with the same rights as the active archiva 
session (e.g. adminstrator rights).

Mitigation:
  All users are recommended to upgrade to Archiva 2.2.3 or higher, 
  where additional measures are taken to verify the origin of REST requests.

References:
http://archiva.apache.org/security.html#CVE-2017-5657

The newest Archiva version can be downloaded from:
http://archiva.apache.org/download.cgi

[ANN] Apache Archiva 2.2.3 Released

[Martin]

The Apache Archiva team is pleased to announce the release of 
   Archiva 2.2.3. 
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.3 is a bugs fix release.

Compatibility Changes:
This release contains new security features for the REST API. Depending on 
your hosting environment there may be additional configuration steps 
necessary.

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

Improvement

[MRM-1925] - Make User-Agent header configurable for HTTP requests
[MRM-1861], [MRM-1924] - Increasing timeouts for repository check
[MRM-1937] - Prevent creating initial admin user with wrong name.
Adding origin header validation checks for REST requests

Bugs fixed

[MRM-1859] - Error upon viewing 'Artifacts' tab when browsing an artifact
[MRM-1874] - Login Dialog triggers multiple events (+messages)
[MRM-1908] - Logged on users can write any repository
[MRM-1909] - Remote repository check fails for 
   https://repo.maven.apache.org/maven2
[MRM-1923] - Fixing bind issue with certain ldap servers, when user not
  found
[MRM-1926] - Invalid checksum files in Archiva repository after download
   from remote repository
[MRM-1928] - Bad redirect URL when using Archiva through HTTP reverse
   proxy
[MRM-1933] - No message body writer has been found for class
   
org.apache.archiva.rest.services.ArchivaRestError
[MRM-1940] - Slashes appended to remote repo url


Have fun! -- The Apache Archiva Team

Re: How to enforce SSL with trusted letsencrypt.org certificate in Apache Archiva standalone 2.2.1?

[Martin]

Hi,

you have to setup jetty for SSL, if you would like to use the standalone 
distribution. Or use a reverse proxy (apache httpd) in front of the server. 
Or a more lightweight SSL forwarder like stunnel. But currently, we have no 
out-of-the-box solution.
If you are more familiar with tomcat configuration, you may use the WAR file 
of archiva and deploy it on a tomcat server.

Greetings

Martin

Am Sonntag, 7. Mai 2017, 14:56:34 CEST schrieb Karl-Philipp Richter:
> Hi,
> I'd like to use/enforce SSL with a trusted letsencrypt.org certificate
> for an Apache Archiva standalone 2.2.1 instance on Ubuntu 17.04.
> 
> I didn't find any information in the Archiva website/documentation. [The
> setup for SSL usage on Jetty is
> painful](http://www.eclipse.org/jetty/documentation/current/configuring-ssl.
> html), so I want to make sure that it's necessary to go through it, that
> it's compatible with Archiva 2.2.1 (and possibly others) (no patched
> versions of Jetty in Archiva, etc.) and that there's no easier way. I came
> across
> http://stackoverflow.com/questions/30871001/how-to-setup-apache-archiva-to-> 
> use-https-instead-of-http and
> http://stackoverflow.com/questions/33229543/how-to-configure-ssl-with-archiv
> a which both suggest to use a httpd proxy which I don't want.
> 
> Don't hesitate answering on SO questions (if you support the
> format/closeness) since Q is much more constructive than mailing lists.
> 
> -Kalle

Re: archiva dependency graph/tree in snapshot repository not shown

[Martin]

Hi,

is there a pom-File in your snapshot repository (same path as jar)?
I did a simple test, and you may be right, that the dependency tree / graph 
may not work on the snapshot repository. Currently I'm not sure why.
Would you mind to open a ticket for this? Or if you have the time, you may
provide a pull request.

Greetings 

Martin

Am Donnerstag, 22. Dezember 2016, 12:28:58 CET schrieb Bachmair Florian - 
flexSolution GmbH:
> Hi!
> 
> Is there a way to view the dependency graph/tree for artifacts in the
> snapshot repository?
> If I deploy the same project to the release repository, the graph is
> shown right!
> 
> Should that be like that?

Re: Rebuilding the repository

[Martin]

Hi Marco,

unfortunately the BundleFsPersistenceManager has no option to run a 
consistency check during startup. With the current archiva I see no way to 
force a consistency check on the running repository.

If you use the standalone archiva, one way could be:
stop archiva
Backup /repositories
Remove /repositories completely
start archiva
Rescan Directories

I'm not sure, if this works and/or if this leads to other errors, but at least 
with a out of the box archiva standalone the repositories directory is rebuilt
after the restart.

Greetings

Martin


Am Montag, 10. Oktober 2016, 17:28:14 CEST schrieb m...@mherrn.de:
> Hello all,
> 
> I have now had the time to try to fix my problem.
> I have stopped archiva,
> then I have modified the archiva.xml to point the internal and snapshot
> repositories to totally different (empty) directories.
> Then I have started archiva up again.
> And did a directory scan for both repositories.
> However I still get lots of
> 
> 2016-10-10 17:23:48,401 [pool-6-thread-1] ERROR
> org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager
> [] - failed to read bundle: ed7c5e19-3418-4ab1-a810-a955469969d1:
> java.io.EOFException
> 
> message in the log file. And they don't stop. Archiva is writing them on
> and on..
> 
> Also when browing the web UI, I get the message
> 
> failed to retrieve item state of item
> 51a07434-8277-41a2-80ad-61d8415b8642
> 
> for the groupId I have snapshot versions of.
> 
> How can I get the database back into a consistent state?
> 
> 
> Best regards
> Marco
> 
> > Hi Olivier,
> > 
> > only some of them were deleted.
> > I will try to remove all of them and if this fixes the problem.
> > 
> > Best regards
> > Marco
> > 
> >> 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: Rebuilding the repository

[Martin Stockhammer]

Hi Marco,

a rescan (directories scanning action) does not help?


For 2: would be great if you can create a issue in the Jira. 

Greetings

Martin

Am 22. September 2016 17:13:55 MESZ, schrieb m...@mherrn.de:
>Hello,
>
>I see lots of problems in the archiva.log that the process cannot find
>some bundles:
>
>2016-09-22 17:08:02,435 [pool-6-thread-1] ERROR
>org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager
>[] - failed to read bundle: b9706fc7-846b-4dab-bac3-7a734136dbf8:
>java.io.EOFException
>2016-09-22 17:08:02,477 [pool-6-thread-1] ERROR
>org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager
>[] - failed to read bundle: b9706fc7-846b-4dab-bac3-7a734136dbf8:
>java.io.EOFException
>2016-09-22 17:08:02,528 [pool-6-thread-1] ERROR
>org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager
>[] - failed to read bundle: b9706fc7-846b-4dab-bac3-7a734136dbf8:
>java.io.EOFException
>2016-09-22 17:08:02,549 [pool-6-thread-1] ERROR
>org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager
>[] - failed to read bundle: 27c8fb7c-b9ef-4b6c-9b59-565d71f51ce5:
>java.io.EOFException
>
>
>I expect this happened because some files were removed directly in the
>filesystem.
>
>
>This leads to two questions:
>
>1. How can I recreate the whole repository from scratch? I tried
>configuring a different location in archiva.xml, but that lead to the
>same
>problems.
>
>2. How can archiva be made a bit more robust? Files or directories
>being
>deleted directly in the filesystem shouldn't confuse archiva that much
>that it doesn't really revive.
>
>Best regards
>Marco

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Archiva to Attic? Asking contribution

[Martin Stockhammer]

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/

Beginner needs help with Archiva

[Julien Martin]

Hello,
I am new to Archiva which I have successfully installed and I would like to
know how to add my local ~/.m2 repository to Archiva if that makes sense
at all.
Can anyone please help?
Thanks in advance,
Julien.

Re: WELCOME to users@archiva.apache.org

[Martin Schwarzbauer]

I tried this, this doesn't work for me!

2011/6/20 Brett Porter br...@apache.org

 The simplest is to remove the uniqueVersionfalse/uniqueVersion when you
 deploy so that the snapshots are deployed with a timestamp  build number.

 On 20/06/2011, at 2:57 PM, Martin Schwarzbauer wrote:

  Hello Brett,
 
  i am using the snapshot deploy repo for out deployment snapshot (still
  testing). I wanna deploy the snapshot and fetch these artifacts
  (XXX--0.1-SNAPSHOT.jar) as a dependency in another maven project. The
  problem is, that i can't fetch the SNAPSHOT version as a dependency from
 the
  repo! Why?
 
  How to handle this?
 
  Thx,
  Martin
 
  2011/6/20 Brett Porter br...@apache.org
 
  Sorry, I'm a bit unclear what you are trying to do here with the
 snapshot.
  Is it your objective to use a timestamp (in which case, you need to
 change
  the snapshotRepository in your distributionManagement), or to not use a
  timestamp (in which case, Maven 3 will not be able to deploy or retrieve
 the
  artifact)?
 
  I recommend using timestamps, and turning on Archiva's purge snapshots
  feature to better maintain disk space.
 
  - Brett
 
  On 17/06/2011, at 7:44 PM, Martin Schwarzbauer wrote:
 
  Hello the problem is still not fixed! Here again my setup:
 
  * maven 3.0.3
  * Archiva 1.3.3
 
  * Internal Proxy repo with further remote repos.
  * deploy and deploy_snapshot repo
  * these three repos are in ONE repository group (spr_internal)
 
  My settings.xml:
  mirror
  idinternal/id
  mirrorOf*/mirrorOf
  nameInternal Sprecher Automation Repository./name
  url
 
 http://febuild1.sprecher-automation.com/archiva/repository/spr_internal/
  /url
/mirror
 
  In pom.xml:
 
  distributionManagement
  repository
  iddeploy/id
  nameInternal Release Repository/name
  urlhttp://10.1.2.140/archiva/repository/deploy//url
  /repository
  snapshotRepository
uniqueVersionfalse/uniqueVersion
  iddeploy_snapshot/id
  nameInternal Snapshot Repository/name
  urlhttp://10.1.2.140/archiva/repository/deploy_snapshot/url
  /snapshotRepository
  /distributionManagement
 
  I can deploy this artifact (SNAPSHOT) into deploy_snapshot. In another
  project i use this SNAPSHOT-Version as dependency but maven can't fetch
  it
  from archiva repo. I think there is a problem with the timestamp in the
  SNAPSHOT repo? The tag uniqueVersionfalse/uniqueVersion
  doesn't work in Maven3!
 
  Can anybody help me?
 
  thx,
  Martin
 
 
  2011/6/14 Mohni, Daniel daniel.mo...@ch.unisys.com
 
  Hi Martin
 
  Questions 1: Is this url available in a web browser ?
 
 
 
 
 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/WebService-1.0-SNAPSHOT.pom
 
  Question 2: Did you add the snapshot repository to the 'internal'
  repository group ?
 
  Cheers
  Daniel
 
  -Ursprüngliche Nachricht-
  Von: Martin Schwarzbauer [mailto:martin.schwarzba...@gmail.com]
  Gesendet: Dienstag, 14. Juni 2011 09:55
  An: users@archiva.apache.org
  Betreff: Re: WELCOME to users@archiva.apache.org
 
  Hi *!
 
  I have got a problem using Archiva! The story is:
 
  I am using ARCHIVA to proxy all the remote repos.
 
  My Configuration is:
  Internal repository - proxies different remote repos.
  In my settings.xml i have:
  mirror
 idinternal/id
 mirrorOf*/mirrorOf
 nameInternal Sprecher Automation Repository./name
 urlhttp://febuild1/archiva/repository/internal//url
   /mirror
 
  so that all of me request will be handled by the proxy!
 
  I also created TWO repositories for deployment - deploy and
  deploy.snapshot.
 
  In my POM.xml i have:
  distributionManagement
  repository
  idarchiva.deploy/id
  nameInternal Release Repository/name
  urlhttp://10.1.2.140/archiva/repository/deploy//url
  /repository
  snapshotRepository
  idarchiva.deploy.snapshots/id
  nameInternal Snapshot Repository/name
  urlhttp://10.1.2.140/archiva/repository/deploy.snapshots/url
  /snapshotRepository
  /distributionManagement
 
  The different artifacts (*.jars, *.zip) get deployed correctly (either
  SNAPSHOT or not) !
 
  My Problem:
  I will use the deployed JAR as a dependency in another project - BUT
  this
  doesn't work for SNAPSHOTS!
 
  I always get:
  [...]
  Downloading:
 
 
 
 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
  Downloading:
 
 
 
 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
  Downloading:
 
 
 
 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/WebService-1.0-SNAPSHOT.pom
  [WARNING] The POM for
  at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT is missing,
 no
  dependency information available
  [...]
  [ERROR] Failed to execute goal on project SWTConfigTool: Could not
  resolve
  dependencies for project
  at.sprecher.web.swt.configtool:SWTConfigTool:jar:0.0.1-SNAPSHOT

Re: WELCOME to users@archiva.apache.org

[Martin Schwarzbauer]

Permissions seem to be correct. I can download the artifact via Browser or
wget!

2011/6/20 Brett Porter br...@apache.org

 All looks ok. I assume the 1.0-SNAPSHOT/maven-metadata.xml also looks
 correct and has the right timestamp and build number in it.

 Is it possible something more basic is not right here - like incorrect
 access permissions on the repository, or incorrect credentials on the maven
 end if you meant it to be restricted?

 - Brett

 On 20/06/2011, at 5:05 PM, Martin Schwarzbauer wrote:

  The directory in the repo looks like:
  .
  |-- 1.0-SNAPSHOT
  |   |-- WebBase-1.0-20110617.094951-1.jar
  |   |-- WebBase-1.0-20110617.094951-1.jar.md5
  |   |-- WebBase-1.0-20110617.094951-1.jar.sha1
  |   |-- WebBase-1.0-20110617.094951-1.pom
  |   |-- WebBase-1.0-20110617.094951-1.pom.md5
  |   |-- WebBase-1.0-20110617.094951-1.pom.sha1
  |   |-- WebBase-1.0-20110620.070104-2.jar
  |   |-- WebBase-1.0-20110620.070104-2.jar.md5
  |   |-- WebBase-1.0-20110620.070104-2.jar.sha1
  |   |-- WebBase-1.0-20110620.070104-2.pom
  |   |-- WebBase-1.0-20110620.070104-2.pom.md5
  |   |-- WebBase-1.0-20110620.070104-2.pom.sha1
  |   |-- maven-metadata.xml
  |   |-- maven-metadata.xml.md5
  |   `-- maven-metadata.xml.sha1
  |-- maven-metadata.xml
  |-- maven-metadata.xml.md5
  `-- maven-metadata.xml.sha1
 
 
  maven-metadata.xml:
  ?xml version=1.0 encoding=UTF-8?
  metadata
   groupIdat.sprecher.web.gwt.base/groupId
   artifactIdWebBase/artifactId
   versioning
 latest1.0-SNAPSHOT/latest
 versions
   version1.0-SNAPSHOT/version
 /versions
 lastUpdated20110620070104/lastUpdated
   /versioning
  /metadata
 
  The other project (dependency to WebBase):
  dependency
 groupIdat.sprecher.web.gwt.base/groupId
 artifactIdWebBase/artifactId
 version1.0-SNAPSHOT/version
 /dependency
 
  I removed the local ~/.m2 folder, because the deploy also install the
  artifact on the disk and dependency resolution works :-)
 
  Error:
  [...]
  [DEBUG] Could not find metadata
  at.sprecher.web.gwt.base:WebBase:1.0-SNAPSHOT/maven-metadata.xml in local
  (/home/schwarzi/.m2/repository)
  [DEBUG] Could not find metadata
  at.sprecher.web.gwt.base:WebBase:1.0-SNAPSHOT/maven-metadata.xml in local
  (/home/schwarzi/.m2/repository)
  [WARNING] The POM for at.sprecher.web.gwt.base:WebBase:jar:1.0-SNAPSHOT
 is
  missing, no dependency information available
  [...]
  [INFO]
  
  [INFO] BUILD FAILURE
  [INFO]
  
  [INFO] Total time: 14.101s
  [INFO] Finished at: Mon Jun 20 09:04:28 CEST 2011
  [INFO] Final Memory: 2M/52M
  [INFO]
  
  [ERROR] Failed to execute goal on project WebModules: Could not resolve
  dependencies for project
  at.sprecher.web.gwt.modules:WebModules:jar:1.0-SNAPSHOT: Could not find
  artifact at.sprecher.web.gwt.base:WebBase:jar:1.0-SNAPSHOT - [Help 1]
  org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
  goal on project WebModules: Could not resolve dependencies for project
  at.sprecher.web.gwt.modules:WebModules:jar:1.0-SNAPSHOT: Could not find
  artifact at.sprecher.web.gwt.base:WebBase:jar:1.0-SNAPSHOT
  at
 
 org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:196)
  at
 
 org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:108)
  at
 
 org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
  at
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
  at
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
  at
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
  at
 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
  at
 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
  at
 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
  at
 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
  at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
  at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
  at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke

Re: WELCOME to users@archiva.apache.org

[Martin Schwarzbauer]

Hi Wendy,
no i don't have any other settings in the settings.xml (except a HTTP
Proxy).

What's missing?

Martin

2011/6/20 Wendy Smoak wsm...@gmail.com

 On Fri, Jun 17, 2011 at 5:44 AM, Martin Schwarzbauer
 martin.schwarzba...@gmail.com wrote:
 
  My settings.xml:
   mirror
   idinternal/id
   mirrorOf*/mirrorOf
   nameInternal Sprecher Automation Repository./name
   url
  http://febuild1.sprecher-automation.com/archiva/repository/spr_internal/
  /url
 /mirror

 Do you have anything else in settings.xml?  By default Maven doesn't
 have any repositories defined with snapshots enabled, so it won't
 retrieve any snapshots at all.

 --
 Wendy

Re: WELCOME to users@archiva.apache.org

[Martin Schwarzbauer]

Hello Brett,

i am using the snapshot deploy repo for out deployment snapshot (still
testing). I wanna deploy the snapshot and fetch these artifacts
(XXX--0.1-SNAPSHOT.jar) as a dependency in another maven project. The
problem is, that i can't fetch the SNAPSHOT version as a dependency from the
repo! Why?

How to handle this?

Thx,
Martin

2011/6/20 Brett Porter br...@apache.org

 Sorry, I'm a bit unclear what you are trying to do here with the snapshot.
 Is it your objective to use a timestamp (in which case, you need to change
 the snapshotRepository in your distributionManagement), or to not use a
 timestamp (in which case, Maven 3 will not be able to deploy or retrieve the
 artifact)?

 I recommend using timestamps, and turning on Archiva's purge snapshots
 feature to better maintain disk space.

 - Brett

 On 17/06/2011, at 7:44 PM, Martin Schwarzbauer wrote:

  Hello the problem is still not fixed! Here again my setup:
 
  * maven 3.0.3
  * Archiva 1.3.3
 
  * Internal Proxy repo with further remote repos.
  * deploy and deploy_snapshot repo
  * these three repos are in ONE repository group (spr_internal)
 
  My settings.xml:
  mirror
   idinternal/id
   mirrorOf*/mirrorOf
   nameInternal Sprecher Automation Repository./name
   url
  http://febuild1.sprecher-automation.com/archiva/repository/spr_internal/
  /url
 /mirror
 
  In pom.xml:
 
  distributionManagement
  repository
  iddeploy/id
  nameInternal Release Repository/name
  urlhttp://10.1.2.140/archiva/repository/deploy//url
  /repository
  snapshotRepository
 uniqueVersionfalse/uniqueVersion
  iddeploy_snapshot/id
  nameInternal Snapshot Repository/name
  urlhttp://10.1.2.140/archiva/repository/deploy_snapshot/url
  /snapshotRepository
  /distributionManagement
 
  I can deploy this artifact (SNAPSHOT) into deploy_snapshot. In another
  project i use this SNAPSHOT-Version as dependency but maven can't fetch
 it
  from archiva repo. I think there is a problem with the timestamp in the
  SNAPSHOT repo? The tag uniqueVersionfalse/uniqueVersion
  doesn't work in Maven3!
 
  Can anybody help me?
 
  thx,
  Martin
 
 
  2011/6/14 Mohni, Daniel daniel.mo...@ch.unisys.com
 
  Hi Martin
 
  Questions 1: Is this url available in a web browser ?
 
 
 
 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/WebService-1.0-SNAPSHOT.pom
 
  Question 2: Did you add the snapshot repository to the 'internal'
  repository group ?
 
  Cheers
  Daniel
 
  -Ursprüngliche Nachricht-
  Von: Martin Schwarzbauer [mailto:martin.schwarzba...@gmail.com]
  Gesendet: Dienstag, 14. Juni 2011 09:55
  An: users@archiva.apache.org
  Betreff: Re: WELCOME to users@archiva.apache.org
 
  Hi *!
 
  I have got a problem using Archiva! The story is:
 
  I am using ARCHIVA to proxy all the remote repos.
 
  My Configuration is:
  Internal repository - proxies different remote repos.
  In my settings.xml i have:
  mirror
  idinternal/id
  mirrorOf*/mirrorOf
  nameInternal Sprecher Automation Repository./name
  urlhttp://febuild1/archiva/repository/internal//url
/mirror
 
  so that all of me request will be handled by the proxy!
 
  I also created TWO repositories for deployment - deploy and
  deploy.snapshot.
 
  In my POM.xml i have:
  distributionManagement
  repository
  idarchiva.deploy/id
  nameInternal Release Repository/name
  urlhttp://10.1.2.140/archiva/repository/deploy//url
  /repository
  snapshotRepository
  idarchiva.deploy.snapshots/id
  nameInternal Snapshot Repository/name
  urlhttp://10.1.2.140/archiva/repository/deploy.snapshots/url
  /snapshotRepository
  /distributionManagement
 
  The different artifacts (*.jars, *.zip) get deployed correctly (either
  SNAPSHOT or not) !
 
  My Problem:
  I will use the deployed JAR as a dependency in another project - BUT
 this
  doesn't work for SNAPSHOTS!
 
  I always get:
  [...]
  Downloading:
 
 
 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
  Downloading:
 
 
 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
  Downloading:
 
 
 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/WebService-1.0-SNAPSHOT.pom
  [WARNING] The POM for
  at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT is missing, no
  dependency information available
  [...]
  [ERROR] Failed to execute goal on project SWTConfigTool: Could not
 resolve
  dependencies for project
  at.sprecher.web.swt.configtool:SWTConfigTool:jar:0.0.1-SNAPSHOT: The
  following artifacts could not be resolved:
  at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT,
  at.sprecher.web.gwt.config:GWTConfigTool:war:0.0.1-SNAPSHOT,
  at.sprecher.web.gwt.base:WebBase:jar:1.0-SNAPSHOT: Could not find
 artifact
  at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT in internal (
  http://febuild1

Re: WELCOME to users@archiva.apache.org

[Martin Schwarzbauer]

Hello the problem is still not fixed! Here again my setup:

* maven 3.0.3
* Archiva 1.3.3

* Internal Proxy repo with further remote repos.
* deploy and deploy_snapshot repo
* these three repos are in ONE repository group (spr_internal)

My settings.xml:
 mirror
  idinternal/id
  mirrorOf*/mirrorOf
  nameInternal Sprecher Automation Repository./name
  url
http://febuild1.sprecher-automation.com/archiva/repository/spr_internal/
/url
/mirror

In pom.xml:

distributionManagement
repository
iddeploy/id
nameInternal Release Repository/name
urlhttp://10.1.2.140/archiva/repository/deploy//url
/repository
snapshotRepository
uniqueVersionfalse/uniqueVersion
iddeploy_snapshot/id
nameInternal Snapshot Repository/name
urlhttp://10.1.2.140/archiva/repository/deploy_snapshot/url
/snapshotRepository
/distributionManagement

I can deploy this artifact (SNAPSHOT) into deploy_snapshot. In another
project i use this SNAPSHOT-Version as dependency but maven can't fetch it
from archiva repo. I think there is a problem with the timestamp in the
SNAPSHOT repo? The tag uniqueVersionfalse/uniqueVersion
doesn't work in Maven3!

Can anybody help me?

thx,
Martin


2011/6/14 Mohni, Daniel daniel.mo...@ch.unisys.com

 Hi Martin

 Questions 1: Is this url available in a web browser ?


 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/WebService-1.0-SNAPSHOT.pom

 Question 2: Did you add the snapshot repository to the 'internal'
 repository group ?

 Cheers
 Daniel

 -Ursprüngliche Nachricht-
 Von: Martin Schwarzbauer [mailto:martin.schwarzba...@gmail.com]
 Gesendet: Dienstag, 14. Juni 2011 09:55
 An: users@archiva.apache.org
 Betreff: Re: WELCOME to users@archiva.apache.org

 Hi *!

 I have got a problem using Archiva! The story is:

 I am using ARCHIVA to proxy all the remote repos.

 My Configuration is:
 Internal repository - proxies different remote repos.
 In my settings.xml i have:
 mirror
  idinternal/id
  mirrorOf*/mirrorOf
  nameInternal Sprecher Automation Repository./name
  urlhttp://febuild1/archiva/repository/internal//url
/mirror

 so that all of me request will be handled by the proxy!

 I also created TWO repositories for deployment - deploy and
 deploy.snapshot.

 In my POM.xml i have:
 distributionManagement
 repository
 idarchiva.deploy/id
 nameInternal Release Repository/name
 urlhttp://10.1.2.140/archiva/repository/deploy//url
 /repository
 snapshotRepository
 idarchiva.deploy.snapshots/id
 nameInternal Snapshot Repository/name
 urlhttp://10.1.2.140/archiva/repository/deploy.snapshots/url
 /snapshotRepository
 /distributionManagement

 The different artifacts (*.jars, *.zip) get deployed correctly (either
 SNAPSHOT or not) !

 My Problem:
 I will use the deployed JAR as a dependency in another project - BUT this
 doesn't work for SNAPSHOTS!

 I always get:
 [...]
 Downloading:

 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
 Downloading:

 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
 Downloading:

 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/WebService-1.0-SNAPSHOT.pom
 [WARNING] The POM for
 at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT is missing, no
 dependency information available
 [...]
 [ERROR] Failed to execute goal on project SWTConfigTool: Could not resolve
 dependencies for project
 at.sprecher.web.swt.configtool:SWTConfigTool:jar:0.0.1-SNAPSHOT: The
 following artifacts could not be resolved:
 at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT,
 at.sprecher.web.gwt.config:GWTConfigTool:war:0.0.1-SNAPSHOT,
 at.sprecher.web.gwt.base:WebBase:jar:1.0-SNAPSHOT: Could not find artifact
 at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT in internal (
 http://febuild1/archiva/repository/internal/) - [Help 1]
 [...]


 Any ideas how to use SNAPSHOT artifact from the deploy.snapshots repository
 from Archiva?

 Thx in advance,
 Martin

Re: WELCOME to users@archiva.apache.org

[Martin Schwarzbauer]

Hi *!

I have got a problem using Archiva! The story is:

I am using ARCHIVA to proxy all the remote repos.

My Configuration is:
Internal repository - proxies different remote repos.
In my settings.xml i have:
mirror
  idinternal/id
  mirrorOf*/mirrorOf
  nameInternal Sprecher Automation Repository./name
  urlhttp://febuild1/archiva/repository/internal//url
/mirror

so that all of me request will be handled by the proxy!

I also created TWO repositories for deployment - deploy and
deploy.snapshot.

In my POM.xml i have:
distributionManagement
repository
idarchiva.deploy/id
nameInternal Release Repository/name
urlhttp://10.1.2.140/archiva/repository/deploy//url
/repository
snapshotRepository
idarchiva.deploy.snapshots/id
nameInternal Snapshot Repository/name
urlhttp://10.1.2.140/archiva/repository/deploy.snapshots/url
/snapshotRepository
/distributionManagement

The different artifacts (*.jars, *.zip) get deployed correctly (either
SNAPSHOT or not) !

My Problem:
I will use the deployed JAR as a dependency in another project - BUT this
doesn't work for SNAPSHOTS!

I always get:
[...]
Downloading:
http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
Downloading:
http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
Downloading:
http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/WebService-1.0-SNAPSHOT.pom
[WARNING] The POM for
at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT is missing, no
dependency information available
[...]
[ERROR] Failed to execute goal on project SWTConfigTool: Could not resolve
dependencies for project
at.sprecher.web.swt.configtool:SWTConfigTool:jar:0.0.1-SNAPSHOT: The
following artifacts could not be resolved:
at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT,
at.sprecher.web.gwt.config:GWTConfigTool:war:0.0.1-SNAPSHOT,
at.sprecher.web.gwt.base:WebBase:jar:1.0-SNAPSHOT: Could not find artifact
at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT in internal (
http://febuild1/archiva/repository/internal/) - [Help 1]
[...]


Any ideas how to use SNAPSHOT artifact from the deploy.snapshots repository
from Archiva?

Thx in advance,
Martin

Re: WELCOME to users@archiva.apache.org

[Martin Schwarzbauer]

Hi Daniel!

No the URL is not available in browser.
I have tried to add the internal deploy.snapshot repo as a proxy connector
to the internal repo - this doesn't work too!

Martin


2011/6/14 Mohni, Daniel daniel.mo...@ch.unisys.com

 Hi Martin

 Questions 1: Is this url available in a web browser ?


 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/WebService-1.0-SNAPSHOT.pom

 Question 2: Did you add the snapshot repository to the 'internal'
 repository group ?

 Cheers
 Daniel

 -Ursprüngliche Nachricht-
 Von: Martin Schwarzbauer [mailto:martin.schwarzba...@gmail.com]
 Gesendet: Dienstag, 14. Juni 2011 09:55
 An: users@archiva.apache.org
 Betreff: Re: WELCOME to users@archiva.apache.org

 Hi *!

 I have got a problem using Archiva! The story is:

 I am using ARCHIVA to proxy all the remote repos.

 My Configuration is:
 Internal repository - proxies different remote repos.
 In my settings.xml i have:
 mirror
  idinternal/id
  mirrorOf*/mirrorOf
  nameInternal Sprecher Automation Repository./name
  urlhttp://febuild1/archiva/repository/internal//url
/mirror

 so that all of me request will be handled by the proxy!

 I also created TWO repositories for deployment - deploy and
 deploy.snapshot.

 In my POM.xml i have:
 distributionManagement
 repository
 idarchiva.deploy/id
 nameInternal Release Repository/name
 urlhttp://10.1.2.140/archiva/repository/deploy//url
 /repository
 snapshotRepository
 idarchiva.deploy.snapshots/id
 nameInternal Snapshot Repository/name
 urlhttp://10.1.2.140/archiva/repository/deploy.snapshots/url
 /snapshotRepository
 /distributionManagement

 The different artifacts (*.jars, *.zip) get deployed correctly (either
 SNAPSHOT or not) !

 My Problem:
 I will use the deployed JAR as a dependency in another project - BUT this
 doesn't work for SNAPSHOTS!

 I always get:
 [...]
 Downloading:

 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
 Downloading:

 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/maven-metadata.xml
 Downloading:

 http://febuild1/archiva/repository/internal/at/sprecher/web/rest/service/WebService/1.0-SNAPSHOT/WebService-1.0-SNAPSHOT.pom
 [WARNING] The POM for
 at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT is missing, no
 dependency information available
 [...]
 [ERROR] Failed to execute goal on project SWTConfigTool: Could not resolve
 dependencies for project
 at.sprecher.web.swt.configtool:SWTConfigTool:jar:0.0.1-SNAPSHOT: The
 following artifacts could not be resolved:
 at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT,
 at.sprecher.web.gwt.config:GWTConfigTool:war:0.0.1-SNAPSHOT,
 at.sprecher.web.gwt.base:WebBase:jar:1.0-SNAPSHOT: Could not find artifact
 at.sprecher.web.rest.service:WebService:jar:1.0-SNAPSHOT in internal (
 http://febuild1/archiva/repository/internal/) - [Help 1]
 [...]


 Any ideas how to use SNAPSHOT artifact from the deploy.snapshots repository
 from Archiva?

 Thx in advance,
 Martin

archiva consumer test cases

[martin . goldhahn]

Hi!
Im trying to implement an Archiva consumer, but I have trouble with 
implementing a test case.
There is an archiva-consumer-plugin-archetype that creates a simple 
consumer.

When I run the test case in Eclipse I get this stack trace:
java.lang.VerifyError: Cannot inherit from final class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at 
org.codehaus.plexus.component.discovery.PlexusXmlComponentDiscoverer.discoverConfiguration(PlexusXmlComponentDiscoverer.java:105)
at 
org.codehaus.plexus.DefaultPlexusContainer.initializeConfiguration(DefaultPlexusContainer.java:710)
at 
org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:520)
at 
org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:277)
at 
org.codehaus.plexus.DefaultPlexusContainer.init(DefaultPlexusContainer.java:168)
at 
org.codehaus.plexus.PlexusTestCase.setupContainer(PlexusTestCase.java:100)
at 
org.codehaus.plexus.PlexusTestCase.getContainer(PlexusTestCase.java:143)
at 
org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:204)
at 
no.uis.archiva.consumer.SimpleArtifactConsumerTest.setUp(SimpleArtifactConsumerTest.java:50)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at 
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

I think the same happens with the archiva-consumer-plugin in the sandbox. 
What am I missing here?

Cheers
Martin