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

Build fails for aggregator project #14

Closed
EvgeniGordeev opened this issue Apr 7, 2015 · 12 comments
Closed

Build fails for aggregator project #14

EvgeniGordeev opened this issue Apr 7, 2015 · 12 comments

Comments

@EvgeniGordeev
Copy link

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
Copy link
Owner

jutzig commented Apr 7, 2015

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
Copy link
Author

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 EvgeniGordeev changed the title Build fails on new release creation Build fails on new release creation for aggregator project Apr 8, 2015
@EvgeniGordeev
Copy link
Author

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

@EvgeniGordeev EvgeniGordeev changed the title Build fails on new release creation for aggregator project Build fails for aggregator project Apr 8, 2015
@jutzig
Copy link
Owner

jutzig commented Apr 8, 2015

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

@EvgeniGordeev
Copy link
Author

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
Copy link
Owner

jutzig commented Apr 8, 2015

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.

  1. 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
Copy link
Author

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
Copy link
Owner

jutzig commented Apr 8, 2015

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
Copy link
Author

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
Copy link
Owner

jutzig commented Apr 8, 2015

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?

  • In case it's just the reactor -> use inherit false
  • One child module -> put the whole plugin configuration there
  • All of the child modules -> use inherit true
  • Some of the child modules -> use plugin management for the configuration and just declare an execution for the children that actually create assets (or use profiles)

@EvgeniGordeev
Copy link
Author

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
Copy link
Owner

jutzig commented Apr 8, 2015

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

@jutzig jutzig closed this as completed Apr 8, 2015
pascalleclercq added a commit to angelozerr/eclipse-wtp-json that referenced this issue Jun 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants