Skip to content
This repository has been archived by the owner on Mar 21, 2022. It is now read-only.

Add support for filtering Dockerfile based configuration #25

Closed
rodlogic opened this issue Oct 15, 2014 · 13 comments
Closed

Add support for filtering Dockerfile based configuration #25

rodlogic opened this issue Oct 15, 2014 · 13 comments
Labels

Comments

@rodlogic
Copy link

No description provided.

@drewcsillag
Copy link

Can you describe more

a. what you mean?
b. what your use case is?

@jorgemoralespou
Copy link

Hi, I have same request here.
I have a Dockerfile where I add a zip file that has the ${project.version}. I want in my final Dockerfile to have 1.0.0-SNAPSHOT rather than putting that in my original Dockerfile and having to change per every release and tag

@byF
Copy link

byF commented Apr 2, 2015

@jorgemoralespou: workaround is simple, use maven-resources-plugin like:

<plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.7</version>
    <executions>
        <execution>
            <id>prepare-dockerfile</id>
            <phase>validate</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory}/docker-ready</outputDirectory>
                <resources>
                    <resource>
                        <directory>src/docker</directory>
                        <filtering>true</filtering>
                    </resource>
                </resources>
            </configuration>
        </execution>
    </executions>
</plugin>

Then ${project.build.directory}/docker-ready is your dockerDirectory

@davidxia
Copy link
Contributor

davidxia commented Aug 7, 2015

@rodlogic Is this issue still relevant or can I close? If it's still relevant, please add more info.

@yngveh
Copy link

yngveh commented Oct 16, 2015

This is still wanted. The easiest way to explaine the wanted change is with the following diff:

$ git diff BuildMojo.java BuildMojo-Modified.java
diff --git a/BuildMojo.java b/BuildMojo-Modified.java
index 3b8dcb8..db6b5f2 100755
--- a/BuildMojo.java
+++ b/BuildMojo-Modified.java
@@ -301,6 +301,7 @@ public class BuildMojo extends AbstractDockerMojo {
     } else {
       final Resource resource = new Resource();
       resource.setDirectory(dockerDirectory);
+      resource.setFiltering(true);
       resources.add(resource);
       copyResources(destination);
     }

@beskow
Copy link

beskow commented Nov 5, 2015

+1. The workaround is ugly, the proposed solution is simple.

@mattnworb
Copy link
Member

The BuildMojo doesn't use maven-resources-plugin to copy the files/resources, so setting resource.setFiltering(true) as suggested above by @yngveh unfortunately does not have any effect.

I think that @byF's workaround is the best solution as any sort of homegrown filtering logic we could add in BuildMojo would be less feature-rich than what already exists in maven-resources-plugin:copy-resources, and it doesn't seem obvious or simple to reuse the logic that maven-resources-plugin uses.

@mattnworb
Copy link
Member

Actually I looked at it a bit more and the resource-filtering logic seems like it can be reused from maven-resources-plugin.

I have a branch with this change at https://github.com/spotify/docker-maven-plugin/tree/resource-filtering but I get some test failures related to Plexus that I don't understand, my guess is that the maven-filtering library has introduced some sort of dependency problem within the other Maven jars:

testPush(com.spotify.docker.PushMojoTest)  Time elapsed: 0.125 sec  <<< ERROR!
java.lang.NoClassDefFoundError: Lorg/apache/maven/artifact/transform/ArtifactTransformationManager;
    at java.lang.Class.getDeclaredFields0(Native Method)
    at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
    at java.lang.Class.getDeclaredFields(Class.java:1916)
    at com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:651)
    at com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:358)
    at com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(ConstructorBindingImpl.java:155)
    at com.google.inject.internal.InjectorImpl.getInternalDependencies(InjectorImpl.java:585)
    at com.google.inject.internal.InjectorImpl.cleanup(InjectorImpl.java:542)
    at com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:528)
    at com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:833)
    at com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:758)
    at com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:255)
    at com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:204)
    at com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:954)
    at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:987)
    at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:950)
    at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1000)
    at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
    at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:84)
    at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:52)
    at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
    at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
    at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
    at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
    at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
    at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
    at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
    at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
    at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
    at com.google.inject.Scopes$1$1.get(Scopes.java:59)
    at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
    at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
    at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
    at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
    at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
    at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
    at org.eclipse.sisu.plexus.PlexusRequirements$RequirementProvider.get(PlexusRequirements.java:250)
    at org.eclipse.sisu.plexus.ProvidedPropertyBinding.injectProperty(ProvidedPropertyBinding.java:48)
    at org.eclipse.sisu.bean.BeanInjector.injectMembers(BeanInjector.java:52)
    at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:128)
    at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:117)
    at com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
    at com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:91)
    at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
    at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
    at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
    at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:89)
    at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:259)
    at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
    at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
    at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
    at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1000)
    at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
    at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:84)
    at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:52)
    at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
    at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
    at org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
    at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
    at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
    at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
    at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
    at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
    at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
    at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
    at com.google.inject.Scopes$1$1.get(Scopes.java:59)
    at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
    at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
    at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
    at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
    at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
    at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
    at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
    at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
    at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:246)
    at org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:211)
    at org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:126)
    at junit.framework.TestCase.runBare(TestCase.java:139)
...

@mattnworb mattnworb reopened this Nov 5, 2015
@byF
Copy link

byF commented Nov 5, 2015

I've looked into it and the reason is the maven-filtering is built with Maven version 2.2.1, while you are building the plugin on top of 3.2.1. That causes incompatibility between dependencies.

I was trying to downgrade this plugin to use 2.2.1 - there are a few issues which might be resolvable, though I'm not sure what is the best way (f.e. old version of PluginParameterExpressionEvaluator needs ancient org.codehaus.plexus.logging.Logger interface which could be implemented with some moder logger underneath etc.)

@mattnworb
Copy link
Member

@byF nice catch!

Looks like the maven-filtering library has had some activity recently to upgrade it to Maven 3.0 components, so perhaps that could be used instead of having to downgrade the entirety of this plugin to 2.2.1 dependencies.

@byF
Copy link

byF commented Nov 9, 2015

I built maven-filtering 3.0.1-SNAPSHOT locally (the snapshot is not published), but the tests keep failing - I suspect because of conflicts. I tried various combinations of dependency versions, but it's like a looking for a needle in a haystack.

@vromero
Copy link

vromero commented Dec 5, 2016

IMHO this very necessary change could render the whole maven xml DSL DockerFile alternative config unnecessary. +1

@stale
Copy link

stale bot commented Sep 11, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Sep 11, 2018
@stale stale bot closed this as completed Sep 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

9 participants