Archiva

Appearance Actions do not work when ${user.home} is invalid.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.0-beta-2
  • Fix Version/s: 1.1
  • Component/s: system
  • Labels:
    None
  • Number of attachments :
    0

Description

The reliance on maven core components with regards to Appearance / Company Info / Edit Pom actions, prevents server installations without a valid user $HOME directory. ( such as /dev/null )

We should migrate away from maven core components at our earliest opportunity.

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MRM-553 removing conf/shared.xml from plexus runtime causes save appearance to fail

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is superceded by

Improvement - An improvement or enhancement to an existing feature or task. MRM-829 Replace Company POM feature with simple Appearence customisation

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

not critical.

it's just a local repository assumption (we should instead pass in a repository to store in) - there are other points in archiva that use user.home and would be similarly affected

Show
Brett Porter added a comment - not critical. it's just a local repository assumption (we should instead pass in a repository to store in) - there are other points in archiva that use user.home and would be similarly affected
Hide
Permalink
Brett Porter added a comment -

a related issue is the creation of ~/.m2/archiva directory for a single metadata file during this process.

Show
Brett Porter added a comment - a related issue is the creation of ~/.m2/archiva directory for a single metadata file during this process.
Hide
Permalink
Joakim Erdfelt added a comment -

Actually, no.

We have mitigated all other $

{user.home}

situations.
And we have 2 known users now that run Archiva on a Unix environment with a homeless user (a common security practice).

Show
Joakim Erdfelt added a comment - Actually, no. We have mitigated all other $ {user.home} situations. And we have 2 known users now that run Archiva on a Unix environment with a homeless user (a common security practice).
Hide
Permalink
Brett Porter added a comment -

no to "not critical", or no to the creation of ~/.m2/archiva (which I still see)?

Does the server fail to start, or do the appearance actions just not work (I couldn't get a failure other than to try and edit the logo)?

Show
Brett Porter added a comment - no to "not critical", or no to the creation of ~/.m2/archiva (which I still see)? Does the server fail to start, or do the appearance actions just not work (I couldn't get a failure other than to try and edit the logo)?
Hide
Permalink
Joakim Erdfelt added a comment -

The creation of $HOME/.m2/archiva is a result of reliance on the maven core components, and should be filed as a separate bug.

This wasn't filed as critical, just major.

If someone decides to enter the appearance screens, as they are now, that whole process fails.
Once the appearance screens have been activated, then the logs fill up ridiculously fast with the exceptions, all tracked down to the appearance / logo logic attempting to resolve content, on every access to every screen in the application.

This is a severe problem.
We must address it.
Maybe not for the next pre-1.0 release, but definitely before 1.0 final.

Show
Joakim Erdfelt added a comment - The creation of $HOME/.m2/archiva is a result of reliance on the maven core components, and should be filed as a separate bug. This wasn't filed as critical, just major. If someone decides to enter the appearance screens, as they are now, that whole process fails. Once the appearance screens have been activated, then the logs fill up ridiculously fast with the exceptions, all tracked down to the appearance / logo logic attempting to resolve content, on every access to every screen in the application. This is a severe problem. We must address it. Maybe not for the next pre-1.0 release, but definitely before 1.0 final.
Hide
Permalink
Brett Porter added a comment -

suggested workaround to avoid the log spam: set -Duser.home in the wrapper (or HOME in the env) before running to an effectively-homeless but writeable location (eg /tmp/archiva-home) - the account can still have no real home, this is just to tell Java where to treat $HOME.

Will fix this properly in 1.x - I would suggest:

  • sourcing from the managed repositories instead of remote
  • proxying if necessary
  • not needing a local repository
  • when saving a new POM, allow selection of the managed repository to store to

This makes the actions more specific to Archiva, so might need to come up with something easier to work with there so we don't diverge from what is used in Continuum.

Show
Brett Porter added a comment - suggested workaround to avoid the log spam: set -Duser.home in the wrapper (or HOME in the env) before running to an effectively-homeless but writeable location (eg /tmp/archiva-home) - the account can still have no real home, this is just to tell Java where to treat $HOME. Will fix this properly in 1.x - I would suggest: sourcing from the managed repositories instead of remote proxying if necessary not needing a local repository when saving a new POM, allow selection of the managed repository to store to This makes the actions more specific to Archiva, so might need to come up with something easier to work with there so we don't diverge from what is used in Continuum.
Hide
Permalink
James William Dumay added a comment -

Move to 1.1.x

Show
James William Dumay added a comment - Move to 1.1.x
Hide
Permalink
James William Dumay added a comment -

Moving to 1.2

Show
James William Dumay added a comment - Moving to 1.2

People

  • Assignee:
    James William Dumay
    Reporter:
    Joakim Erdfelt
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: