[uber] Some dependencies require their pom.properties file

[martinklepsch]

Postal looks up it's version at runtime be looking at META-INF/maven/com.draines/postal/pom.properties which is excluded by the uberjar task by default:

#{#"(?i)^META-INF/[^/]*\.(MF|SF|RSA|DSA)$"
  #"^((?i)META-INF)/.*pom\.(properties|xml)$"
  #"(?i)^META-INF/INDEX.LIST$"}

Postal function for reference:

(defn pom-version []
  (let [pom "META-INF/maven/com.draines/postal/pom.properties"
        props (doto (Properties.)
                (.load (-> pom io/resource io/input-stream)))]
    (.getProperty props "version")))

[martinklepsch]

In this regard the docstring for the uber task are also a bit confusing.

Conj MATCH onto the set of regexes that paths must not match.

makes one think that the things mentioned as default will be the "base set" for the mentioned conj operation.

[martinklepsch]

I’m thinking we should include all pom.properties files but that would require a more strict rule to find the right .properties file in the fileset. Currently the following is used, causing my jar to build as tools.namespace 😄

(->> (core/output-files fileset)
                 (map core/tmp-file)
                 (core/by-name ["pom.properties"])
                 first)

(source)

[martinklepsch]

There's drewr/postal#66 tracking this in postal. I'm not sure if reaching for pom.properties is something jars are "allowed" to do. Someone who knows please step up :)

[micha]

Regarding the uber docstring: how about

Conj MATCH onto the set of regexes that paths must not match, replacing the default set.

[micha]

@martinklepsch The only thing it's getting from the pom.properties file is the info it uses to generate the name of the jar file. You can use the -f option to the jar task to name your uberjar something other than tools.namespace.jar :)

[martinklepsch]

Right! How did I not check task options here...?
The docstring suggestion sounds good to me.
Guess we can close this then?

[micha]

@martinklepsch i think it's still a bug...

I think the jar task is trying to be too smart when it sniffs for pom.properties files just to make a pretty jar name. I think the jar should just be called "project.jar" unless you give the -f option.

Similarly, I think the install and push tasks aren't being smart enough--they should accept an optional --pom option where you can specify the specific pom.xml file they should use to install/deploy when there are multiple poms in the jar.

So I think you're right, we should remove the pom.properties regex from the default excludes and modify some tasks. Does that seem right?

[martinklepsch]

I think the jar task is trying to be too smart when it sniffs for pom.properties files just to make a pretty jar name. I think the jar should just be called "project.jar" unless you give the -f option.

👍

Similarly, I think the install and push tasks aren't being smart enough--they should accept an optional --pom option where you can specify the specific pom.xml file they should use to install/deploy when there are multiple poms in the jar.

Makes sense 👍

So I think you're right, we should remove the pom.properties regex from the default excludes and modify some tasks. Does that seem right?

If the jar task outputs project.jar by default seems fine. What other tasks would need to be modified?

[Deraen]

This should work with the default options.

[Deraen]

This is fixed in master.