search

jutzig / github-release-plugin

uses the github release api to upload files
69 stars 24 forks source link

Build fails for aggregator project #14

Closed EvgeniGordeev closed 9 years ago

EvgeniGordeev commented 9 years ago

Build fails but the tag, release are actually created and artifact uploaded:

[INFO] --- github-release-plugin:1.1.0:release (default-cli) @ matrix-build ---
[ERROR] 
java.io.FileNotFoundException: https://api.github.com/repos/:organization/:repo.git
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1835)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
    at org.kohsuke.github.Requester.parse(Requester.java:323)
    at org.kohsuke.github.Requester._to(Requester.java:200)
    at org.kohsuke.github.Requester.to(Requester.java:154)
    at org.kohsuke.github.GitHub.getRepository(GitHub.java:289)
    at de.jutzig.github.release.plugin.UploadMojo.execute(UploadMojo.java:142)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
jutzig commented 9 years ago

Given that line number it cannot have uploaded anything de.jutzig.github.release.plugin.UploadMojo.execute(UploadMojo.java:142) At this point it has not even assigned the name of the release.

EvgeniGordeev commented 9 years ago

Tried the command on latest snapshot:

mvn github-release:release -Ddescription="v.4.0.6.BUILD released." -Dusername=xxx -Dpassword=xxx

for scm url configured:

  <scm>
    <url>https://github.com/${organization.name}/${repo}</url>
    <connection>scm:git:https://github.com/${organization.name}/${repo}</connection>
    <developerConnection>scm:git:https://github.com/${organization.name}/${repo}.git</developerConnection>
  </scm>

Exception as follows:

java.io.FileNotFoundException: https://api.github.com/repos/scm:git:https:/
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1834)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
    at org.kohsuke.github.Requester.parse(Requester.java:323)
    at org.kohsuke.github.Requester._to(Requester.java:200)
    at org.kohsuke.github.Requester.to(Requester.java:154)
    at org.kohsuke.github.GitHub.getRepository(GitHub.java:289)
    at de.jutzig.github.release.plugin.UploadMojo.execute(UploadMojo.java:158)

I'm feeling strange about the line 158 in code since it doesn't make any sense to me, but again release and tag were created sucessfully, and artifact was uploaded.

EvgeniGordeev commented 9 years ago

Ok, I missed something in the log. Actually aggregator module is executed successfully, the build fails on the first child module.

jutzig commented 9 years ago

Is it possible that you forget to copy the scm section over to the child modules?

EvgeniGordeev commented 9 years ago

Don't think it's a good idea. Why to duplicate your scm sections among all child modules? I see 2 options: 1) skip child modules by default if task is run on aggregator project (e.g. checkstyle:checkstyle-aggregate) 2) add a new task or option like aggregate=true (or skipModules=true) to skip children or not for more flexibility

jutzig commented 9 years ago

Don't think it's a good idea. Why to duplicate your scm sections among all child modules?

Because that is how maven works. Maven does bad automagic to the SCM section of multi module builds. It appends the relative path of the child module to the parents scm section. That makes sense for old SCMs like subversion and CVS but breaks for git. If you do not copy the SCM section into the children their SCM info is broken and things like maven-release-plugin (and this plugin) will fail.

1) skip child modules by default if task is run on aggregator project (e.g. checkstyle:checkstyle-aggregate)

I use the plugin in the child modules myself, so I don't think this is a reasonable default.

2) add a new task or option like aggregate=true (or skipModules=true) to skip children or not for more flexibility

If you define the plugin in the parent and do not want it to apply to the children use inherited false in the plugin config

EvgeniGordeev commented 9 years ago

inherited=false doesn't prevent a plugin from running in modules. Thus there is still no much gain from it since you need to specify the plugin in all modules. What won't work for release plugin. It still makes sense to add a skipModules (default=false) property to plugin configuration for aggregator projects and add a method like

public boolean skipExecution()
    {
        return skipModules && !project.isExecutionRoot();
        }

Thanks, for pointing out to SCM Maven magic. So the only solution for my case is to put into child module

<scm>
    <connection>${project.parent.scm.connection}</connection>
  </scm>

and move release plugin to distribution module.

jutzig commented 9 years ago

inherited=false doesn't prevent a plugin from running in modules. Thus there is still no much gain from it since you need to specify the plugin in all modules.

It prevents you from inheriting a defined execution from the parent which in turn prevents the plugin from running in child modules.

What won't work for release plugin

Things like submodule release do not work unless the scm section if defined in each child module. If you try to release without it tries to clone e.g. http:example.org/repo.git/submodule

It still makes sense to add a skipModules (default=false) property to plugin configuration for aggregator projects

Sorry, I don't really get why that would be helpful

EvgeniGordeev commented 9 years ago

It prevents you from inheriting a defined execution from the parent which in turn prevents the plugin from running in child modules.

Exactly, it means you can't just run github-release:release. If you bind execution to a specific phase, this phase should be configured for all modules. The only workaround is to skip deployment plugin:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-deploy-plugin</artifactId>
        <configuration>
          <skip>true</skip>
        </configuration>
      </plugin>
      <plugin>
        <groupId>de.jutzig</groupId>
        <artifactId>github-release-plugin</artifactId>
        <executions>
          <execution>
            <id>github-upload</id>
            <phase>deploy</phase>
            <goals>
              <goal>release</goal>
            </goals>
            <inherited>false</inherited>
            <configuration>
              <releaseName>v${project.version}</releaseName>
              <tag>v${project.version}</tag>
              <description>v${project.version} released.</description>
            </configuration>
          </execution>
        </executions>
      </plugin>

Sorry, I don't really get why that would be helpful

skipModules property will give more control, and we could run the plugin disregarding any phase without extra workaround configuration like above. Even with the workaround like here the entire life cycle (compilation, tests) is executed, but you need only to make a release.

jutzig commented 9 years ago

I still don't quite get what you are trying to do. Who in your reactor wants to publish assets to github? The reactor, one of the child modules, some of the child modules or all of the child modules?

EvgeniGordeev commented 9 years ago

Only reactor. Inherited=false in reactor and execution phase=deploy triggers first github release and then all child modules are compiled, tested and deployed what is overkill since you just want to release without extra stuff. But it's a standard behavior of Maven, so definitely your plugin is not aimed to fix it as far as you can work-around it by moving plugin to a child module. I think it's time to close the issue.

Thanks for you great plugin, especially for new version 1.1.1.

jutzig commented 9 years ago

You can use the -N (non-recursive) parameter to just build the parent without the children.