Re: [Springframework-developer] Hibernate 3 annotations in 1.2 rc1

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I'm mainly concerned to get the source directory structure right.
"tiger/src" and "tiger/test" directories sound appropriate to me, getting
built by a "tiger.build" in the build script, with "-target 1.5" in contrast
to the main sources.

Building the annotations into spring jar is probably not a problem. The jar
target could simply grab both the "-target 1.3" classes and the classes
compiled from the "tiger" source tree and put them into a single jar.

Regarding accessing annotations directly: Don't forget that we're always
using specific facades in front, such as TransactionAttributeSource and
JmxAttributeSource. Overriding can be done there nicely, at a higher level.

Even if we tried to add overriding at the annotation level, how would that
work? How can you create annotation objects other than reading them from a
class file? It looks like there always has to be a facade for accessing
specific attributes, using plain objects as attribute values, with
annotation parsing going on in the background.

My main point regarding AnnotationsAttributes is that it doesn't add any
value, as long as it returns annotations objects as result. And wrapping
annotations at a generic level is probably not desirable, when there's
always a specific facade in front of it anyway.

Juergen

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Tuesday, March 15, 2005 12:55 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Hibernate 3 annotations in 1.2
rc1

I'm not too bothered about the build structure or the infrastructure to
access annotations in the 1.2 timeframe. I think we need to:

- Release a usable (non-preview) transaction annotation in 1.2. Ideally
from RC1. People want to use this stuff.

- Ensure source compatibility of application code using annotations
moving forward. It doesn't matter if the internals change (e.g. we add
Annogen or whatever) but we can't break code by changing the annotations.

- Build the annotations into spring.jar somehow. So they're always
available. I think this is core functionality; it's just that it can't
be used in most environments. It doesn't add much size to the JAR, either.

Besides these things I don't think it particularly matters how we build
or access annotations at this point.

One reason that I *don'* favour accessing annotations directly is that
then there is no ability to override annotations. With transactions,
this is a bit of a moot point: there is a strong argument that it makes
no sense to override transactional behaviour. But essentially
annotations *should* be overridable, and we clearly need a general
solution for this problem.

So we could add as an enhancement in 1.3 the ability to override
transaction annotations, for example in XML. (Of course we could do this
using our own API, not annotations-specific, but it would be much nicer
to have an integrated solution.)

The fact that no one on the annotations expert group seems to have
thought about overriding is astounding IMO. *All* projects using
annotations have faced this issue, and there is no really good way round it.

Rgds
Rod

Juergen Hoeller wrote:
> Well, the problem is that even with module separation, we would still have
> the problem that we need to build as much as possible with "-target 1.3".
> But our modules won't be that fine-granular: I assume that our JDK 1.5
> annotations would live in the transaction and JMX modules, respectively.
> Which still involves the target JDK problem.
>
> It might even be necessary to keep JDK 1.5 dependent stuff in a separate
> source tree for a longer time - maybe for the entire Spring 1.x branch.
This
> is not necessarily a big burden: We'd just need to figure out how to make
> the building with 1.3/1.5 targets as convenient as possible. The
separation
> itself would be perfectly reasonable for users, I guess.
>
> We can certainly have a build script that it is able to build both when
> running on JDK 1.5 (with respective target values), which would be
necessary
> for actual releases. However, it would be great if we could design the
build
> script such that it would still be able to build the main sources when
> running on JDK 1.4. That should be possible with proper build targets.
>
> Juergen
>
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Colin Sampaleanu
> Sent: Tuesday, March 15, 2005 1:57 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Hibernate 3 annotations in 1.2
> rc1
>
>
> Juergen Hoeller wrote:
>
>
>>Good point regarding "preview" in conjunction with JDK 1.5. Preview is
>>probably the wrong term anyway. This is essentially a building and
>
> packaging
>
>>issue: The JDK 1.5 transaction annotation support must be built with
>>"-target 1.5", while the rest of Spring obviously should be built with
>>"-target 1.3".
>>
>>So there are just two options, as far as I see:
>>
>>* either turn the JDK 1.5 transaction annotations into a separate
download,
>>which will be built with JDK 1.5 as opposed to the main download
>>
>>* or create a separate source tree within the main download (e.g.
>>"tiger/src" and "tiger/test"), built with "-target 1.5" as opposed to the
>>main sources which get built with "-target 1.3"
>>
>>The latter option is fine with me too. The separate source tree would
>>essentially just contain the packages
>>"org.springframework.transaction.annotations" and
>>"org.springframework.jmx.export.annotations" (which I would suggest as
>>package names), compiled into a separate jar file in a separate build
step.
>>
>>
>>
>
> I'm not a big fan of the idea of having a separate source and test tree
> for 1.5 specific code within the main project. Where would the actual
> build file live, and how would it be called? Or is the main build file
> expected to be run under JDK 1.5 now, but using -1.3 for most source,
> and 1.5 for this? This is actually a step in the opposite direction
> which we mostly agreed we want to take for 1.3, which is to have
> separate source packages. If it makes things easier though, I can
> probably live with it for the 1.2 timeframe :-)
>
>
>>Of course, we also need to decide on a final naming strategy for
>>annotations. "Transactional" sounds good to me. I would also suggest to
>>rename the PropagationType enumeration to PropagationBehavior, for
>>consistent naming - or go for "Propagation" and "Isolation" as enumeration
>>names.
>>
>>
>
> Transactional is fine with me. Propagation by itself is probably ok.
> It's always going to be used as an attribute of Transactional Anyway.
>
>
>>BTW, I don't see much point in the AnnotationsAttributes implementation of
>>our Attribute facade, as used in the AnnotationsJmxAttributeSource. Why
not
>>access the JDK 1.5 annotation API directly there? After all, the
>
> annotations
>
>>have to be converted to the JmxAttributeSource return values anyway.
>>
>>The JDK 1.5 annotation model and our Attributes facade simply don't match
>>well, so I guess we need to go forward with both in parallel. The
>
> Attributes
>
>>facade provides value even for Commons Attributes as sole target (e.g. for
>>testing). I must say I appreciate the ability to use existing attribute
>>classes with Commons Attributes...
>>
>>
>
> After I created the code last fall this is the same conversatoin I had
> with Rod. There is no real added value in accessing the Annotations
> through the Attributes interface, because the user of the Annotations
> has to know they are annotations anyway, it's not really compatible with
> getting generic classes through the interfaces as provided by
> commons-attributes. Now moving to something like Annogen is I think
> desireable, but it's probably not an option right now, as it doesn't
> support arrays properly. So I think what would work is to move the
> implementation to access Annotations directly, and then at some point
> make it work via a mapping lib like Annogen. That would basically be
> transparent to users.
>
>
>>So how do we move forward with this? We should move the code to the main
>
> CVS
>
>>module ASAP, clarify the class naming, and also prepare the build script
to
>>handle the different target JDKs. I can certainly care for this, but I
>
> would
>
>>appreciate some help. After all, 1.2 RC1 should go out this week!
>>
>>
>
> I can do this. The code was mine after all. However I don' t know if I
> can do it in the next couple of days. I'm onsite at a client all week,
> and need to work on some stuff for them in the evenings, and can't see
> being able to do it before Thurs. or Fri. night.
>
> Colin
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

--
Rod Johnson
Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/

____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer