wocommunity / wolifecycle-maven-plugin Goto Github PK

This is an issue I brought up on Slack a couple of weeks ago. It turns out that it's a side-effect of the new flattenComponents option introduced in #3. In fact, you could argue it's not even a side-effect: it's fully documented behaviour for that option:

Flatten only the WOComponents and EOModels from Resources or Components folders. All other files and directories keep their original nesting structure.

Here is the problem. Say you've got your models and .eogen files in src/main/resources/models. If you set flattenComponents to true, the plug-in does copy the models to Resources as advertised, but (presumably because of the presence of the .eogen files) doesn't then delete src/main/resources/models, or even delete just the models from that location. The result is that you've got a copy of any model Foo.eomodeld in both Resources and Resources/models in the built package. Your application will complain about the duplication at start-up.

I think we have to call this result a bug: flattenComponents causes duplicate models in the built package under the conditions described above. I can see some potential solutions:

1. Maybe flattenComponents should just do one job (flatten components) and leave models alone.
2. You could definitely argue that the .eogen files aren't even needed in the built package, and if they can be pulled from the resources at the appropriate point, then flattenComponents won't duplicate the models. (That is, it will delete Resources/models and its contents in the example above if you put the .eogen files somewhere else.)

I tried using woproject/resources.exclude.patternset to achieve option 2 without success, but maybe someone else knows how to approach it?

Attached is a sample project created by @hprange to investigate the issue, with a single modification: it sets flattenComponents to demonstrate the issue. Run mvn package and observe:

elmo:Resources paulh$ ls -l
total 32
-rw-r--r--   1 paulh  staff  1451  3 Jul 08:46 Info.plist
drwxr-xr-x  12 paulh  staff   384  3 Jul 08:46 Java
-rw-r--r--   1 paulh  staff   142  3 Jul 08:46 Main.api
drwxr-xr-x   5 paulh  staff   160  3 Jul 08:46 Main.wo
drwxr-xr-x   4 paulh  staff   128  3 Jul 08:46 MyEOModel.eomodeld
-rw-r--r--   1 paulh  staff  4508  3 Jul 08:46 Properties
drwxr-xr-x   4 paulh  staff   128  3 Jul 08:46 models
elmo:Resources paulh$ cd models/
elmo:models paulh$ ls -l
total 8
-rw-r--r--  1 paulh  staff  195  3 Jul 08:46 MyEOModel.eogen
drwxr-xr-x  4 paulh  staff  128  3 Jul 08:46 MyEOModel.eomodeld

wo-flatten-model-test.zip

The wolifecycle-maven-plugin should tell m2e to ignore its execution inside Eclipse. This issue was solved by 90462b8.

When installing a woapplication project (packaging woapplication,mvn install) with the maven-install-plugin 3.0.0-M1 the build fails with the message:

The packaging plugin for this project did not assign a main file to the project but it has attachments. Change packaging to 'pom'.

With a previous install-plugin version (e.g. 2.5.2) an info message is displayed instead:

No primary artifact to install, installing attached artifacts instead.

The 3.0.0 version of the install plugin demands from all non-POM-packaging projects a defined main artifact. AbstractPackageMojo.java does set a main project artifact file, but for woapplications the file name is probably invalid.

A simple solution (besides not using version 3.0.0 ;-) may be to define the application resource archive as the main artifact, and only attach the webserver resource archive.

In general wolifecycle implements some kind of classifier support, but setting a classifier on a woapplication project generates incomplete and broken applications.

<build>
        <plugins>
            <plugin>
                <groupId>org.wocommunity</groupId>
                <artifactId>wolifecycle-maven-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <skipAppleProvidedFrameworks>${skip.apple.frameworks}</skipAppleProvidedFrameworks>
                    <classifier>testclassifier</classifier>
                </configuration>
            </plugin>
        </plugins>
</build>

The content of the WOA build is split between two directories, one with the classifier embedded in the name (e.g. ERXTest-7.2-SNAPSHOT-testclassifier.woa), and one without the classifier (ERXTest-7.2-SNAPSHOT.woa). The classifier part contains all application resources (components, webserverresources, etc.), while the non-classifier part contains the java classes and WOA infrastructure (classpath files, start scripts).
The tgz-archives are packed and named from the WOA without the classifier, but installed and deployed under the classifier name.
In my opinion the build should generate only the non-classifier WOA directory (named after the finalName property) with all content, and only then generate the tgz-archives with the classifier name. If it is necessary to embed the classifier into the app directory name, then finalName could be modified accordingly.