4 Replies Latest reply on May 15, 2008 6:39 PM by Ales Justin

    GA releases of mc projects?

    Kabir Khan Master

      I am being pushed for an AOP 2.0.0.GA release (end of next week), but we still have dependencies on non-GA mc stuff. From our build-thirdparty.xml:

       <componentref name="jboss/integration" version="5.0.0.Beta4"/>
       <componentref name="jboss/jboss-mdr" version="2.0.0.Beta12"/>
       <componentref name="jboss/jboss-reflect" version="2.0.0.Beta12"/>
       <componentref name="jboss/jboss-vfs" version="2.0.0.Beta9"/>
       <componentref name="jboss/jboss-deployers" version="2.0.0.Beta12"/>
       <componentref name="jboss/jboss-managed" version="2.0.0.Beta10.1"/>
       <componentref name="jboss/profiler/jvmti" version="1.0.0.CR5"/>
      

      I don't think we can do a GA against beta versions?

        • 1. Re: GA releases of mc projects?
          Kabir Khan Master

          Having dug a bit more into the dependencies and seeing where they are used from, all we need to bundle in the standalone release is jboss-mdr and jboss-reflect, the others are needed for integration into jboss 5, but I guess by the time AS 5 is released we can release a new AOP version.

          So, can we have GA releases of jboss-mdr and jboss-reflect as discussed in Neuchatel?

          • 2. Re: GA releases of mc projects?
            Ales Justin Master

             

            "kabir.khan@jboss.com" wrote:

            So, can we have GA releases of jboss-mdr and jboss-reflect as discussed in Neuchatel?

            I would first like to finish these JIRA issues:
            - http://jira.jboss.com/jira/browse/JBCL-9
            - http://jira.jboss.com/jira/browse/JBDEPLOY-13
            - http://jira.jboss.com/jira/browse/JBMICROCONT-277
            since they might be potential API changers/fixers when they use Reflect and MDR.
            And I remember having one Reflect issue, when dealing with non-public method invocations.

            But even then GA is not a direct option, needing CR1 before that.
            btw: Who is so badly needing AOP GA?

            • 3. Re: GA releases of mc projects?
              Adrian Brock Master

              Why would any of the above require a change to the existing api?

              Sure we might want to allow an alternate implementation of the parsing of the class
              annotations using javassist in the MDR so AOP can use thi s mechanism
              but that is an implemetation detail.

              I don't see why bean validation would require any api change.

              If you mean adding bean validation as a new api to the reflect project,
              the addition of new optional api is NOT an api change.

              But bean validation is not really reflection so I'd prefer additional validation api or
              integration to be in its own project. i.e. it is something that sits above the reflection layer.

              Allowing non-public method invocations is just an internal change to do access checks
              similar to what I did for non-public fields, i.e. no api change.

              • 4. Re: GA releases of mc projects?
                Ales Justin Master

                 

                "adrian@jboss.org" wrote:
                Why would any of the above require a change to the existing api?

                You never know. ;-)
                And in this case, in turned out to be true, since I needed exact distinction between method params signature and constructor params signature in annotations scanning.
                And I added Javassist version of it all as well, but that's addition, not change. ;-)

                "adrian@jboss.org" wrote:

                But bean validation is not really reflection so I'd prefer additional validation api or
                integration to be in its own project. i.e. it is something that sits above the reflection layer.

                You mean this ;-)
                - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsr303/

                "adrian@jboss.org" wrote:

                Allowing non-public method invocations is just an internal change to do access checks
                similar to what I did for non-public fields, i.e. no api change.

                True.
                And already done. ;-)