CloudStack
  1. CloudStack
  2. CLOUDSTACK-212

Switch java package structure from com.cloud to org.apache

    Details

    • Type: Improvement Improvement
    • Status: In Progress
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: pre-4.0.0
    • Fix Version/s: Future
    • Component/s: None
    • Security Level: Public (Anyone can view this level - this is the default.)
    • Labels:
      None

      Description

      Since the project has moved over to ASF, I'd like to suggest that we move from com.cloud to org.apache for the java package structure of our modules.

      If there is agreement, we can take this up after 4.0 is out the door.

        Activity

        Hide
        Mice Xia added a comment -

        +1

        hard code strings consists of 'cloud.com' in the source codes
        should be also be addressed

        -Mice

        Show
        Mice Xia added a comment - +1 hard code strings consists of ' cloud.com ' in the source codes should be also be addressed -Mice
        Hide
        Rohit Yadav added a comment -

        This will possible make things backward incompatible, any platform that uses CS won't work, may cause unknown exceptions and may break at several places, certainly if changed in DB (all internal names, offerings have Cloud.com- prefix etc.). If we agree to do this, may be target for next major release, 5.0?

        Show
        Rohit Yadav added a comment - This will possible make things backward incompatible, any platform that uses CS won't work, may cause unknown exceptions and may break at several places, certainly if changed in DB (all internal names, offerings have Cloud.com- prefix etc.). If we agree to do this, may be target for next major release, 5.0?
        Hide
        Manikanta Swamy K added a comment -

        If backward incompatibility is the problem we should solve it here itself since after going out with 4.0 as ASF release the number of implementations of CS are bound to increase and changing the structure in 5.0 would face heavy criticism and magnitude of compatibility issues(quantity not unique) will be heavy.

        It would be better to change it soon as people are expecting there will be a lot of change in the 4.0 vs the previous releases.

        +1

        Manikanta.

        Show
        Manikanta Swamy K added a comment - If backward incompatibility is the problem we should solve it here itself since after going out with 4.0 as ASF release the number of implementations of CS are bound to increase and changing the structure in 5.0 would face heavy criticism and magnitude of compatibility issues(quantity not unique) will be heavy. It would be better to change it soon as people are expecting there will be a lot of change in the 4.0 vs the previous releases. +1 Manikanta.
        Hide
        Chip Childers added a comment -

        Fair perspective Manikanta, but I'm personally hesitant to have us add another aspect of work to getting 4.0 finally out the door. I also think this is a purely housekeeping issue, since cloudstack isn't really designed as a java library that people integrate with. The API is the canonical integration method for "standard use" of the system.

        Show
        Chip Childers added a comment - Fair perspective Manikanta, but I'm personally hesitant to have us add another aspect of work to getting 4.0 finally out the door. I also think this is a purely housekeeping issue, since cloudstack isn't really designed as a java library that people integrate with. The API is the canonical integration method for "standard use" of the system.
        Hide
        Noah Slater added a comment -

        How much work would it likely to be? Agree with Manikanta that as many breaking changes should happen up front, where sensible.

        Show
        Noah Slater added a comment - How much work would it likely to be? Agree with Manikanta that as many breaking changes should happen up front, where sensible.
        Hide
        Chip Childers added a comment -

        It would be fairly significant in the code itself, and my position is that the issue of code linking to cloudstack compiled source files is minimal. IMO, people don't use the project that way. It's not intended to be a library.

        Show
        Chip Childers added a comment - It would be fairly significant in the code itself, and my position is that the issue of code linking to cloudstack compiled source files is minimal. IMO, people don't use the project that way. It's not intended to be a library.
        Hide
        Noah Slater added a comment -

        Let's punt it to post-4.0 then!

        Show
        Noah Slater added a comment - Let's punt it to post-4.0 then!
        Hide
        Rohit Yadav added a comment -

        I moved a lot of classes org.apache.cloudstack from com.cloud in cloud-api in api_refactoring. To avoid merge conflicts and with people submitting their patches, what we should do is to switch to package name org.apache.cloudstack after the code freeze for 4.1.0, I think if we do that it would ensure minimal issues for any contributor (developer or committer). Discuss, or comment, maybe on ML? (Lastly, technical suggestion to avoid using Eclipse for that kind of rename refactoring as it tends to miss any text or non-java files, I would recommend IDEA CE which I'd used for work in api_refactoring.)

        Show
        Rohit Yadav added a comment - I moved a lot of classes org.apache.cloudstack from com.cloud in cloud-api in api_refactoring. To avoid merge conflicts and with people submitting their patches, what we should do is to switch to package name org.apache.cloudstack after the code freeze for 4.1.0, I think if we do that it would ensure minimal issues for any contributor (developer or committer). Discuss, or comment, maybe on ML? (Lastly, technical suggestion to avoid using Eclipse for that kind of rename refactoring as it tends to miss any text or non-java files, I would recommend IDEA CE which I'd used for work in api_refactoring.)
        Hide
        Chip Childers added a comment -

        Rohit,

        Thinking about the overall scope of what's happening for 4.1, and the relative priority of this one (plus it's risk), I'd propose that we don't do it for 4.1.

        However, your thinking about this happening after the 4.1 code freeze is excellent. I believe that this should occur as one of the first steps for 4.2. After we create a release branch for 4.1, master basically frees up for 4.2 activity.

        I'm going to shift the fix version to 4.2, but do you want to come up with a strategy for fixing this and propose on the ML?

        Show
        Chip Childers added a comment - Rohit, Thinking about the overall scope of what's happening for 4.1, and the relative priority of this one (plus it's risk), I'd propose that we don't do it for 4.1. However, your thinking about this happening after the 4.1 code freeze is excellent. I believe that this should occur as one of the first steps for 4.2. After we create a release branch for 4.1, master basically frees up for 4.2 activity. I'm going to shift the fix version to 4.2, but do you want to come up with a strategy for fixing this and propose on the ML?
        Hide
        Rohit Yadav added a comment -

        Oh, I already did a lot of grouping and rearragement of pkg structure limited to cloud-api only, mostly the cmd, response and test classes. api_refactoring will have such rename refactors and a lot of new stuff from javelin, so any new stuff (for ex. javelin is already following this), should be in pkg org.apache.cloudstack

        You're right, so I'll stop any further pkg rename refactoring and we can slowly move it to org.apache.cloudstack. If we'll have time we can move it before 4.1 release otherwise it will be more practical to aim for 4.2, on master

        Show
        Rohit Yadav added a comment - Oh, I already did a lot of grouping and rearragement of pkg structure limited to cloud-api only, mostly the cmd, response and test classes. api_refactoring will have such rename refactors and a lot of new stuff from javelin, so any new stuff (for ex. javelin is already following this), should be in pkg org.apache.cloudstack You're right, so I'll stop any further pkg rename refactoring and we can slowly move it to org.apache.cloudstack. If we'll have time we can move it before 4.1 release otherwise it will be more practical to aim for 4.2, on master
        Hide
        Animesh Chaturvedi added a comment -

        Dharmesh are you planning this for 4.2?

        Show
        Animesh Chaturvedi added a comment - Dharmesh are you planning this for 4.2?
        Hide
        Dharmesh Kakadia added a comment -

        Animesh Chaturvedi Yes. I am waiting for code freeze, otherwise merging the new code might be difficult. Suggestions ?

        Show
        Dharmesh Kakadia added a comment - Animesh Chaturvedi Yes. I am waiting for code freeze, otherwise merging the new code might be difficult. Suggestions ?
        Hide
        ASF subversion and git services added a comment -

        Commit 2091852175797eeed0c3952f4fd3da74a13fb623 in branch refs/heads/master from Hiroaki Kawai
        [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2091852 ]

        CLOUDSTACK-212: migrate the namespace (network-ssp-plugin)

        migrate the ssp plugin namespace from com.cloud to org.apache.cloudstack

        Signed-off-by: Hiroaki KAWAI <kawai@stratosphere.co.jp>

        Show
        ASF subversion and git services added a comment - Commit 2091852175797eeed0c3952f4fd3da74a13fb623 in branch refs/heads/master from Hiroaki Kawai [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2091852 ] CLOUDSTACK-212 : migrate the namespace (network-ssp-plugin) migrate the ssp plugin namespace from com.cloud to org.apache.cloudstack Signed-off-by: Hiroaki KAWAI <kawai@stratosphere.co.jp>
        Hide
        Animesh Chaturvedi added a comment -

        Should this be resolved now?

        Show
        Animesh Chaturvedi added a comment - Should this be resolved now?
        Hide
        Dharmesh Kakadia added a comment -

        Animesh Chaturvedi I have submitted a patch. If that goes along well I will submitted the patch for full refactoring.

        Show
        Dharmesh Kakadia added a comment - Animesh Chaturvedi I have submitted a patch. If that goes along well I will submitted the patch for full refactoring.

          People

          • Assignee:
            Dharmesh Kakadia
            Reporter:
            Chip Childers
          • Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:

              Development