GA releases of mc projects?

[kabirkhan]

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?

[kabirkhan]

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?

[alesj]

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?

[adrian.brock]

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.

[alesj]

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. ;-)

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/

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. ;-)