14 Replies Latest reply on Jun 4, 2009 4:06 PM by David Lloyd

    Moving microcontainer -> kernel

    Kabir Khan Master

      We plan to make some changes to the microcontainer project over the next few days/week, and wanted to give you all a bit of advance warning. The reason is that the microcontainer project has grown since its inception and is an umbrella for numerous sub-projects: jboss-reflect, jboss-man, jboss-mdr, jboss-mdr-cache, jboss-cl, jboss-deployers, jboss-vfs as well as the 'microcontainer' project, which is really the kernel.

      Hence, we plan to rebrand the existing 'microcontainer' core as 'kernel', and here is what will change:

      *** JIRA ***
      We have already moved it in JIRA, so the old JBMICROCONT issues have been moved to JBKERNEL.
      The existing JBMICROCONT project will be kept to deal with global microcontainer issues.

      *** SVN ***
      https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/
      will move to
      https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/

      But we will leave the existing tags under
      https://svn.jboss.org/repos/jbossas/projects/microcontainer/tags/
      as well as the branch these releases have been taken from:
      https://svn.jboss.org/repos/jbossas/projects/microcontainer/branches/Branch_2_0/

      The plan is for the
      https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/
      to be come a holder projects for things like tools, docs etc. that bind together the individual sub-projects.

      The upcoming 2.2.x releases will be tagged from
      https://svn.jboss.org/repos/jbossas/projects/kernel/branches/Branch_2_2 (this branch will be created later once we're ready for 2.2.x )


      *** MAVEN ***
      From 2.2.0 onwards the existing microcontainer artifacts will have a new groupId
      org.jboss.microcontainer -> org.jboss.kernel
      The 2.0.x releases will keep on using org.jboss.microcontainer.

        • 1. Re: Moving microcontainer -> kernel
          David Lloyd Master

          While you're going through the API to do this refactor, it might be a good time to change all the parameters which represent a bean name from being "Object" to "String".

          Or maybe that's a can of worms...

          • 2. Re: Moving microcontainer -> kernel
            Ales Justin Master

             

            "david.lloyd@jboss.com" wrote:
            While you're going through the API to do this refactor, it might be a good time to change all the parameters which represent a bean name from being "Object" to "String".

            Isn't this already the case on BeanMetaData?

            Doing this elsewhere would be wrong,
            as you don't really know or care what kind of type do other components use for their name.

            • 3. Re: Moving microcontainer -> kernel
              David Lloyd Master

               

              "alesj" wrote:
              "david.lloyd@jboss.com" wrote:
              While you're going through the API to do this refactor, it might be a good time to change all the parameters which represent a bean name from being "Object" to "String".

              Isn't this already the case on BeanMetaData?

              Doing this elsewhere would be wrong,
              as you don't really know or care what kind of type do other components use for their name.


              Of course you do. The name is a String so why support anything else? And even if you do decide to support something like ObjectName or whatever, you should use overloading for that purpose. It doesn't make sense to allow Object. It implies that I can pass in a HashMap, or a Socket, or an AudioFileFormat, or ...

              • 4. Re: Moving microcontainer -> kernel
                Kabir Khan Master

                 

                "ALR" wrote:

                Will you please follow up, when complete, with the complete:

                groupId:artifactId:version

                ...of all the projects affected, as well as their old names?

                Likely we'll want to be adding some rules to the various Enforcer Plugin configurations to ban the old stuff.

                S,
                ALR


                • 6. Re: Moving microcontainer -> kernel
                  Ales Justin Master

                   

                  "david.lloyd@jboss.com" wrote:

                  Of course you do. The name is a String so why support anything else? And even if you do decide to support something like ObjectName or whatever, you should use overloading for that purpose. It doesn't make sense to allow Object. It implies that I can pass in a HashMap, or a Socket, or an AudioFileFormat, or ...

                  No I don't. ;-) The name is definitely not just a String.

                  Although I see where you're aiming, but there is more to it then just overloading.
                  And exactly the notion of having no explicit type is what makes it possible to:
                  * handle contextual injection with a single lookup method
                  * support Guice Key and other impl details
                  * legacy ObjectName as key/name
                  * ...

                  And if AudioFileFormat makes you happy, be my guest. :-)

                  • 7. Re: Moving microcontainer -> kernel
                    David Lloyd Master

                    OK, I may not agree that this is "right" but it is what it is. I think there's one thing we can agree on though - the parameter ought to have a more accurate name, like "beanName" or "beanIdentifier" rather than just "bean", because "bean" implies an expectation that you're passing in the actual bean object in question rather than its identifier.

                    • 8. Re: Moving microcontainer -> kernel
                      Kabir Khan Master

                       

                      "david.lloyd@jboss.com" wrote:
                      OK, I may not agree that this is "right" but it is what it is. I think there's one thing we can agree on though - the parameter ought to have a more accurate name, like "beanName" or "beanIdentifier" rather than just "bean", because "bean" implies an expectation that you're passing in the actual bean object in question rather than its identifier.

                      I'm working on improving the javadocs, so that is something I can look into

                      • 9. Re: Moving microcontainer -> kernel
                        Adrian Brock Master

                         

                        "david.lloyd@jboss.com" wrote:
                        OK, I may not agree that this is "right" but it is what it is. I think there's one thing we can agree on though - the parameter ought to have a more accurate name, like "beanName" or "beanIdentifier" rather than just "bean", because "bean" implies an expectation that you're passing in the actual bean object in question rather than its identifier.


                        You simply don't get it.
                        The controller context, dependencies, etc. has nothing to do with a "bean"
                        or the choices of any particular component model.

                        The POJO controller context is only one possible implementation that relates to beans
                        and that happens to use a String as the name.

                        Other component models don't have to use a String for the name.
                        Its up to each component model to keep things consistent.

                        If you want the longer version of this argument, at least as it relates to JMX, then use
                        search. I know I've been over the issue at least once before at some length in this forum.

                        There's even a JIRA (or at least a discussion) somewhere about using a "UUID"
                        as the real id with the publically visible "name" just being an alias.

                        • 10. Re: Moving microcontainer -> kernel
                          David Lloyd Master

                           

                          "adrian@jboss.org" wrote:
                          "david.lloyd@jboss.com" wrote:
                          OK, I may not agree that this is "right" but it is what it is. I think there's one thing we can agree on though - the parameter ought to have a more accurate name, like "beanName" or "beanIdentifier" rather than just "bean", because "bean" implies an expectation that you're passing in the actual bean object in question rather than its identifier.


                          You simply don't get it.


                          I get it - as I said, it is what it is. I'm just saying that at the least we ought to change the parameter name because it's misleading. For example, BeanMetaDataBuilder gives us:

                          public static BeanMetaDataBuilder createBuilder(String name, String bean)
                          


                          This just makes no sense. One of those parameters is the name of the bean associated with the BeanMetaData, the other is the name of the class. But which is which? I get it wrong about half the time.


                          • 11. Re: Moving microcontainer -> kernel
                            Adrian Brock Master

                             

                            "david.lloyd@jboss.com" wrote:

                            public static BeanMetaDataBuilder createBuilder(String name, String bean)
                            


                            This just makes no sense. One of those parameters is the name of the bean associated with the BeanMetaData, the other is the name of the class. But which is which? I get it wrong about half the time.


                            This must be a bad example? The javadoc tells you which is which.

                            If you posted all the code;
                             /**
                            
                             * Create builder from name and bean.
                            
                             *
                            
                             * @param name bean name
                            
                             * @param bean bean class name
                            
                             * @return new Builder
                            
                             */
                            
                             public static BeanMetaDataBuilder createBuilder(String name, String bean)
                            
                             {
                            
                             return BeanMetaDataBuilderFactory.createBuilder(name, bean);
                            
                             }
                            
                            


                            Parameter names have no meaning in java anyway - it being a positional language - so they could be called x and y. This is "Humpty dumpty" again.

                            "bean" is actually the name of the class on BeanMetaData because you can't have
                            a get/setClass() - it already means something else in java.lang.Object.

                            Anyway, "String bean" is kind of funny, even if it wasn't an intentional joke by Ales. :-)
                            http://en.wikipedia.org/wiki/Green_beans

                            • 12. Re: Moving microcontainer -> kernel
                              David Lloyd Master

                              Parameter names do have meaning in that they tell the human reading the code what the parameter is. If you called all your parameters "x" and "y" you'd soon have an angry mob outside your door - or at least, people wouldn't use your hard-to-use software.

                              If "bean" is the class name, how about "beanName" and "beanClassName"? There's nothing wrong with being descriptive.

                              • 13. Re: Moving microcontainer -> kernel
                                Kabir Khan Master

                                As advertised the move has now happened. To check out the kernel project, neé microcontainer,
                                you now check out https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/.

                                https://svn.jboss.org/repos/jbossas/projects/microcontainer/branches and https://svn.jboss.org/repos/jbossas/projects/microcontainer/tags contain the existing tags and branches for the current releases.

                                Further 2.2.x releases will be tagged from https://svn.jboss.org/repos/jbossas/projects/kernel/branches/Branch_2_2/, which will be a branch of https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/

                                https://svn.jboss.org/repos/jbossas/projects/microcontainer/mcdocs contains the documentation, managing its own branches and tags.
                                https://svn.jboss.org/repos/jbossas/projects/microcontainer/mc-release/ contains the tool for uploading all the mc artifacts to the downloads area, again managing its own branches and tags.
                                Further projects 'global' to MC should be added under https://svn.jboss.org/repos/jbossas/projects/microcontainer.

                                The renames of the maven artifacts are as follows. This will only take effect from further 2.2.0 releases:
                                org.jboss.microcontainer:jboss-microcontainer -> org.jboss.kernel:jboss-mc-kernel (parent)

                                org.jboss.microcontainer:aop-mc-int -> org.jboss.kernel:aop-mc-int
                                org.jboss.microcontainer:guice-int -> org.jboss.kernel:guice-int
                                org.jboss.microcontainer:jboss-dependency -> org.jboss.kernel:jboss-dependency
                                org.jboss.microcontainer:jboss-kernel -> org.jboss.kernel:jboss-kernel
                                org.jboss.microcontainer:jmx-aop-mc-int -> org.jboss.kernel:jmx-aop-mc-int
                                org.jboss.microcontainer:jmx-mc-int -> org.jboss.kernel:jmx-mc-int
                                org.jboss.microcontainer:spring-int -> org.jboss.kernel:spring-int

                                If there are more 2.0.x releases they will use the old group ids.

                                • 14. Re: Moving microcontainer -> kernel
                                  David Lloyd Master

                                  BTW if you already have the microcontainer trunk checked out, you don't need to check it out again. Just run this command:

                                  svn switch https://svn.jboss.org/repos/jbossas/projects/kernel/trunk

                                  and you'll be in the new repository.