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

[Juergen H. <ju...@in...>]

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