Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

system.properties for Heroku repo #15

Open
ebridges opened this issue Aug 8, 2013 · 11 comments
Open

system.properties for Heroku repo #15

ebridges opened this issue Aug 8, 2013 · 11 comments

Comments

@ebridges
Copy link

ebridges commented Aug 8, 2013

Thanks for creating the tool I've been looking for :-)

What's the recommended way for a project to bundle up it's jar file and dependencies to work with this plugin?

  • If I create an executable fat jar (i.e. all dependencies with main attribute in manifest), it doesn't get pushed up to heroku.
  • If I add a main attribute to the manifest, then it's not finding the classes on the classpath.

Would you kindly provide a more sophisticated (i.e. non-web) example that involves multiple 3rd party jar files? (In my case I'm building a Spring Batch job). What should the procfile look like to be compatible?

Thanks!

@yegor256
Copy link
Member

yegor256 commented Aug 8, 2013

Let's split your problems first. Why your fat executable file doesn't get pushed to heroku? Keep in mind that the plugin doesn't push any WAR/JAR files to heroku. Instead, it expects you to deploy them somewhere (to S3 repository, for example), and then it will instruct heroku to pull them from there. Let's make this clear before we move on.

@ebridges
Copy link
Author

ebridges commented Aug 8, 2013

Okay, I see now that it uses <artifacts><artifact>...</artifact></artifacts> to determine what to copy over to Heroku. I was leaving the jar-with-dependencies classifier out; adding that led to the artifact being copied successfully.

I ran into some other (unrelated) issues and have gotten the code to successfully deploy to Heroku and to kick off the job.

However, it appears that the plugin is not honoring the JDK level of my project (as set in my project's parent pom) when generating system.properties. The project is at 1.7, while the system.properties which is generated is 1.6.

Is there some configuration I need in order to establish the proper JDK target?

Thanks!

@yegor256
Copy link
Member

yegor256 commented Aug 8, 2013

I'm not sure what you mean by system.properties. The plugin doesn't generate such a file.. Where do you find it?

@ebridges
Copy link
Author

ebridges commented Aug 8, 2013

This is what I'm referring to --> https://devcenter.heroku.com/articles/add-java-version-to-an-existing-maven-app#add-system-properties-to-your-app

And, one does end up appearing:

$ heroku run bash
Running `bash` attached to terminal... up, run.2989
~ $ ls -l
total 8912
-rw------- 1 u37219 37219     112 Aug  8 12:06 Procfile
-rw------- 1 u37219 37219    1017 Aug  8 12:08 build.log
-rw------- 1 u37219 37219    5492 Aug  8 12:06 pom.xml
-rw------- 1 u37219 37219    1497 Aug  8 12:06 settings.xml
-rw------- 1 u37219 37219      25 Aug  8 12:06 system.properties
-rw------- 1 u37219 37219 9098611 Aug  8 12:08 weather-history-import.jar
~ $ cat system.properties 
java.runtime.version=1.6

Whereas in the parent pom for the project I've deployed I've specified 1.7 for both source & target versions.

Thanks for the quick responses!!

@yegor256
Copy link
Member

yegor256 commented Aug 8, 2013

The plugin doesn't touch this file. You should checkout Git repository from Heroku to your computer, change the file, commit and push it back. That's it.

@ebridges
Copy link
Author

ebridges commented Aug 8, 2013

Ok, I'll work around this for now. If you could point out relevant aspects of the code, I may be able to do a pull request with this added in (unless you were planning on doing it).

Thanks again!

@yegor256
Copy link
Member

yegor256 commented Aug 8, 2013

This is how we add files to the repo: https://github.com/yegor256/jcabi/blob/master/jcabi-heroku-maven-plugin/src/main/java/com/jcabi/heroku/maven/plugin/DeployMojo.java#L153-L168

Maybe it's a good idea to add system.properties there as well. A pull request is always welcome :)

@ebridges
Copy link
Author

ebridges commented Aug 9, 2013

Started looking at this, but I'm not terribly familiar with the internal mechanisms of Maven.

Assuming that the POM will contain somewhere this information:

    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.1</version>
      <configuration>
        <source>1.7</source>
        <target>1.7</target>
      </configuration>
    </plugin>

I'm looking at doing something like this:

    private static String lookupJdkVersion(MavenProject project) {
        String jdkVersion = "1.6" // default?
        List<Plugin> buildPlugins = project.getBuildPlugins();
        for(Plugin plugin : buildPlugins) {
            if(plugin.getArtifactId().equals("maven-compiler-plugin")) {
                Object configuration = plugin.getConfiguration();
                // what type would this object be?  I.e. how would I obtain target version from this?
            }
        }
        return jdkVersion;
    }

Note the question in the comment -- not clear how to interpret the Object returned from Plugin#getConfiguration().

@yegor256
Copy link
Member

yegor256 commented Aug 9, 2013

I don't really like this approach. Mostly because maven-compiler-plugin is not the only one that is used for source code compilation. I use aspectj compiler sometimes, for example.

How about we add a list of system properties to the jcabi-heroku-maven-plugin itself? BTW, do you have a link to that system.properties files explained by heroku? I can't find it..

@ebridges
Copy link
Author

ebridges commented Aug 9, 2013

fair enough, can we assume that any compiler plugin would store the version in a configuration property named target?

It's in one of the issues above, but here's the link:
https://devcenter.heroku.com/articles/add-java-version-to-an-existing-maven-app#add-system-properties-to-your-app

@yegor256
Copy link
Member

yegor256 commented Aug 9, 2013

In this case we'll add support just for one property. In the future Heroku will add more properties to the file and we'll have to change the plugin again. Instead, I would propose to add an ability to commit/push any content of this system.properties:

<plugin>
  <groupId>com.jcabi</groupId>
  <artifactId>jcabi-heroku-maven-plugin</artifactId>
  <version>0.7.21</version>
  <configuration>
    <system.properties>
      <java.runtime.version>1.7</java.runtime.version>
      <something.in.the.future>blah-blah-blah</something.in.the.future>
    </system.properties>
  </configuration>
</plugin>

@yegor256 yegor256 transferred this issue from jcabi/jcabi Sep 10, 2022
@yegor256 yegor256 removed their assignment Sep 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants