The following warning can be seen in the strongbox-storage-maven-layout-provider:

[INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ strongbox-storage-maven-layout-provider ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 55 source files to /java/opensource/carlspring/strongbox/strongbox-storage/strongbox-storage-layout-providers/strongbox-storage-maven-layout-provider/target/classes
[INFO] /java/opensource/carlspring/strongbox/strongbox-storage/strongbox-storage-layout-providers/strongbox-storage-maven-layout-provider/src/main/java/org/carlspring/strongbox/storage/indexing/RepositoryIndexer.java: /java/opensource/carlspring/strongbox/strongbox-storage/strongbox-storage-layout-providers/strongbox-storage-maven-layout-provider/src/main/java/org/carlspring/strongbox/storage/indexing/RepositoryIndexer.java uses or overrides a deprecated API.
[INFO] /java/opensource/carlspring/strongbox/strongbox-storage/strongbox-storage-layout-providers/strongbox-storage-maven-layout-provider/src/main/java/org/carlspring/strongbox/storage/indexing/RepositoryIndexer.java: Recompile with -Xlint:deprecation for details.
[INFO] -------------------------------------------------------------

This needs to be investigated and resolved.

Task Description

In continuation of the work done or Maven artifact coordinate validators (#365 and #366, work done by @dinesh19aug) and in relation to #332, we should make it possible to define additional artifact coordinate validators. The ones implemented in #332 (by @fuss86) only cover version validation and artifact deployment/redeployment.

We now need to somehow be able to specify these non-default validators.

As a consequence of this work, we may have to do some refactoring. (This could be done in a follow-up issue as well).

This should be configurable via the strongbox.yaml file.

Task Relationships

This task:

• Is a follow-up of: #365 , #366
• Relates to: #332

Help

• Our chat
• Points of contact:
  • @carlspring
  • @sbespalov
  • @fuss86

The Maven 2.0 layout provider uses the Maven Indexer, in addition to OrientDB as it's place for storing useful information about the artifacts.

We need to be able to keep a record of the checksum files in the local Maven Index.

What needs to be done:

• Make sure that checksums are added to the Lucene (Maven Indexer) local index
• Make it possible to use the MavenIndexerSearchProvider to search by class
• Implement test cases
  • Generate a test jar with an md5 and sha checksum (via your tests)
  • Add the artifact and checksums to the Maven Indexer local index
  • Execute a search by checksum against the local Maven Indexer and assert there are results which match the criteria

The code for this will have to be placed under the strongbox/strongbox-storage/strongbox-storage-providers/strongbox-maven-layout-provider module.

Notes:

• Don't add checksums for maven-metadata.xml files

See also:

• Searching
• Artifact Coordinates
• Maven Metadata
• Maven Indexer:
  • Strongbox: Maven Indexer
  • Apache Maven Indexer sources
• MavenArtifactGenerator
• TestCaseWithMavenArtifactGeneration

This issue is similar to #427.

Similarly to #446 and #464, we need to implement directory browsing for repositories with NuGet layouts. This is currently only implemented for repositories with Maven layouts.

Description

We need a new Spring controller to be implemented that returns a JSON representation of the contents of a path.

• The controller should:
  • Be called BrowsingController
  • Be placed in the strongbox-web-core under the org.carlspring.strongbox.controllers
• The web resource path should be /browse/{storageId}/{repository}/{path}.
• The returned results must be sorted

Examples

Listing all the storages

curl -H "Accept: application/json" -X GET http://localhost:48080/browse/

Expected JSON response

{
    'storages': [
      'storage0',
      'storage1',
      'storage2'
      ....
    ]
}

Listing all the repositories in storage

curl -H "Accept: application/json" -X GET http://localhost:48080/browse/storage0/

Expected JSON response

{
    'repositories': [
      'releases',
      'snapshots',
      ....
    ]
}

Listing the contents of a repository

curl -H "Accept: application/json" -X GET http://localhost:48080/browse/storage0/releases/

Expected JSON response

{
    'directories': [
        // any directories found in /storage0/releases/* (depth level 1) without trailing slash
        // if none are found, this should be an empty array.
        'com',
        'org',
        ....
    ],
    'files': [
        // and any files in /storage0/releases/* (depth level 1)
        // if none are found, this should be an empty array.
        'maven-metadata.xml',
        'maven-metadata.xml.md5',
        'maven-metadata.xml.sha1',
        ...
    ]
}

Listing the contents of a path in a repository

curl -H "Accept: application/json" -X GET http://localhost:48080/browse/storage0/releases/org/apache/maven/

Expected JSON response:

{
    'directories': [
        // any directories found in /storage0/releases/org/apache/maven/* (depth level 1) without trailing slash
        // if none are found, this should be an empty array.
        '3.5.1',
        '3.5.2',
        '3.5.3',
        ....
    ],
    'files': [
        // and any files in /storage0/releases/org/apache/maven/* (depth level 1)
        // if none are found, this should be an empty array.
        'maven-metadata.xml',
        'maven-metadata.xml.md5',
        'maven-metadata.xml.sha1',
        ...
    ]
}

• Replace the implementation="file-system" with data-store="file-system".
• Replace the org.carlspring.strongbox.providers.storage with org.carlspring.strongbox.providers.datastore.

We need to be able to respond to HTTP HEAD requests issued against the org.carlspring.strongbox.controllers.maven.MavenArtifactController and org.carlspring.strongbox.controllers.nuget.NugetPackageController classes.

This task should only cover the implementation for HEAD requests against proxy repositories.

Possible headers to return:

• Content-Length
• Checksum-MD5
• Checksum-SHA1
• Creation-Date
• Last-Updated

This following needs to be implement:

• If the artifact is cached, get the date from the cache
• If the artifact needs to be resolved from the remote, download it first and then send the HEAD response

Also, as suggested by @fuss86, we need to add the same headers to the GET requests.

This task is similar to #372 .

Task Description

We need to improve our documentation for all of the etc/conf/strongbox*xml files, as it's very basic. We could use some more examples for different configurations.

Some of the configuration files are not even partially documented (like, for example, the etc/conf/strongbox-authorization.xml file).

Help

• Our chat
• Points of contact:
  • @carlspring
  • @sbespalov
  • @steve-todorov

We need to be able to respond to HTTP HEAD requests issued against the org.carlspring.strongbox.controllers.maven.MavenArtifactController and org.carlspring.strongbox.controllers.nuget.NugetPackageController classes.

This task should only cover the implementation for HEAD requests against hosted repositories.

Possible headers to return:

• Content-Length
• Checksum-MD5
• Checksum-SHA1
• Creation-Date
• Last-Updated

Also, as suggested by @fuss86, we need to add the same headers to the GET requests.

This task relates to #471 and #472.

We need to upgrade to the latest version of Jetty.

Make sure that:

• The project still builds
• The tests are still passing

The version is controlled via the strongbox-parent/pom.xml.

The webapp can be executed using:

mvn clean install
cd strongbox-web-core
mvn clean package -Pjetty-block

If Jetty is starting the webapp correctly, then things should be alright. To test things, try accessing:
http://localhost:48080/configuration/strongbox/xml with admin/password -- an XML with the configuration of the server should be presented, upon successful login.

We need to add integration tests (in the strongbox-web-integration-tests project) that resolve and deploy artifacts using Gradle.

There's a "Hello, World!" application that we've already created for illustrating how to configure Gradle to work with Strongbox.

The tests should be invoked in a similar way to how they're currently being invoked for NuGet -- using Groovy scripts. There should be a Maven profile similar to the one for NuGet (check the one with<id>run-nuget-it-tests</id> for an example).

The test case must cover at least the following:

• Resolve dependencies
• Deploy an artifact

Please, note that the work for this will have to be done in a different project -- strongbox-web-integration-tests.

This issue relates to #432 and #430.

We need to upgrade to the latest version of quartz.

Make sure that:

• The project still builds
• The tests are still passing

The version is controlled via the strongbox-parent/pom.xml.

The cron task tests which use Quartz can be executed using:

mvn clean install -Dintegration.tests

These must all be passing successfully. For more information on the cron tasks, check here.

Preface
Similar to #418

Steps to reproduce

1. Compile the project (https://github.com/strongbox/strongbox/wiki/Building-the-code#building)
2. Run jetty server (https://github.com/strongbox/strongbox/wiki/Building-the-code#running-jetty-in-blocked-mode)
3. Visit for example http://localhost:48080/storages/storage-common-proxies/maven-central/pl/fuss/mummy.jar

Problem
See StackTrace at https://gist.github.com/fuss86/6dc5a586064d0224042e1ca947c42cde

Expected result
404 HTTP response

The port management code located in org.carlspring.strongbox.controllers.ConfigurationManagementController is not exactly working as expected. We need to have the following changes made:

1. GET /configuration/strongbox/port - needs to return in JSON the following output:

   {
       "port": 12345 // or whatever the actual port is
   }
   

2. PUT /configuration/strongbox/port - (new endpoint) which should require the following JSON body to be submitted:

   {
       "port": 48081 // or whatever the new port is
   }
   

3. PUT /configuration/strongbox/port/{port} - has to respond with Status 200 and plain text body OK when the operation has been successful and Status 500 and plain text body FAILED if something has gone wrong. This will make the life of people using scripts a lot easier than having to actually parse the response of curl and monitor the status code.

We need to add integration tests (in the strongbox-web-integration-tests project) that resolve and deploy artifacts using NPM.

There's a "Hello, World!" application that we've already created for illustrating how to configure NPM to work with Strongbox.

The tests should be invoked in a similar way to how they're currently being invoked for NuGet -- using Groovy scripts. There should be a Maven profile similar to the one for NuGet (check the one with<id>run-nuget-it-tests</id> for an example).

The test case must cover at least the following:

• Resolve dependencies
• Deploy an artifact

We need something along the same lines implemented for NPM.

Please, note that the work for this will have to be done in a different project -- strongbox-web-integration-tests.

This issue relates to #430, #431 and #432.

At the moment, the logic for this exists only in the MavenArtifactController. The code for this needs to be extracted into the BaseArtifactController and made more re-usable. The respective layout provider implementations of the controllers should then use these methods as required, to avoid duplication.

This task is similar to #446.

The maven indexes are currently being downloaded to the java.io.tmpdir. This is incorrect. Each repository has a .temp directory in it's base directory. If all of the indexes that have been downloaded temporarily to the java.io.tmpdir are all just spewed there, it becomes a mess and it's hard to figure out which of them belongs to which repository.

Once the remote index has been downloaded and updates/merged, these temporary files should probably be removed from the .temp directory.

Task Description

Gather the list of requirements here and produce a wiki page with them.

You will need to create a PR in the strongbox-docs repository. Please add this as a page under the User Guide.

Help

• Our chat
• Points of contact:
  • @carlspring
  • @sbespalov
  • @fuss86
  • @steve-todorov

It would be great to have this set up, so that our dependencies could be kept clean.

This will also involve cleaning up any currently existing diamond dependencies.

For more details on how this can be done, check here.

Similar to
#418 and #419

Steps to reproduce

1. Compile the project (https://github.com/strongbox/strongbox/wiki/Building-the-code#building)
2. Run jetty server (https://github.com/strongbox/strongbox/wiki/Building-the-code#running-jetty-in-blocked-mode)
3. Visit 2 locations one by one:

• http://localhost:48080/storages/storage-common-proxies/maven-central/org/carlspring/maven/derby-maven-plugin/1.8/derby-maven-plugin-1.8.jar
• http://localhost:48080/storages/storage-common-proxies/maven-central/org/carlspring/maven/derby-maven-plugin/1.8/derby-maven-plugin-5.0.jar

Problem
See StackTrace at https://gist.github.com/fuss86/6bc6b1071b452588075a31776e044317

Expected result
404 HTTP response

Refactor org.carlspring.strongbox.controllers.users.UserController (located in strongbox-web-core) so that it returns JSON messages upon successful/failed actions with the appropriate messages as follows:

1. If an action is successful we need to return the following JSON:

   {
       "message": "User successfully updated / deleted / etc"
   }
   

2. If the action has failed we need to return an error message that describes what's wrong:

   {
       "message": "A user with this username already exists! Please enter another username. / etc"
   }
   

This validator should be applicable for Maven repositories. It should check that the groupId component of the path is lowercase.

For more information, check the strongbox-storage-api module under the org.carlspring.strongbox.storage.validation package.

This task is similar to #365.

Steps to reproduce

1. Compile the project (https://github.com/strongbox/strongbox/wiki/Building-the-code#building)
2. Run jetty server (https://github.com/strongbox/strongbox/wiki/Building-the-code#running-jetty-in-blocked-mode)
3. Visit for example http://localhost:48080/storages/storage-common-proxies/maven-central/pl/fuss/

Problem
See StackTrace at https://gist.github.com/fuss86/df8bdc5454d6e5da7e4fbf6a34f5cf4c

Expected result
404 HTTP response

This class is no longer needed, as it's been properly replaced by a better mechanism -- the RepositoryFileAttributes.

Check if the strongbox-web-integration-tests still need this (the order of building is strongbox > strongbox-web-integration-tests).

Currently, all the project's properties are prefixed with strongbox.* and this is the only property in the that does not conform with the convention.

Tasks:

• The code of the project will have to be scanned for occurrences of this and they should be replaced.
• Building and executing the following projects should pass:
  • strongbox
  • strongbox-webapp
  • strongbox-assembly
• Updated the Application Properties page.

We need to upgrade to the latest version of Jetty.

Make sure that:

• The project still builds
• The tests are still passing

The version is controlled via the strongbox-parent/pom.xml.

This validator should be applicable for Maven repositories. It should check that the artifactId component of the path is lowercase.

For more information, check the strongbox-storage-api module under the org.carlspring.strongbox.storage.validation package.

This task is similar to #366.

At the moment, the logic for this exists only in the MavenArtifactController. The code for this needs to be extracted into the BaseArtifactController and made more re-usable. The respective layout provider implementations of the controllers should then use these methods as required, to avoid duplication.

This task is similar to #447 .

Relates to #418, #419, #420.

In the past, we used to have Spring context XML files across the modules. Since we migrated everything to annotation-based configuration, there are no longer such files, (except for one in the META-INF/spring/strongbox-web-context.xml, which should be unaffected by this change).

We need all the occurrences of META-INF/spring/** to be removed from all executions of the maven-dependency-plugin in pom.xml files.

For example:

<includes>etc/conf/strongbox.xml,META-INF/spring/**</includes>

Should be:

<includes>etc/conf/strongbox.xml</includes>

Once these have been removed, build:

• strongbox
• strongbox-web-integration-tests

... and make sure both build with properly running tests.

Build the projects below by executing mvn clean install:

• strongbox
• strongbox-webapp
• strongbox-assembly

... and make sure that the produced assembly in the strongbox-assembly/strongbox-distribution can run Strongbox properly (have a look at this page and try accessing http://localhost:48080/configuration/strongbox/xml using admin/password as credentials). Make sure there are no apparent issues.

Apply any required further changes.

All the classes using this enum like this:

RepositoryLayoutEnum.NUGET.getLayout()

should now be using:

NugetLayoutProvider.ALIAS

Initially, we thought we would have more than one implementation of a layout provider for NuGet.

• The code from NugetHierarchicalArtifactCoordinates class needs to be merged into the NugetArtifactCoordinates class.
• The NugetHierarchicalArtifactCoordinates needs to be removed. All classes using it, should be changed to use the NugetArtifactCoordinates class instead.
• Replace all Nuget Hierarchical strings to NuGet.

Note: This issue depends on #486.

We need to make it so that only one task of a given type could be running simultaneously. This should be the default behavior. There should be an option to override this, of course.

We will need a proper test case for this.

For more details on cron tasks, check here.

We need to be able to figure out the extensions of artifact files. It seems that Apache Tika is one way to do this. Doing a simple path.subString(path.lastIndexOf(File.separatorChar), path.length)) is not good enough, because there are certain extensions that are more complex like for example tar.gz, tar.bz2 and the likes.

This will probably have to be implemented in the LayoutProvider implementations.

Description

When an artifact is being deployed, or downloaded, the temporary file is stored under:

strongbox-vault/storages/${storageId}/${repositoryId}/.temp/

with the respective path of the artifact (for example: org/foo/bar/1.2.3/bar/....

When the artifact has successfully finished being written (regardless of whether this is a deploy, or resolve operation) and the file has been moved under the proper place under the repository's directory (strongbox-vault/storages/${storageId}/${repositoryId}/org/foo/bar/blah-1.2.3/blah... (this is an approximation, as the actual file name is a timestamp)), the parent directory gets left behind lying around empty under the .temp directory.

Please, note that nothing outside the .temp directory should be removed.

How to fix

Once the artifact has been successfully moved to the proper location under the repository, the respective parent directories up until a level that contains only empty directories must be removed. For example, if the path in the .temp/ directory to the artifact was com/foo/bar/1.2.3/bar-1.2.3.jar and there are com/blah/2.2.1/blah-2.2.1.jar and an empty directory com/foo/bar/1.2.3/ (with no files in any of the subdirectories under com/foo), the com/foo/bar/1.2.3/ path should be removed up until com and the com/blah/2.2.1/blah-2.2.1.jar should be skipped.

Steps to reproduce

Rough steps to reproduce this:

1. Option 1 for reproducing (deploying an artifact):
   1.1 Build strongbox with mvn clean install (you can add -DskipTests, if you like)
   1.2 cd strongbox-web-core && mvn clean package -Pjetty-block
   1.3. Use the hello-strongbox-maven example project (and the instructions there on how to deploy an artifact to Strongbox)
   1.4. Check the strongbox-vault/storages/${storageId}/${repositoryId}/.temp/
2. Option 2 for reproducing (using Strongbox as a proxy repository):
   2.1. Use the following settings.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<settings>

    <localRepository>/home/carlspring/.m2/repository-strongbox</localRepository>

    <mirrors>
        <mirror>
            <id>strongbox</id>
            <name>strongbox</name>
            <url>http://localhost:48080/storages/public/public-group/</url>
            <!-- Or try: -->
            <!--url>http://localhost:48080/storages/storage-common-proxies/maven-central/</url-->
            <mirrorOf>*</mirrorOf>
        </mirror>
    </mirrors>

    <profiles>
        <profile>
            <id>carlspring-repositories</id>

            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>

            <repositories>
                <repository>
                    <id>strongbox</id>
                    <name>strongbox</name>
                    <url>http://localhost:48080/storages/public/public-group/</url>
                    <layout>default</layout>
                </repository>
            </repositories>
            <pluginRepositories>
                <pluginRepository>
                    <id>strongbox</id>
                    <name>strongbox</name>
                    <url>http://localhost:48080/storages/public/public-group/</url>
                    <!--url>http://localhost:48080/storages/storage-common-proxies/maven-central/</url-->
                    <layout>default</layout>
                </pluginRepository>
            </pluginRepositories>
        </profile>
    </profiles>
</settings>

2.2. Try building Strongbox (or one of it's modules) against this running instance
2.3. Check under strongbox/strongbox-web-core/target/strongbox-vault/storages/"storage-common-proxies/ (or strongbox/strongbox-web-core/target/strongbox-vault/storages/storage-common-proxies/storage-common-proxies/maven-central, depending on what you chose).

Some tasks might need to have a guarantee that just one instance is executing against a given repository, or against all repositories. We need to implement this sort of limitation.

For more details on cron tasks, check here.

The Maven 2.0 layout provider uses the Maven Indexer, in addition to OrientDB as it's place for storing useful information about the artifacts.

We need to be able to keep a record of the .class files discovered in the common Maven archive formats (jar, war, etc).

What needs to be done:

• Make sure classes are added to the Lucene (Maven Indexer) local index
• Make it possible to use the MavenIndexerSearchProvider to search by class
• Implement test cases
  • Generate a test jar with several class files on it (via your tests)
  • Add the artifact to the Maven Indexer local index
  • Search for the class and assert there are results which match the criteria

The code for this will have to be placed under the strongbox/strongbox-storage/strongbox-storage-providers/strongbox-maven-layout-provider module.

See also:

• Searching
• Artifact Coordinates
• Maven Metadata
• Maven Indexer:
  • Strongbox: Maven Indexer
  • Apache Maven Indexer sources
• MavenArtifactGenerator
• TestCaseWithMavenArtifactGeneration

We need to upgrade to the latest version of Jetty.

Make sure that:

• The project still builds
• The tests are still passing
• The version is controlled via the strongbox-parent/pom.xml.

The webapp can be executed using:

mvn clean install
cd strongbox-web-core
mvn clean package -Pjetty-block

If Jetty is starting the webapp correctly, then things should be alright. To test things, try accessing:
http://localhost:48080/configuration/strongbox/xml with admin/password -- an XML with the configuration of the server should be presented, upon successful login.

Note : Jetty 9.4.7 and 9.4.8 builds the web app correctly. The tests pass too. The issue is that the Jetty server does not start at the end for deploying web app. Note that jetty v9.4.8 requires maven 3.5.0.

We need to upgrade the versions of the following dependencies to their latest compatible versions:

• org.slf4j:jcl-over-slf4j:${version.jcl}
• org.slf4j:jul-to-slf4j:${version.jcl}
• ch.qos.logback:logback-core:${version.logback}
• ch.qos.logback:logback-classic:${version.logback}

Make sure that:

• The project still builds
• The tests are still passing

The version is controlled via the strongbox-parent/pom.xml.

Upgrade the standard Spring dependencies to >= 5.0.2.RELEASE.

Make sure that:

• The project still builds
• The tests are still passing

The version is controlled via the strongbox-parent/pom.xml.

(This should not include the spring-data and spring-security-* ones).

We need to be able to respond to HTTP HEAD requests issued against the org.carlspring.strongbox.controllers.maven.MavenArtifactController and org.carlspring.strongbox.controllers.nuget.NugetPackageController classes.

This task should only cover the implementation for HEAD requests against group repositories.

Possible headers to return:

• Content-Length
• Checksum-MD5
• Checksum-SHA1
• Creation-Date
• Last-Updated

The following needs to be implement for group repositories:

• If the artifact can be resolved from one of the hosted repositories, get it from there
• For artifacts that are in a group repository that resolves them via a proxy:
  • If the artifact is cached, get the date from the cache
  • If the artifact needs to be resolved from the remote, download it first and then send the response

Also, as suggested by @fuss86, we need to add the same headers to the GET requests.

This task relates to #372 and #471.

This needs to be addressed properly, as it's not correct.
This can be obtained from the jar's META-INF/maven/plugin.xml and could be read via a ZipInputStream.

For more details, please check org.carlspring.strongbox.storage.metadata.MetadataMerger.updateMetadataAtGroupLevel().

We need a method that could return a list of Repository objects that are of a specified layout format. The method should be implemented in the ConfigurationManagementService class (+implementation).

The method should be called getRepositoriesWithLayout(String storageId, String layout). If the storageId is null, search all storages.

A small test should also be provided.

We need to add integration tests (in the strongbox-web-integration-tests project) that resolve and deploy artifacts using Ant+Ivy.

There's a "Hello, World!" application that we've already created for illustrating how to configure Ant+Ivy to work with Strongbox.

The tests should be invoked in a similar way to how they're currently being invoked for NuGet -- using Groovy scripts. There should be a Maven profile similar to the one for NuGet (check the one with<id>run-nuget-it-tests</id> for an example).

The test case must cover at least the following:

• Resolve dependencies
• Deploy an artifact

Please, note that the work for this will have to be done in a different project -- strongbox-web-integration-tests.

This issue relates to #431 and #432.

At the moment, it's not possible to list storages, or repositories, just the content of repositories.

It would be great to have this implemented.

This relates to #418, #419, #420, #444.

In continuation of #458, make the EnvironmentInfoController also show the JVM args used to start Strongbox.

Just copy the ICLA.md file from this project into all of the projects in this organization.

We need to add integration tests (in the strongbox-web-integration-tests project) that resolve and deploy artifacts using SBT.

There's a "Hello, World!" application that we've already created for illustrating how to configure SBT to work with Strongbox.

The tests should be invoked in a similar way to how they're currently being invoked for NuGet -- using Groovy scripts. There should be a Maven profile similar to the one for NuGet (check the one with<id>run-nuget-it-tests</id> for an example).

The test case must cover at least the following:

• Resolve dependencies
• Deploy an artifact

We need something along the same lines implemented for SBT.

Please, note that the work for this will have to be done in a different project -- strongbox-web-integration-tests.

This issue relates to #431 and #430.

Upgrade the dependencies and make sure that:

• The project still builds
• The tests are still passing

The version is controlled via the strongbox-parent/pom.xml.

Description

We need a new Spring controller to be implemented that returns a list of the environment variables and system properties used to launch the application.

• The controller should:
  • Produce a JSON response
  • Have a /configuration/environment/info web resource path
  • Be called EnvironmentInfoController
  • Be placed in the strongbox-web-core under the org.carlspring.strongbox.controllers
  • Display the following info:
    • Environment variables used when starting the instance
    • System properties used when starting the instance
• The returned results must be sorted
• The resource must be secured with a @PreAuthorize("hasAuthority('ADMIN')")

We need a proper test case for this.

Listing all the environment variables and system properties

curl -H "Accept: application/json" -X GET http://localhost:48080/configuration/environment/info

Expected JSON response

{
  "environment": [
    {
      "name": "JAVA_HOME",
      "value": "/java/jdk1.8.0_151"
    },
    {
      "name": "M2_HOME",
      "value": "/java/apache/maven-3.3.9"
    }
    ......
  ],
  "system": [
    {
      "name": "logging.dir",
      "value": "/path/to/logs"
    },
    {
      "name": "java.io.tmpdir",
      "value": "/path/to/tmp"
    },
    ....
  ]
}