ageto / hybris-maven-plugin Goto Github PK

->copy files into temp dir
->run code generator

Every hybris extension has a lib folder containing additional libraries. It looks like that they all comes from maven central repository.
Use the REST api of search.maven.org to determine the GAV parameters of each library.

For example commons-configuration-1.7:
http://search.maven.org/solrsearch/select?q=a:%22fastutil%22%20AND%20v:%226.5.6%22%20AND%20p:%22jar%22&rows=20&wt=json

When running the code generator it produces a compilation error for extension "mediaweb". This should be resolved.

Currently while building the hybris fake extension the list of extensions will be taken from the extensions.xml from the platform resources.
For productive use the plugin has to determine the extensions list from the dependencies of the modules contained in the reactor.

Create Unit-Tests for more classes

hybris extensions provide test sources. They will no restructured currently because they could not be compiled.
Some dependencies are missing. That hat to be fixed. The test sources document the functionality and usage of the productive code.

The EmbeddedMavenExecutor blocks the program execution till the triggered maven build is finished. For better monitoring and feeled performance it would be nice to have a non-blocking implementation of MavenExecutor.

Based on #26 the should be another enhancement.
At the current state the resolvability of an external dependency will check with aether api against the central repository only. This will not reflect current settings suh as proxies or local repo mirrors.

To do so, we create a temporary pom with the dependency to test. Than use mvn dependency:resolve. In addition this will speed up the current process of doing the hybris:install over and over becaus locally installed hybris artifacts can now be resolved.

com.divae.ageto.hybris.install.extensions.Extension and com.divae.ageto.hybris.install.task.metadata.ExtensionProperties are the same data classes. They are used at different places within execution but stores nearly the same data.

Merge them and use only one.

Needed files should be linked instead of copying them into the hybis fake structure.

https://travis-ci.org/
https://www.versioneye.com/
https://sonarqube.com/

To start up the hac-web webapp configure a web container plugin such as tomcat or jetty maven plugin the start it up. Solve all problems that will occur.

• divide "CopyFilesTask" in separate classes for the cases:

  copy 1 file to directory
  copy folder recursivly to directory

• add function to class:

  copy only files in a folder to directory

• refactore class in that way that it gets file classes instead of strings for target and source

Currently the build fails in TravisCI. It looks like the temp directory could not determined by the JVM by System.getProperty("java.io.tmpdir")

We could try a fall back in the abtract test base. Maybe use the local working dir as temp dir. At TraivsCI it should no problem.

Initially it was there but deactivated til development.

Introduce a property for InstallMojo to activate the decompilation of the hybris code, so that *-sources.jar could be provided per each extension. Durring development of the hybris-maven-plugin it would help alot to encounter compiler and linkage problems.

Aappropriate legal notes are a must have!

Add a list of extensions to build and run a basic hybris suite

Introduce a property of the InstallMojo that the user could define a custom and fix work directory for the installation process

Move the currently existing integration tests into a new module.

Write a method getting an extension as parameter and returning a list of extensions it depends on.

https://github.com/AGETO/hybris-maven-plugin/wiki/Basic-extensions

Copy folder "web" in "hac" into separate folder "hac-web" (contains directory src/main/resources)

Add an option to skip test sources to be restructured

Reorganize and sort the pom.xml of the project after https://maven.apache.org/pom.html the reflect the defined standard format.

Function "MavenCentralDependencyResolver.resolve" causes a null pointer exception when trying to run the plugin

Currently all dependency versions are hard coded and only valid for the hybris suit version we develop against now (5.5.1.1).
While restructuration of the extensions, the versions have to be determined and applied dynamically.

While restructuring extension create metadata file to store the extensions infos for later use when building the hybris fake structure

[EXTENSION]-metadata.properties that story meta data of the source hybris extension is placed wrong.
EVERY file within a maven project has to be localed in "src".
In this case is valid "src/main/resources/". For better separation we could use "src/meta/".

Find all files which have to be copied for the code generator to run an copy them to the needed locations.
A description of the resource files the code generator depends on can be found here:
https://github.com/AGETO/hybris-maven-plugin/wiki/Code-generator-resource-files

How to build the project? This is essential for gh-5

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.773 s
[INFO] Finished at: 2016-08-11T10:22:40+02:00
[INFO] Final Memory: 14M/202M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project hybris-maven-plugin: Could not resolve dependencies for project com.divae.ageto:hybris-maven-plugin:maven-plugin:0.0-SNAPSHOT: Could not find artifact de.hybris:bootstrap:jar:5.5.1.1 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Add project description to wiki

There are different places that store paths, files and directoires as String. Use File instead.

There is a CreatePomTask that will use the PomCreator. The PomCreator was introduced to reuse the functionality of the CreatePomTask. That use case is not any more valid. Becaus of that the PomCreator could be removed.

Currently the project is build on java 7.
Migrate to Java 8 and all its enhancements.

I have spotted a class with absolute miss use of logging combined with thrown an exception:

ExtractZipTask maybe there are more.

While catching an exception you have to decide what to do:

• log a meaningful message and break processing or not
• throw an exception with a meaningful message and break ultimatively the processing for the caller

When use what:
If your method encounters an exception but still can continue, log this situation as warning and proceed. An other situation is an exception, log something and terminate the execution normaly by early return.

You throw an exception if it impossible to handle the detected situation and your method has encountered an error. Something went terribly wrong and the only valid result is an exceptional process termination.

NEVER EVER do both. It is totaly bad style. Typically will be the exception message be logged. If you throw an exception than let decide the caller what to do with this information. He could also log this or throw another excpetion. There the same rules will be applied.