IvyDE
  1. IvyDE
  2. IVYDE-121

IVYDE classpath container should support bundle types by default

    Details

    • Type: Wish Wish
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0.alpha1
    • Fix Version/s: 2.0.0.beta1
    • Component/s: classpath container
    • Labels:
      None

      Description

      By default, the ivy classpath container does not support bundle types as jar files.
      These are generated automatically by Ivy 2.0 RC1 (and higher) when importing maven POMs to an ivy repository.

      Sample based on http://repo1.maven.org/maven2/org/springframework/ws/spring-oxm-tiger/1.5.4/spring-oxm-tiger-1.5.4.pom

      <publications>
      <artifact name="spring-oxm-tiger" type="bundle" ext="jar" conf="master"/>
      <artifact name="spring-oxm-tiger" type="source" ext="jar" conf="sources" m:classifier="sources"/>
      <artifact name="spring-oxm-tiger" type="javadoc" ext="jar" conf="javadoc" m:classifier="javadoc"/>
      </publications>
      

      The result is that the jar file is resolved from the ivy file, but not shown in the classpath container.

        Activity

        Hide
        Nicolas Lalevée added a comment -

        Have you tried to add "bundle" to the list of "Accepted types" ?
        Look into the advanced tab or the global configuration, and change the "Accepted types" field so you have something like "jar,bundle".

        Show
        Nicolas Lalevée added a comment - Have you tried to add "bundle" to the list of "Accepted types" ? Look into the advanced tab or the global configuration , and change the "Accepted types" field so you have something like "jar,bundle".
        Hide
        Erik-Berndt Scheper added a comment -

        You are right, by setting

        Accepted types = jar,bundle

        in the ivy preferences, bundle files are shown in the classpath container.

        I've edited this issue to a 'wish' instead of a bug.

        I believe bundle files should be shown by default in the classpath container. The reason is that we will most likely see many more bundles in the future, with the increased popularity of OSGi.

        Show
        Erik-Berndt Scheper added a comment - You are right, by setting Accepted types = jar,bundle in the ivy preferences, bundle files are shown in the classpath container. I've edited this issue to a 'wish' instead of a bug. I believe bundle files should be shown by default in the classpath container. The reason is that we will most likely see many more bundles in the future, with the increased popularity of OSGi.
        Hide
        Nicolas Lalevée added a comment -

        Now the default is "jar,bundle".

        Show
        Nicolas Lalevée added a comment - Now the default is "jar,bundle".
        Hide
        Maarten Coene added a comment -

        Why not accept all types by default?

        Show
        Maarten Coene added a comment - Why not accept all types by default?
        Hide
        Nicolas Lalevée added a comment -

        Because type like "source" or "javadoc" should not be added to the classpath but only attached to the actual "jar" or "bundle".

        Show
        Nicolas Lalevée added a comment - Because type like "source" or "javadoc" should not be added to the classpath but only attached to the actual "jar" or "bundle".
        Hide
        Erik-Berndt Scheper added a comment - - edited

        Well, I wouldn't like to have the javadoc and source types included in the classpath container.

        What might be an option is by default to include anything else than the types configured as source/javadoc types.
        I.e something like a checkbox with label "Include all other types"
        If this checkbox is enabled, then the input box where the user can enter the accepted types should be disabled
        If this checkbox is disabled, then the input box where the user can enter the accepted types should be enabled (with jar, bundle as default).

        Show
        Erik-Berndt Scheper added a comment - - edited Well, I wouldn't like to have the javadoc and source types included in the classpath container. What might be an option is by default to include anything else than the types configured as source/javadoc types. I.e something like a checkbox with label "Include all other types" If this checkbox is enabled, then the input box where the user can enter the accepted types should be disabled If this checkbox is disabled, then the input box where the user can enter the accepted types should be enabled (with jar, bundle as default).
        Hide
        Nicolas Lalevée added a comment -

        The current UI allow you to specify as many type as you want, there is no feature missing here. What you are suggesting is about a use case where there will be so many different kind of type that have to be included to the classpath that the "accept" logic should be reverse: we would need an excluding a list more than an accepting a list.
        But I don't know such use case. So it seems to me a useless complication of the UI.

        Show
        Nicolas Lalevée added a comment - The current UI allow you to specify as many type as you want, there is no feature missing here. What you are suggesting is about a use case where there will be so many different kind of type that have to be included to the classpath that the "accept" logic should be reverse: we would need an excluding a list more than an accepting a list. But I don't know such use case. So it seems to me a useless complication of the UI.
        Hide
        Maarten Coene added a comment -

        You should also include the other types from maven2 that have "jar" extension. (See the Ivy pom parser code for a list of these types)
        Maybe you could by default accept all types, but only add the files with a ".jar" extension to the classpath?

        Show
        Maarten Coene added a comment - You should also include the other types from maven2 that have "jar" extension. (See the Ivy pom parser code for a list of these types) Maybe you could by default accept all types, but only add the files with a ".jar" extension to the classpath?
        Hide
        Nicolas Lalevée added a comment - - edited

        We cannot accept every type with a .jar extension, because it will include sources and javadocs (at least for the default maven repositories).
        I have looked to the pom parser, I have found two other types ("ejb" and "maven-plugin"), and I have added them to the default conf.

        Show
        Nicolas Lalevée added a comment - - edited We cannot accept every type with a .jar extension, because it will include sources and javadocs (at least for the default maven repositories). I have looked to the pom parser, I have found two other types ("ejb" and "maven-plugin"), and I have added them to the default conf.
        Hide
        Erik-Berndt Scheper added a comment -

        That should do for the moment, I believe.

        Maybe it's a good idea to add some documentation comment to the Pom parser in ivy, that if extra types are added there, that they should be added to ivyde as well.

        Show
        Erik-Berndt Scheper added a comment - That should do for the moment, I believe. Maybe it's a good idea to add some documentation comment to the Pom parser in ivy, that if extra types are added there, that they should be added to ivyde as well.
        Hide
        Maarten Coene added a comment -

        It will still be the cause of problems when you have defined additional types in your own ivy.xml files.
        In one of my previous jobs, we had defined some extra types and it was this setting that caused a lot of problems with the usage of IvyDE, especially when new types were added.

        Show
        Maarten Coene added a comment - It will still be the cause of problems when you have defined additional types in your own ivy.xml files. In one of my previous jobs, we had defined some extra types and it was this setting that caused a lot of problems with the usage of IvyDE, especially when new types were added.
        Hide
        Erik-Berndt Scheper added a comment -

        I agree, but then we must think of a way to express that in the UI, that is not over complicated.
        I've suggested an option above, but maybe you have a better idea?

        Show
        Erik-Berndt Scheper added a comment - I agree, but then we must think of a way to express that in the UI, that is not over complicated. I've suggested an option above, but maybe you have a better idea?

          People

          • Assignee:
            Nicolas Lalevée
            Reporter:
            Erik-Berndt Scheper
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development