Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.1
    • Component/s: None
    • Labels:
      None

      Description

      Prior to Solr 5, we avoided doing anything fancy with our jetty configs because we didn't want to overly customize "the example" beyond things that involved loading the solr.war.

      That's not longer an issue, so we might as well plop in some jetty config features to redirect / to /solr.

      1. SOLR-7240_start_jar_branch5x.patch
        0.2 kB
        Timothy Potter
      2. SOLR-7240_trunk.patch
        4 kB
        Hoss Man
      3. SOLR-7240.patch
        0.8 kB
        Hoss Man

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          In response to the inevitable question "why not just move all /solr/* URLs to /, i re-iterate my comment to this topic on the mailing list last month...

          PS: Same goes for the default URL. We could move to toplevel now http://localhost:8983/

          -0 ... i don't see any downside to leaving "/solr/" in the URL, and if/when we rip out the jetty stack completley and stop beholding to the servlet APIs internally it gives us flexibility if we want to start deprecating/retring things to be able to say "All of the legacy, pre-Solr X.0, APIs use a base path of '/solr/' and all the new hotness APIs use a base path of '/v2/'" ... or something like that.

          Show
          Hoss Man added a comment - In response to the inevitable question "why not just move all /solr/* URLs to /, i re-iterate my comment to this topic on the mailing list last month... PS: Same goes for the default URL. We could move to toplevel now http://localhost:8983/ -0 ... i don't see any downside to leaving "/solr/" in the URL, and if/when we rip out the jetty stack completley and stop beholding to the servlet APIs internally it gives us flexibility if we want to start deprecating/retring things to be able to say "All of the legacy, pre-Solr X.0, APIs use a base path of '/solr/' and all the new hotness APIs use a base path of '/v2/'" ... or something like that.
          Hide
          Hoss Man added a comment -

          patch leveraging a bit of jetty magic to do this.

          Show
          Hoss Man added a comment - patch leveraging a bit of jetty magic to do this.
          Hide
          Hoss Man added a comment -

          Hmm, not sure i'm a fan of this solution actually...

          it only only redirects "/" it also redirects "/anything_other_then_solr"...

          http://localhost:8983/garbage -> http://localhost:8983/solr/

          ...this seems like a bad idea. My goal was simply to make "http://localhost:8983/" send you someplace useful, but if people are making up giberish URLs – or have typos in client connection urls (eg: "http://localhost:8983/Solr/MyCollection/select") those should really just return 404 rather then silently rewriting to ".../solr/"

          Show
          Hoss Man added a comment - Hmm, not sure i'm a fan of this solution actually... it only only redirects "/" it also redirects "/anything_other_then_solr"... http://localhost:8983/garbage -> http://localhost:8983/solr/ ...this seems like a bad idea. My goal was simply to make "http://localhost:8983/" send you someplace useful, but if people are making up giberish URLs – or have typos in client connection urls (eg: "http://localhost:8983/Solr/MyCollection/select") those should really just return 404 rather then silently rewriting to ".../solr/"
          Hide
          Ramkumar Aiyengar added a comment -

          Re: your comment on having /solr so that we could have an incompatible /v2 in the future: wouldn't the same concern apply to the redirect as well? I.e. what API is the root url going to service during such an API shift? It leads to the root URL being on the oldest version if it stays on v1, but if always redirect it to v2, we are waiving off all backward compatibility requirements for the root url alone – how do we communicate this discrepancy in compatibility guarantees between the two URLs? And how useful is it going to be if we say that the meaning of the redirect is going to change under your feet without notice?

          Show
          Ramkumar Aiyengar added a comment - Re: your comment on having /solr so that we could have an incompatible /v2 in the future: wouldn't the same concern apply to the redirect as well? I.e. what API is the root url going to service during such an API shift? It leads to the root URL being on the oldest version if it stays on v1, but if always redirect it to v2, we are waiving off all backward compatibility requirements for the root url alone – how do we communicate this discrepancy in compatibility guarantees between the two URLs? And how useful is it going to be if we say that the meaning of the redirect is going to change under your feet without notice?
          Hide
          Hoss Man added a comment -

          ... what API is the root url going to service during such an API shift?

          Your concern is precisely the reason i said i do not like the patch i put up. When i threw it together, i did not intend/expect that it would cause /foo to redict to /solr ... i missunderstood what Jetty's MovedContextHandlerthe does.

          I do not want people to mistakenly rely on any sort of redirecting to server the "current" API ... i was solely trying to put in place a redirect for the singular url of "/" so that the user experience on loading "/" in a browser would be slightly less ugly.

          Show
          Hoss Man added a comment - ... what API is the root url going to service during such an API shift? Your concern is precisely the reason i said i do not like the patch i put up. When i threw it together, i did not intend/expect that it would cause /foo to redict to /solr ... i missunderstood what Jetty's MovedContextHandlerthe does. I do not want people to mistakenly rely on any sort of redirecting to server the "current" API ... i was solely trying to put in place a redirect for the singular url of "/" so that the user experience on loading "/" in a browser would be slightly less ugly.
          Hide
          Shawn Heisey added a comment -

          I agree that redirecting /whatever would be a bad idea. +1 to redirecting ONLY the specific "/" url to the admin UI on /solr, or whatever it might be in the future.

          Show
          Shawn Heisey added a comment - I agree that redirecting /whatever would be a bad idea. +1 to redirecting ONLY the specific "/" url to the admin UI on /solr, or whatever it might be in the future.
          Hide
          ASF GitHub Bot added a comment -

          GitHub user makuk66 opened a pull request:

          https://github.com/apache/lucene-solr/pull/136

          SOLR-7240 add redirect of / to /solr/

          SOLR-7240 add redirect of / to /solr/, using the jetty rewrite module with a regex pattern

          With this patch, / (and only /) redirects to /solr/.

          Tested with `bin/solr -f` on OSX:

          ```
          $ printf "GET / HTTP/1.0\r\n\r\n" | nc localhost 8983
          HTTP/1.1 302 Found
          Location: http://127.0.0.1:8983/solr/
          Content-Length: 0

          $ printf "GET /solr/ HTTP/1.0\r\n\r\n" | nc localhost 8983 | grep '<title>'
          <title>Solr Admin</title>
          $ printf "GET /foo HTTP/1.0\r\n\r\n" | nc localhost 8983 | grep '<title>'
          <title>Error 404 Not Found</title>
          ```

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/makuk66/lucene-solr SOLR-7240-redirect-slash-to-solr-squashed

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/lucene-solr/pull/136.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #136


          commit 7bab2d8ab38a8e27fe606e63eb7ae6f48181a492
          Author: Martijn Koster <mak-github@greenhills.co.uk>
          Date: 2015-03-25T08:18:28Z

          SOLR-7240 add redirect of / to /solr/, using the jetty rewrite module with a regex pattern


          Show
          ASF GitHub Bot added a comment - GitHub user makuk66 opened a pull request: https://github.com/apache/lucene-solr/pull/136 SOLR-7240 add redirect of / to /solr/ SOLR-7240 add redirect of / to /solr/, using the jetty rewrite module with a regex pattern With this patch, / (and only /) redirects to /solr/. Tested with `bin/solr -f` on OSX: ``` $ printf "GET / HTTP/1.0\r\n\r\n" | nc localhost 8983 HTTP/1.1 302 Found Location: http://127.0.0.1:8983/solr/ Content-Length: 0 $ printf "GET /solr/ HTTP/1.0\r\n\r\n" | nc localhost 8983 | grep '<title>' <title>Solr Admin</title> $ printf "GET /foo HTTP/1.0\r\n\r\n" | nc localhost 8983 | grep '<title>' <title>Error 404 Not Found</title> ``` You can merge this pull request into a Git repository by running: $ git pull https://github.com/makuk66/lucene-solr SOLR-7240 -redirect-slash-to-solr-squashed Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/136.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #136 commit 7bab2d8ab38a8e27fe606e63eb7ae6f48181a492 Author: Martijn Koster <mak-github@greenhills.co.uk> Date: 2015-03-25T08:18:28Z SOLR-7240 add redirect of / to /solr/, using the jetty rewrite module with a regex pattern
          Hide
          Hoss Man added a comment -

          Mak's patch is against 5x and looks appropriate for jetty8 – but on trunk, with jetty9, i know that "OPTIONS=..." syntax is no longer supported.

          inspired by mak's patch, i created this one for trunk. I thought we'd need to modifiy solr/server/start.ini, to include "rewrite" in the --module list, but when i tried that out i got an error in the logs that "rewrite" wasn't a valid module name, and regardless of that change hte rewrite worked – so i guess this handler is part of the core in jetty9? not sure.

          I'm running precommit now, i'll get this into trunk later today and then test mak's patch more thoroughly on the 5x branch.

          Show
          Hoss Man added a comment - Mak's patch is against 5x and looks appropriate for jetty8 – but on trunk, with jetty9, i know that "OPTIONS=..." syntax is no longer supported. inspired by mak's patch, i created this one for trunk. I thought we'd need to modifiy solr/server/start.ini, to include "rewrite" in the --module list, but when i tried that out i got an error in the logs that "rewrite" wasn't a valid module name, and regardless of that change hte rewrite worked – so i guess this handler is part of the core in jetty9? not sure. I'm running precommit now, i'll get this into trunk later today and then test mak's patch more thoroughly on the 5x branch.
          Hide
          ASF subversion and git services added a comment -

          Commit 1669431 from hossman@apache.org in branch 'dev/trunk'
          [ https://svn.apache.org/r1669431 ]

          SOLR-7240: '/' redirects to '/solr/' for convinience

          Show
          ASF subversion and git services added a comment - Commit 1669431 from hossman@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1669431 ] SOLR-7240 : '/' redirects to '/solr/' for convinience
          Hide
          ASF subversion and git services added a comment -

          Commit 1669433 from hossman@apache.org in branch 'dev/trunk'
          [ https://svn.apache.org/r1669433 ]

          SOLR-7240 CHANGES typo

          Show
          ASF subversion and git services added a comment - Commit 1669433 from hossman@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1669433 ] SOLR-7240 CHANGES typo
          Hide
          ASF subversion and git services added a comment -

          Commit 1669448 from hossman@apache.org in branch 'dev/trunk'
          [ https://svn.apache.org/r1669448 ]

          SOLR-7240 Another CHANGES typo .. sure ... why not.

          Show
          ASF subversion and git services added a comment - Commit 1669448 from hossman@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1669448 ] SOLR-7240 Another CHANGES typo .. sure ... why not.
          Hide
          ASF subversion and git services added a comment -

          Commit 1669452 from hossman@apache.org in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1669452 ]

          SOLR-7240: '/' redirects to '/solr/' for convenience (merge 1669431, 1669433, 1669448, This closes #136)

          Show
          ASF subversion and git services added a comment - Commit 1669452 from hossman@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1669452 ] SOLR-7240 : '/' redirects to '/solr/' for convenience (merge 1669431, 1669433, 1669448, This closes #136)
          Hide
          Timothy Potter added a comment -

          Solr won't start if using: java -jar start.jar

          [~/dev/lw/projects/br5x/solr/server]$ java -jar start.jar
          0    [main] WARN  org.eclipse.jetty.xml.XmlConfiguration  [] [] [] [] – Config error at <New id="RewriteHandler" class="org.eclipse.jetty.rewrite.handler.RewriteHandler"><Set name="rewriteRequestURI">true</Set><Set name="rewritePathInfo">false</Set><Set name="originalPathAttribute">requestedPath</Set><Call name="addRule"><Arg>
                   <New class="org.eclipse.jetty.rewrite.handler.RedirectRegexRule"><Set name="regex">^/$</Set><Set name="replacement">/solr/</Set></New>
                 </Arg></Call></New>
          java.lang.reflect.InvocationTargetException
              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.eclipse.jetty.start.Main.invokeMain(Main.java:473)
              at org.eclipse.jetty.start.Main.start(Main.java:615)
              at org.eclipse.jetty.start.Main.main(Main.java:96)
          Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.rewrite.handler.RewriteHandler
              at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
              at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
              at java.security.AccessController.doPrivileged(Native Method)
              at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
              at org.eclipse.jetty.util.Loader.loadClass(Loader.java:100)
              at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.nodeClass(XmlConfiguration.java:354)
              at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:754)
              at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:392)
              at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:343)
              at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:296)
              at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1247)
              at java.security.AccessController.doPrivileged(Native Method)
              at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1182)
              ... 7 more
          
          Usage: java -jar start.jar [options] [properties] [configs]
                java -jar start.jar --help  # for more information
          

          Of course, you should use bin/solr to start Solr, but I don't think we ever declared using java -jar start.jar is no longer supported?

          Show
          Timothy Potter added a comment - Solr won't start if using: java -jar start.jar [~/dev/lw/projects/br5x/solr/server]$ java -jar start.jar 0 [main] WARN org.eclipse.jetty.xml.XmlConfiguration [] [] [] [] – Config error at <New id= "RewriteHandler" class= "org.eclipse.jetty.rewrite.handler.RewriteHandler" ><Set name= "rewriteRequestURI" > true </Set><Set name= "rewritePathInfo" > false </Set><Set name= "originalPathAttribute" >requestedPath</Set><Call name= "addRule" ><Arg> <New class= "org.eclipse.jetty.rewrite.handler.RedirectRegexRule" ><Set name= "regex" >^/$</Set><Set name= "replacement" >/solr/</Set></New> </Arg></Call></New> java.lang.reflect.InvocationTargetException 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.eclipse.jetty.start.Main.invokeMain(Main.java:473) at org.eclipse.jetty.start.Main.start(Main.java:615) at org.eclipse.jetty.start.Main.main(Main.java:96) Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.rewrite.handler.RewriteHandler at java.net.URLClassLoader$1.run(URLClassLoader.java:372) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang. ClassLoader .loadClass( ClassLoader .java:424) at java.lang. ClassLoader .loadClass( ClassLoader .java:357) at org.eclipse.jetty.util.Loader.loadClass(Loader.java:100) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.nodeClass(XmlConfiguration.java:354) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:754) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:392) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:343) at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:296) at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1247) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1182) ... 7 more Usage: java -jar start.jar [options] [properties] [configs] java -jar start.jar --help # for more information Of course, you should use bin/solr to start Solr, but I don't think we ever declared using java -jar start.jar is no longer supported?
          Hide
          Timothy Potter added a comment -

          Marking this as a blocker for 5.1. Although bin/solr is the preferred method of starting Solr, using java -jar start.jar should still work.

          Show
          Timothy Potter added a comment - Marking this as a blocker for 5.1. Although bin/solr is the preferred method of starting Solr, using java -jar start.jar should still work.
          Hide
          Timothy Potter added a comment -

          Mak has proposed a solution for this: https://gist.github.com/makuk66/20c736ae47fc4993c461

          However, here's Chris Hostetter (Unused) take on this:
          "As of solr5 we very clearly document that the only supported way to run solr is bin/solr - we may not have ever explicitly said start.jar was no longer supported, but we shouldn't have ever needed to because it was never officially supported either - it was just an example of how to run solr in jetty.

          If we're going to hold back on stuff like this now, I don't see how were ever going to leave ourselves enough room to gradually replace the internals like we've talked about for a while, unless we commit to rolling our own start.jar

          I won't stand in the way if people think this is important, but I give up on trying to move past "solr is just a web app" if we worry about stuff like this."

          Show
          Timothy Potter added a comment - Mak has proposed a solution for this: https://gist.github.com/makuk66/20c736ae47fc4993c461 However, here's Chris Hostetter (Unused) take on this: "As of solr5 we very clearly document that the only supported way to run solr is bin/solr - we may not have ever explicitly said start.jar was no longer supported, but we shouldn't have ever needed to because it was never officially supported either - it was just an example of how to run solr in jetty. If we're going to hold back on stuff like this now, I don't see how were ever going to leave ourselves enough room to gradually replace the internals like we've talked about for a while, unless we commit to rolling our own start.jar I won't stand in the way if people think this is important, but I give up on trying to move past "solr is just a web app" if we worry about stuff like this."
          Hide
          Gus Heck added a comment -

          Scripts in solr/cloud-dev/ rely on start.jar... (and are broken right now)

          Show
          Gus Heck added a comment - Scripts in solr/cloud-dev/ rely on start.jar... (and are broken right now)
          Hide
          Timothy Potter added a comment -

          Ok, thanks Gus Heck ... problem is bigger than I realized

          Show
          Timothy Potter added a comment - Ok, thanks Gus Heck ... problem is bigger than I realized
          Hide
          Timothy Potter added a comment -

          Here's a patch that fixes this issue for branch5x.

          Still looking into how to fix for trunk b/c it runs on Jetty 9

          Show
          Timothy Potter added a comment - Here's a patch that fixes this issue for branch5x. Still looking into how to fix for trunk b/c it runs on Jetty 9
          Hide
          Gus Heck added a comment -

          hmm, you seem to have managed to link my old account (from when I worked at Olin College)... wonder how I can keep people from doing that, I have no access to it anymore.

          Show
          Gus Heck added a comment - hmm, you seem to have managed to link my old account (from when I worked at Olin College)... wonder how I can keep people from doing that, I have no access to it anymore.
          Hide
          Ramkumar Aiyengar added a comment -

          I am with Hoss on this one. But given that we have a patch for branch_5x, could we leave trunk broken and remove support for 5.2?

          Show
          Ramkumar Aiyengar added a comment - I am with Hoss on this one. But given that we have a patch for branch_5x, could we leave trunk broken and remove support for 5.2?
          Hide
          Timothy Potter added a comment -

          Thanks for chiming in Ramkumar Aiyengar ... I think trunk has been broken for a while because java -jar start.jar starts up Jetty 9, but doesn't deploy the WAR. I'm going to commit my fix for 5.1 to unblock that release and open a new JIRA to remove support for it in a later release.

          Show
          Timothy Potter added a comment - Thanks for chiming in Ramkumar Aiyengar ... I think trunk has been broken for a while because java -jar start.jar starts up Jetty 9, but doesn't deploy the WAR. I'm going to commit my fix for 5.1 to unblock that release and open a new JIRA to remove support for it in a later release.
          Hide
          ASF subversion and git services added a comment -

          Commit 1670788 from Timothy Potter in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1670788 ]

          SOLR-7240: add start.ini in the server directory so java -jar start.jar continues to work on Jetty 8

          Show
          ASF subversion and git services added a comment - Commit 1670788 from Timothy Potter in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1670788 ] SOLR-7240 : add start.ini in the server directory so java -jar start.jar continues to work on Jetty 8
          Hide
          ASF subversion and git services added a comment -

          Commit 1670793 from Timothy Potter in branch 'dev/branches/lucene_solr_5_1'
          [ https://svn.apache.org/r1670793 ]

          SOLR-7240: add start.ini in the server directory so java -jar start.jar continues to work on Jetty 8

          Show
          ASF subversion and git services added a comment - Commit 1670793 from Timothy Potter in branch 'dev/branches/lucene_solr_5_1' [ https://svn.apache.org/r1670793 ] SOLR-7240 : add start.ini in the server directory so java -jar start.jar continues to work on Jetty 8
          Hide
          Timothy Potter added a comment -

          java -jar start.jar works on 5.1 branch now ... but it will soon be an unsupported way to start solr after 5.1

          Show
          Timothy Potter added a comment - java -jar start.jar works on 5.1 branch now ... but it will soon be an unsupported way to start solr after 5.1
          Hide
          Timothy Potter added a comment -

          Bulk close after 5.1 release

          Show
          Timothy Potter added a comment - Bulk close after 5.1 release
          Hide
          Gus Heck added a comment -

          hmm, I'm noticing that the "trunk" patch for this (and 5.3.1 release files) contains these lines:

                      <Item>
          +             <Ref id="RewriteHandler"/>
          +           </Item>
          

          Is this part of the config working as expected? The documentation for Jetty seems to say that this shoud be

                      <Item>
          +             <Ref refid="RewriteHandler"/>
          +           </Item>
          

          If it's all working as expected then I guess the fact that Intellij flags an error here (duplicate id attributes) is not a big deal. However, if something is awry here maybe we need to open a new ticket to deal with it (since this one is already closed). I haven't (yet) run into a symptom, but this looks funny...

          Show
          Gus Heck added a comment - hmm, I'm noticing that the "trunk" patch for this (and 5.3.1 release files) contains these lines: <Item> + <Ref id= "RewriteHandler" /> + </Item> Is this part of the config working as expected? The documentation for Jetty seems to say that this shoud be <Item> + <Ref refid= "RewriteHandler" /> + </Item> If it's all working as expected then I guess the fact that Intellij flags an error here (duplicate id attributes) is not a big deal. However, if something is awry here maybe we need to open a new ticket to deal with it (since this one is already closed). I haven't (yet) run into a symptom, but this looks funny...
          Hide
          Uwe Schindler added a comment -

          I assume both will work for compatibility reasons. But IntelliJ is right, you cannot have duplicate id values. Same we know from ant: <javac classpathref="..."/> pointing to <classpath id="..."/>.

          Show
          Uwe Schindler added a comment - I assume both will work for compatibility reasons. But IntelliJ is right, you cannot have duplicate id values. Same we know from ant: <javac classpathref="..."/> pointing to <classpath id="..."/> .

            People

            • Assignee:
              Timothy Potter
              Reporter:
              Hoss Man
            • Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development