Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8.3
    • Fix Version/s: 2.10.0
    • Component/s: None
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      This ticket aims to resolve the issues already mentioned in [1], but just to name them ALL explicitly here:

      • Removal of the unused imports
      • Convert for loops to the enhanced one (supported since Java Tiger)
      • Removal of the obsolete "super();" call by the Constructors (Since JDK 1.0 compilers already do it inside the byte-code for free!)
      • Remove of all $NON-NLS$ tags
      • Removal of the unnecessary casts
      • Usage of the @Deprecated & @Override annotations where required (will be skipped because of the reasons Claus has already mentioned in his comment for the already provided patch)
      • Avoidance of the raw type declarations by the generified classes as much as possible
      • Removal of unused private memebers: Types, Constructors, Fields and Methods where applicable
      • Remove the trailing whitespace on all lines, even on the empty ones

      Add of missing serialVersionUID where required and default it to 1L where serialVersionUID has been already declared should be better postponed to the major 3.0.x release as otherwise the backward-compatility would be broken on the 2.x.y release branches.

      If you can think of other possible clean-ups as well you may like to propose for including, then please first better discuss it in [1] so that other commiters can better/faster/easier react on it.

      I'll provide the patches exactly in the same order as mentioned above.

      Right now on the trunk my used IDE (eclipse) reports 1991 warnings!

      [1] http://camel.465427.n5.nabble.com/DISCUSS-Trunk-Code-Cleanup-td5071594.html

      1. CAMEL-4796-@Deprecated-@Override.patch
        3.67 MB
        Babak Vahdat
      2. CAMEL-4796-avoid-rawtypes.patch
        169 kB
        Babak Vahdat
      3. CAMEL-4796-avoid-rawtypes-2.patch
        230 kB
        Babak Vahdat
      4. CAMEL-4796-avoid-rawtypes-3.patch
        199 kB
        Babak Vahdat
      5. CAMEL-4796-enhanced-for-loops.patch
        32 kB
        Babak Vahdat
      6. CAMEL-4796-obsolete-super-call.patch
        59 kB
        Babak Vahdat
      7. CAMEL-4796-organize-imports.patch
        157 kB
        Babak Vahdat
      8. CAMEL-4796-organize-imports-2.patch
        10 kB
        Babak Vahdat
      9. CAMEL-4796-remove-$NON-NLS$.patch
        6 kB
        Babak Vahdat
      10. CAMEL-4796-remove-unnecessary-casts.patch
        48 kB
        Babak Vahdat

        Issue Links

          Activity

          Hide
          Babak Vahdat added a comment - - edited

          Attached the first patch concerning "organize imports".

          Show
          Babak Vahdat added a comment - - edited Attached the first patch concerning "organize imports".
          Hide
          Hadrian Zbarcea added a comment -

          First patch (organize imports) reviewed and applied. Thanks Babak for patch.

          Show
          Hadrian Zbarcea added a comment - First patch (organize imports) reviewed and applied. Thanks Babak for patch.
          Hide
          Babak Vahdat added a comment - - edited

          Hadrian,

          Thanks for applying the patch into the trunk, but what was your idea exactly to change the "Affected Version" of this ticket from 2.9.1 to 2.8.3?

          AFAIK the 2.8.3 release is already out the door!

          Show
          Babak Vahdat added a comment - - edited Hadrian, Thanks for applying the patch into the trunk, but what was your idea exactly to change the "Affected Version" of this ticket from 2.9.1 to 2.8.3? AFAIK the 2.8.3 release is already out the door!
          Hide
          Hadrian Zbarcea added a comment -

          @Babak, you are correct. When we open an issue, we normally do so because it (negatively) affects an existing version (already out the door) and it will be fixed in, well, the "Fix Version/s", which will probably be 2.9.1 in this case.

          Show
          Hadrian Zbarcea added a comment - @Babak, you are correct. When we open an issue, we normally do so because it (negatively) affects an existing version (already out the door) and it will be fixed in, well, the "Fix Version/s", which will probably be 2.9.1 in this case.
          Hide
          Babak Vahdat added a comment - - edited

          My used IDE seems to be too shy to tell me the whole truth in one single shot. So attached CAMEL-4796-organize-imports-2.patch which captures another 9 sources.

          Please note that as for example it's the case in [1] or [2] I don't aim to touch the sources where the import(s) has been commented out on purpose.

          [1] https://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/jpa/JpaBlueprintRouteTest.java
          [2] https://svn.apache.org/repos/asf/camel/trunk/examples/camel-example-cxf-tomcat/src/main/java/org/apache/camel/example/cxf/CamelRoute.java

          Show
          Babak Vahdat added a comment - - edited My used IDE seems to be too shy to tell me the whole truth in one single shot. So attached CAMEL-4796 -organize-imports-2.patch which captures another 9 sources. Please note that as for example it's the case in [1] or [2] I don't aim to touch the sources where the import(s) has been commented out on purpose . [1] https://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/jpa/JpaBlueprintRouteTest.java [2] https://svn.apache.org/repos/asf/camel/trunk/examples/camel-example-cxf-tomcat/src/main/java/org/apache/camel/example/cxf/CamelRoute.java
          Hide
          Babak Vahdat added a comment -

          Attached the third patch concerning "enhanced for loops".
          Please note that CAMEL-4796-organize-imports-2.patch is also still pending to be committed.

          Show
          Babak Vahdat added a comment - Attached the third patch concerning "enhanced for loops". Please note that CAMEL-4796 -organize-imports-2.patch is also still pending to be committed.
          Hide
          Babak Vahdat added a comment -

          Can someone please assist me on this ticket to commit, as otherwise the longer it's not applied to the trunk the more likley it will cause svn-conflicts to be resolved manually before committing!

          Currenty there're both

          which are pending.

          Show
          Babak Vahdat added a comment - Can someone please assist me on this ticket to commit, as otherwise the longer it's not applied to the trunk the more likley it will cause svn-conflicts to be resolved manually before committing! Currenty there're both CAMEL-4796 -organize-imports-2.patch CAMEL-4796 -enhanced-for-loops.patch which are pending.
          Hide
          Claus Ibsen added a comment -

          Babak can you create a new patch from the root of the camel source code, so the path have full paths? Currently the first path is missing, eg camel-core, and so forth. This makes it much harder to apply the patches.
          I was trying the foor loop patch.

          Show
          Claus Ibsen added a comment - Babak can you create a new patch from the root of the camel source code, so the path have full paths? Currently the first path is missing, eg camel-core, and so forth. This makes it much harder to apply the patches. I was trying the foor loop patch.
          Hide
          Babak Vahdat added a comment -

          It's done!

          Show
          Babak Vahdat added a comment - It's done!
          Hide
          Claus Ibsen added a comment -

          The import-2 patch is now applied to trunk.

          Show
          Claus Ibsen added a comment - The import-2 patch is now applied to trunk.
          Hide
          Claus Ibsen added a comment -

          Thanks will apply the for loop, just checking the stuff can compile first.

          Show
          Claus Ibsen added a comment - Thanks will apply the for loop, just checking the stuff can compile first.
          Hide
          Claus Ibsen added a comment -

          I have applied the for-loop patch. Thanks.

          Show
          Claus Ibsen added a comment - I have applied the for-loop patch. Thanks.
          Hide
          Babak Vahdat added a comment -

          Thanks a lot for your HELP!

          BTW, we've got checkstyle violation(s) on trunk by ManagedRouteAddRemoveTest.

          Another thing I've also realized is that on checkstyle-rules [1] we permit a max-line-length of 200 on eclipse-code-formatter-setting however just 180 [2]. However this's COMPLETELY another story.

          [1] https://svn.apache.org/repos/asf/camel/trunk/buildingtools/camel-checkstyle.xml
          [2] https://svn.apache.org/repos/asf/camel/trunk/etc/eclipse/CamelCodeFormatter.xml

          Show
          Babak Vahdat added a comment - Thanks a lot for your HELP! BTW, we've got checkstyle violation(s) on trunk by ManagedRouteAddRemoveTest. Another thing I've also realized is that on checkstyle-rules [1] we permit a max-line-length of 200 on eclipse-code-formatter-setting however just 180 [2] . However this's COMPLETELY another story. [1] https://svn.apache.org/repos/asf/camel/trunk/buildingtools/camel-checkstyle.xml [2] https://svn.apache.org/repos/asf/camel/trunk/etc/eclipse/CamelCodeFormatter.xml
          Hide
          Babak Vahdat added a comment -

          Claus,

          Why did you mark the ticket as Fixed?! In the context of this ticket there's much more work to be done, see the Description field!
          Anyway I reopened it again.

          BTW, today I traced the tough & hard work you've done, mostly because of the memory-leak issue. Thanks for the QOS you provide for the Apache Camel!

          Show
          Babak Vahdat added a comment - Claus, Why did you mark the ticket as Fixed?! In the context of this ticket there's much more work to be done, see the Description field! Anyway I reopened it again. BTW, today I traced the tough & hard work you've done, mostly because of the memory-leak issue. Thanks for the QOS you provide for the Apache Camel!
          Hide
          Babak Vahdat added a comment -

          Attached the fourth patch regarding the obsolete super() calls. The provided patch additionally does

          • remove the obsolete this() call in bunch of the places
          • remove the explicit default constructor declarations in bunch of the places (since JDK 1.0 compilers already generates that as well, if no other constructor is defined)
          • remove some obsoletly declared constructors on test classes as well like ApnsProducerWithoutTokensHeaderTest or ApnsProducerTest

          So to say it's all about constructor-clean-ups.

          Show
          Babak Vahdat added a comment - Attached the fourth patch regarding the obsolete super() calls. The provided patch additionally does remove the obsolete this() call in bunch of the places remove the explicit default constructor declarations in bunch of the places (since JDK 1.0 compilers already generates that as well, if no other constructor is defined) remove some obsoletly declared constructors on test classes as well like ApnsProducerWithoutTokensHeaderTest or ApnsProducerTest So to say it's all about constructor-clean-ups.
          Hide
          Claus Ibsen added a comment -

          Thanks, I have applied the ctr patch.

          Show
          Claus Ibsen added a comment - Thanks, I have applied the ctr patch.
          Hide
          Babak Vahdat added a comment -

          Attached CAMEL-4796remove$NON-NLS$.patch as the next patch by the series addressed. O.K. I confess this one was really trivial

          Show
          Babak Vahdat added a comment - Attached CAMEL-4796 remove $NON-NLS$.patch as the next patch by the series addressed. O.K. I confess this one was really trivial
          Hide
          Claus Ibsen added a comment -

          Thanks for the non patch.

          Show
          Claus Ibsen added a comment - Thanks for the non patch.
          Hide
          Babak Vahdat added a comment -

          Attached please find the next Patch in the series regarding the removal of the unnecessary casts.

          Show
          Babak Vahdat added a comment - Attached please find the next Patch in the series regarding the removal of the unnecessary casts.
          Hide
          Claus Ibsen added a comment -

          Applied the cast patch.

          Show
          Claus Ibsen added a comment - Applied the cast patch.
          Hide
          Babak Vahdat added a comment -

          Attached please find the next patch in the series regarding the usage of the @Deprecated & @Override annotations. I admit that this patch is pretty big BUT IMHO it's verification
          could be done in some extend automatically / easier:

          $> grep "+   "  CAMEL-4796-@Deprecated-@Override.patch | less
          

          Then you will see by more than 95% only the lines like:

          +    @Override
          +    @Override
          +    @Override
          +    @Deprecated
          +    @Override
          +    @Override
          +            @Override
          +        @Override
          +    @Override
          +    @Deprecated
          +                    @Override
          +    @Override
          +        @Override
          +    @Override
          +    @Override
          +            @Override
          +        @Override
          +    @Override
          +    @Override
          +    @Override
          +    @Deprecated
          +            @Override
          +    @Override
          +            @Override
          +            @Override
          +                    @Override
          +        @Override
          

          However you will still catch some lines like:

          +    @Override
          +      @Override
          +    protected org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.Person internalGetResult() {
          +      @Override
          +    public Builder clear() {
          +      @Override
          +    public Builder clone() {
          +      @Override
          +    public com.google.protobuf.Descriptors.Descriptor
          +      @Override
          +    public org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.Person getDefaultInstanceForType() {
          +      @Override
          +    public boolean isInitialized() {
          +      @Override
          +    public org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.Person build() {
          +      @Override
          +    public org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.Person buildPartial() {
          +      @Override
          +    public Builder mergeFrom(com.google.protobuf.Message other) {
          +      @Override
          +    public Builder mergeFrom(
          +    @Override
          +    @Override
          +    @Override
          +    @Override
          +    @Override
          +    @Override
          +    @Override
          +      @Override
          +    protected org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.AddressBook internalGetResult() {
          +      @Override
          

          where unfortunately you would have to verify it manually/visually

          So to check such lines doing:

          grep "+   "  CAMEL-4796-@Deprecated-@Override.patch | grep -v @Override | grep -v @Deprecated
          

          Should do the trick, which are really not too much lines (only 85 lines):

          grep "+   "  CAMEL-4796-@Deprecated-@Override.patch | grep -v @Override | grep -v @Deprecated | wc -l
          

          Other than add of the missing @Override & @Deprecated annotations there's one semantic change I also made by the class

          org.apache.camel.management.mbean.ManagedRoute
          

          I commented on the last revision on this [1] however didn't hear anything from Dan in @Dev Forum. Later on however we exchaneged some mails between me and him
          and talked about all other possible stuff but not really about his revision. If the commiter who intends to apply this patch doesn't agree with me on this then
          simply skip the change on this class

          Also please note that the semantics of the @Override annotation has been extended by the JDK 1.5 ==> JDK 1.6 transition [2]. The javadoc in JDK 1.6 doesn't reflect this
          fact but the JDK 1.7 [3] does it! So if we claim that we use/rely on JDK 1.6+ then IMHO we should respect it's complete semantics as well.

          [1] http://camel.465427.n5.nabble.com/The-last-revision-on-the-ManagedRoute-shutdown-JMX-API-td5098934.html#a5102867
          [2] http://blogs.oracle.com/ahe/entry/override_snafu
          [3] http://docs.oracle.com/javase/7/docs/api/java/lang/Override.html

          Show
          Babak Vahdat added a comment - Attached please find the next patch in the series regarding the usage of the @Deprecated & @Override annotations. I admit that this patch is pretty big BUT IMHO it's verification could be done in some extend automatically / easier : $> grep "+ " CAMEL-4796-@Deprecated-@Override.patch | less Then you will see by more than 95% only the lines like: + @Override + @Override + @Override + @Deprecated + @Override + @Override + @Override + @Override + @Override + @Deprecated + @Override + @Override + @Override + @Override + @Override + @Override + @Override + @Override + @Override + @Override + @Deprecated + @Override + @Override + @Override + @Override + @Override + @Override However you will still catch some lines like: + @Override + @Override + protected org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.Person internalGetResult() { + @Override + public Builder clear() { + @Override + public Builder clone() { + @Override + public com.google.protobuf.Descriptors.Descriptor + @Override + public org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.Person getDefaultInstanceForType() { + @Override + public boolean isInitialized() { + @Override + public org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.Person build() { + @Override + public org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.Person buildPartial() { + @Override + public Builder mergeFrom(com.google.protobuf.Message other) { + @Override + public Builder mergeFrom( + @Override + @Override + @Override + @Override + @Override + @Override + @Override + @Override + protected org.apache.camel.dataformat.protobuf.generated.AddressBookProtos.AddressBook internalGetResult() { + @Override where unfortunately you would have to verify it manually/visually So to check such lines doing: grep "+ " CAMEL-4796-@Deprecated-@Override.patch | grep -v @Override | grep -v @Deprecated Should do the trick, which are really not too much lines (only 85 lines): grep "+ " CAMEL-4796-@Deprecated-@Override.patch | grep -v @Override | grep -v @Deprecated | wc -l Other than add of the missing @Override & @Deprecated annotations there's one semantic change I also made by the class org.apache.camel.management.mbean.ManagedRoute I commented on the last revision on this [1] however didn't hear anything from Dan in @Dev Forum. Later on however we exchaneged some mails between me and him and talked about all other possible stuff but not really about his revision. If the commiter who intends to apply this patch doesn't agree with me on this then simply skip the change on this class Also please note that the semantics of the @Override annotation has been extended by the JDK 1.5 ==> JDK 1.6 transition [2] . The javadoc in JDK 1.6 doesn't reflect this fact but the JDK 1.7 [3] does it! So if we claim that we use/rely on JDK 1.6+ then IMHO we should respect it's complete semantics as well. [1] http://camel.465427.n5.nabble.com/The-last-revision-on-the-ManagedRoute-shutdown-JMX-API-td5098934.html#a5102867 [2] http://blogs.oracle.com/ahe/entry/override_snafu [3] http://docs.oracle.com/javase/7/docs/api/java/lang/Override.html
          Hide
          Claus Ibsen added a comment -

          The big patch I do not think is a good idea to apply on the 2.x versions. It touches almost all files, makes backporting patches more problematic due source code difference.

          For Camel 3.0 we can do this. Like we should also remove all the @version from the javadoc, as they are pointless also.

          So I suggest to work on minor code cleanups for 2.x. And postpone the big changes for 3.0.

          Show
          Claus Ibsen added a comment - The big patch I do not think is a good idea to apply on the 2.x versions. It touches almost all files, makes backporting patches more problematic due source code difference. For Camel 3.0 we can do this. Like we should also remove all the @version from the javadoc, as they are pointless also. So I suggest to work on minor code cleanups for 2.x. And postpone the big changes for 3.0.
          Hide
          Babak Vahdat added a comment -

          O.K. fair enough, but would you mind to apply only the change on

          org.apache.camel.management.mbean.ManagedRoute
          

          If you do agree on what I already proposed in [1]?

          It means that the 2 shutdown methods will remain exactly the same as the revision 1210806 but with the additional @Deprecated annotation on top of them.

          [1] http://camel.465427.n5.nabble.com/The-last-revision-on-the-ManagedRoute-shutdown-JMX-API-td5098934.html#a5102867

          Show
          Babak Vahdat added a comment - O.K. fair enough, but would you mind to apply only the change on org.apache.camel.management.mbean.ManagedRoute If you do agree on what I already proposed in [1] ? It means that the 2 shutdown methods will remain exactly the same as the revision 1210806 but with the additional @Deprecated annotation on top of them. [1] http://camel.465427.n5.nabble.com/The-last-revision-on-the-ManagedRoute-shutdown-JMX-API-td5098934.html#a5102867
          Hide
          Babak Vahdat added a comment -

          Attached the next patch regarding avoidance of the raw types by the generified classes (still much more to follow for this issue).

          The patch also includes:

          • one pre-existing checkstyle violation on the trunk
          • removal of unused imports being introduced into the trunk since the first provided patch by this ticket
          Show
          Babak Vahdat added a comment - Attached the next patch regarding avoidance of the raw types by the generified classes (still much more to follow for this issue). The patch also includes: one pre-existing checkstyle violation on the trunk removal of unused imports being introduced into the trunk since the first provided patch by this ticket
          Hide
          Hadrian Zbarcea added a comment - - edited

          I am reviewing and testing the last patch now (avoid-rawtypes). For a few obvious reasons, I will do a full test on it, so it'll take a few good hours. Thanks for the patience.

          Update: patch applied. There are so many changes in this issue that we should consider marking it resolved and start another one for the remaining points.

          Show
          Hadrian Zbarcea added a comment - - edited I am reviewing and testing the last patch now (avoid-rawtypes). For a few obvious reasons, I will do a full test on it, so it'll take a few good hours. Thanks for the patience. Update: patch applied. There are so many changes in this issue that we should consider marking it resolved and start another one for the remaining points.
          Hide
          Babak Vahdat added a comment -

          @Hadrian

          as soon as the currently running "avoid-rawtypes" task is resolved I'll close this ticket (as you've suggested) and will create a new ticket for the rest.

          Show
          Babak Vahdat added a comment - @Hadrian as soon as the currently running "avoid-rawtypes" task is resolved I'll close this ticket (as you've suggested) and will create a new ticket for the rest.
          Hide
          Babak Vahdat added a comment -

          Attached the next patch regarding avoidance of the raw types by the generified classes number 2.

          The patch also includes many pre-existing checkstyle violation on the trunk.

          Show
          Babak Vahdat added a comment - Attached the next patch regarding avoidance of the raw types by the generified classes number 2. The patch also includes many pre-existing checkstyle violation on the trunk.
          Hide
          Hadrian Zbarcea added a comment -

          Babak, now looking into your 2nd patch.

          Show
          Hadrian Zbarcea added a comment - Babak, now looking into your 2nd patch.
          Hide
          Babak Vahdat added a comment -

          Thanks Hadrian!

          Just be aware that you will have to resolve some svn conflicts on camel-krati manually. Although I commented that I'm gone fix the checkstyle issues on CAMEL-4889, Ioannis decided to apply the fixes by himself. However the applied patch of him lacks an explicit serialVersionUID by 2 Serializable classes which is already included by this patch. Good to know that compilers nowadays warn on this as well

          Show
          Babak Vahdat added a comment - Thanks Hadrian! Just be aware that you will have to resolve some svn conflicts on camel-krati manually. Although I commented that I'm gone fix the checkstyle issues on CAMEL-4889 , Ioannis decided to apply the fixes by himself. However the applied patch of him lacks an explicit serialVersionUID by 2 Serializable classes which is already included by this patch. Good to know that compilers nowadays warn on this as well
          Hide
          Hadrian Zbarcea added a comment -

          Babak, I applied your second patch. It had only one problem which I took the liberty to fix. In MockEndpoint for the expectedBodiesReceived* once you changed the parameter type from List to List<Object>, when a call was made with say a List<String> the other overloaded version that takes (Object...) was called. Changing the parameter type to List<?> was my only change.

          Show
          Hadrian Zbarcea added a comment - Babak, I applied your second patch. It had only one problem which I took the liberty to fix. In MockEndpoint for the expectedBodiesReceived* once you changed the parameter type from List to List<Object>, when a call was made with say a List<String> the other overloaded version that takes (Object...) was called. Changing the parameter type to List<?> was my only change.
          Hide
          Babak Vahdat added a comment - - edited

          Attached the 3rd & last patch regarding avoidance of the raw types by the generified classes. The patch also includes:

          • more utility methods by TryDefinition, ProxyHelper and ProxyBuilder (avoiding compiler warnings where there's only one single Class object parameter)
          • one checkstyle fix by ScheduledBatchPollingConsumer (CAMEL-4577)
          • fixed the deprecated usage of org.springframework.security.core.authority.SimpleGrantedAuthority in SpringSecurityAuthorizationPolicyTest
          • add of serialVersionUID where required but only by the unit-testing relevant classes (causing no backward-compatibility issue)

          Note: By the beginning of this ticket I used to see 1991 compiler warnings in total (see the Description field of this ticket), however currently I see only 346 left!

          Show
          Babak Vahdat added a comment - - edited Attached the 3rd & last patch regarding avoidance of the raw types by the generified classes. The patch also includes: more utility methods by TryDefinition, ProxyHelper and ProxyBuilder (avoiding compiler warnings where there's only one single Class object parameter) one checkstyle fix by ScheduledBatchPollingConsumer ( CAMEL-4577 ) fixed the deprecated usage of org.springframework.security.core.authority.SimpleGrantedAuthority in SpringSecurityAuthorizationPolicyTest add of serialVersionUID where required but only by the unit-testing relevant classes (causing no backward-compatibility issue) Note: By the beginning of this ticket I used to see 1991 compiler warnings in total (see the Description field of this ticket), however currently I see only 346 left!
          Hide
          Claus Ibsen added a comment -

          Applied the raw 3 patch.

          Show
          Claus Ibsen added a comment - Applied the raw 3 patch.
          Hide
          Babak Vahdat added a comment -

          Thanks Claus!
          Wish you a relaxing Sunday

          Show
          Babak Vahdat added a comment - Thanks Claus! Wish you a relaxing Sunday
          Hide
          Claus Ibsen added a comment -

          Okay new cleanup stuff should be in new JIRA tickets, as this one is a big one now . Thanks for all the cleanup stuff.

          Show
          Claus Ibsen added a comment - Okay new cleanup stuff should be in new JIRA tickets, as this one is a big one now . Thanks for all the cleanup stuff.
          Hide
          Babak Vahdat added a comment -

          Thanks Claus for closing this ticket as it was what I forgot to do

          Show
          Babak Vahdat added a comment - Thanks Claus for closing this ticket as it was what I forgot to do

            People

            • Assignee:
              Babak Vahdat
              Reporter:
              Babak Vahdat
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development