springframework-developer

[Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[mraible (s. by Nabble.com) <li...@na...>]

I've downloading the nightly build of 2.0 M1, and for some reason neither org.springframework.orm.hibernate.* nor org.springframework.orm.hibernate3.* are in spring.jar.  Is this "as designed"?  If Spring 2.0 is a drop-in replacement for Spring 1.2.x, it seems like these classes should be included in spring.jar.

I tried running "ant alljars" with JDK 1.4.2, but got the following error using 2.0-M1-with-dependencies.

buildmain:
    [mkdir] Created dir: C:\Temp\spring-framework-2.0-m1\target\classes
    [mkdir] Created dir: C:\Temp\spring-framework-2.0-m1\target\classes\META-INF
    [javac] Compiling 1257 source files to C:\Temp\spring-framework-2.0-m1\target\classes
    [javac] C:\Temp\spring-framework-2.0-m1\src\org\springframework\aop\aspectj\AbstractAspectJAdvice.java:22: package org.aspectj.weaver.tools does not exist
    [javac] import org.aspectj.weaver.tools.PointcutExpression;


Matt
--
Sent from the springframework-developer forum at Nabble.com:
http://www.nabble.com/orm.hibernate*-missing-from-spring.jar-in-nightly-builds-t743148.html#a1944607

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[Craig W. <cr...@ha...>]

I stopped Rob, Rod, and Juergen in the lobby on the last day of TSE and
asked the same question. It seems that Juergen has split out most of the
vendor-specific ORM stuff into independent JARs (spring-hibernate.jar or
spring-hibernate3.jar for instance). It's my understanding that the
decision was made because (1) the main JAR was getting quite large and (2)
Hibernate/iBATIS/OJB/etc-specific stuff is not central to Spring and thus
should not be in the main JAR.

So, yes, from a JAR dependency perspective, backwards compatibility is
broken. But fixing it is simply a matter of including an addition JAR file
in the classpath. Code-wise, backwards compatibility is still intact.



>
> I've downloading the nightly build of 2.0 M1, and for some reason
> neither org.springframework.orm.hibernate.* nor
> org.springframework.orm.hibernate3.* are in spring.jar.  Is this "as
> designed"?  If Spring 2.0 is a drop-in replacement for Spring 1.2.x, it
> seems like these classes should be included in spring.jar.
>
> I tried running "ant alljars" with JDK 1.4.2, but got the following
> error using 2.0-M1-with-dependencies.
>
> buildmain:
>     [mkdir] Created dir: C:\Temp\spring-framework-2.0-m1\target\classes
> [mkdir] Created dir:
> C:\Temp\spring-framework-2.0-m1\target\classes\META-INF [javac]
> Compiling 1257 source files to
> C:\Temp\spring-framework-2.0-m1\target\classes [javac]
> C:\Temp\spring-framework-2.0-m1\src\org\springframework\aop\aspectj\AbstractAspectJAdvice.java:22:
> package org.aspectj.weaver.tools does not exist [javac] import
> org.aspectj.weaver.tools.PointcutExpression;
>
>
> Matt
> --
> Sent from the springframework-developer forum at Nabble.com:
> http://www.nabble.com/orm.hibernate*-missing-from-spring.jar-in-nightly-builds-t743148.html#a1944607

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[mraible (s. by Nabble.com) <li...@na...>]

Craig Walls wrote: 
> 
> 
> I stopped Rob, Rod, and Juergen in the lobby on the last day of TSE and
> asked the same question. It seems that Juergen has split out most of the
> vendor-specific ORM stuff into independent JARs (spring-hibernate.jar or
> spring-hibernate3.jar for instance). It's my understanding that the
> decision was made because (1) the main JAR was getting quite large and (2)
> Hibernate/iBATIS/OJB/etc-specific stuff is not central to Spring and thus
> should not be in the main JAR.
> 
> So, yes, from a JAR dependency perspective, backwards compatibility is
> broken. But fixing it is simply a matter of including an addition JAR file
> in the classpath. Code-wise, backwards compatibility is still intact.
> 
> 

Right, I discovered that much.  However, all the other persistence 
frameworks are still included in spring.jar and Hibernate seems to be 
the only one that's been left out.

Matt
--
Sent from the springframework-developer forum at Nabble.com:
http://www.nabble.com/orm.hibernate*-missing-from-spring.jar-in-nightly-builds-t743148.html#a1946280

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[Colin S. <col...@ex...>]

mraible (sent by Nabble.com) wrote:

>     Craig Walls wrote:
>     I stopped Rob, Rod, and Juergen in the lobby on the last day of
>     TSE and
>     asked the same question. It seems that Juergen has split out most
>     of the
>     vendor-specific ORM stuff into independent JARs
>     (spring-hibernate.jar or
>     spring-hibernate3.jar for instance). It's my understanding that the
>     decision was made because (1) the main JAR was getting quite large
>     and (2)
>     Hibernate/iBATIS/OJB/etc-specific stuff is not central to Spring
>     and thus
>     should not be in the main JAR.
>
>     So, yes, from a JAR dependency perspective, backwards
>     compatibility is
>     broken. But fixing it is simply a matter of including an addition
>     JAR file
>     in the classpath. Code-wise, backwards compatibility is still intact.
>
> Right, I discovered that much.  However, all the other persistence
> frameworks are still included in spring.jar and Hibernate seems to be
> the only one that's been left out.

It's not about splitting it out just to split it out. The problem is 
that having both the Hibernate 2 and Hibernate 3 code together leads to 
a lot of confusion. People end up importing the wrong classes all the 
time. The actual class names are identical, and the packages as 
identical except for one extra char, so it's easy to import the wrong 
one when you do an auto import in Eclipse. I see this over and over 
during trainings, among other places. So back in the summer I suggested 
we split things out to separate jars and have people just include 
whichever one they wanted, but it didn't make sense (for drop in 
compatibility reasons) to do this in a 1.2 point release, but rather 
only now with 2.0...

Colin

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[mraible (s. by Nabble.com) <li...@na...>]

Colin Sampaleanu wrote: 
> 
> It's not about splitting it out just to split it out. The problem is 
> that having both the Hibernate 2 and Hibernate 3 code together leads to 
> a lot of confusion. People end up importing the wrong classes all the 
> time. The actual class names are identical, and the packages as 
> identical except for one extra char, so it's easy to import the wrong 
> one when you do an auto import in Eclipse. I see this over and over 
> during trainings, among other places. So back in the summer I suggested 
> we split things out to separate jars and have people just include 
> whichever one they wanted, but it didn't make sense (for drop in 
> compatibility reasons) to do this in a 1.2 point release, but rather 
> only now with 2.0...
> 
> Colin
> 

This makes sense - I've seen this same confusion in my experience. Thanks Colin.

Matt
--
Sent from the springframework-developer forum at Nabble.com:
http://www.nabble.com/orm.hibernate*-missing-from-spring.jar-in-nightly-builds-t743148.html#a1962085

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[Lachezar D. <l.d...@gm...>]

  Ahmm... Maybe if Spring uses the Class-Path attribute in the jars'
MANIFEST.MF this problem would be solved by merely dropping a couple
of jars into the library directory without mangling a project's class
path.
  Spring.jar should have in the manifest:
  Class-Path: spring-hibernate2.jar spring-hibernate-3.jar ...

  Then the developers would only need to drop the required subset of sub-ja=
rs.

2005/12/15, Colin Sampaleanu <col...@ex...>:
> mraible (sent by Nabble.com) wrote:
>
> It's not about splitting it out just to split it out. The problem is
> that having both the Hibernate 2 and Hibernate 3 code together leads to
> a lot of confusion. People end up importing the wrong classes all the
> time. The actual class names are identical, and the packages as
> identical except for one extra char, so it's easy to import the wrong
> one when you do an auto import in Eclipse. I see this over and over
> during trainings, among other places. So back in the summer I suggested
> we split things out to separate jars and have people just include
> whichever one they wanted, but it didn't make sense (for drop in
> compatibility reasons) to do this in a 1.2 point release, but rather
> only now with 2.0...
>
> Colin
>
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

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

Well, doesn't such a manifest classpath entry express the wrong =
direction of
dependency? spring.jar does not depend on spring-hibernate*.jar at all. =
It's
rather the other way round: spring-hibernate*.jar are extensions that =
depend
on spring.jar

Juergen
=20

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Lachezar Dobrev
Sent: Tuesday, December 20, 2005 9:23 AM
To: spr...@li...
Subject: Re: [Springframework-developer] orm.hibernate* missing from
spring.jar in nightly builds

  Ahmm... Maybe if Spring uses the Class-Path attribute in the jars'
MANIFEST.MF this problem would be solved by merely dropping a couple of =
jars
into the library directory without mangling a project's class path.
  Spring.jar should have in the manifest:
  Class-Path: spring-hibernate2.jar spring-hibernate-3.jar ...

  Then the developers would only need to drop the required subset of
sub-jars.

2005/12/15, Colin Sampaleanu <col...@ex...>:
> mraible (sent by Nabble.com) wrote:
>
> It's not about splitting it out just to split it out. The problem is=20
> that having both the Hibernate 2 and Hibernate 3 code together leads=20
> to a lot of confusion. People end up importing the wrong classes all=20
> the time. The actual class names are identical, and the packages as=20
> identical except for one extra char, so it's easy to import the wrong=20
> one when you do an auto import in Eclipse. I see this over and over=20
> during trainings, among other places. So back in the summer I=20
> suggested we split things out to separate jars and have people just=20
> include whichever one they wanted, but it didn't make sense (for drop=20
> in compatibility reasons) to do this in a 1.2 point release, but=20
> rather only now with 2.0...
>
> Colin
>
> --
> Colin Sampaleanu
> Interface21 Principal Consultant
> Spring Training, Consulting and Support - "From the Source"
> http://www.springframework.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] orm.hibernate* missing from spring.jar in nightly builds

[Lachezar D. <l.d...@gm...>]

  Ummm...
  Well... That's not a dependancy, rather an 'optional extension'.
  It is by no means mandatory... And I have not seen any constraints
as to whether the ClassPath entries must exist.
  I have never thought the ClassPath attribute as an expression.
  It's just included in the CP if it exists.

  There was a time when commons-logging used this approach to add
log4j.jar to the CP transparent to the application. Don't know why it
has been missing for some time now... Maybe the same reason that you
pointed out :).

  Anyway. It was just a thought...

2005/12/20, Juergen Hoeller <ju...@in...>:
> Well, doesn't such a manifest classpath entry express the wrong direction=
 of
> dependency? spring.jar does not depend on spring-hibernate*.jar at all. I=
t's
> rather the other way round: spring-hibernate*.jar are extensions that dep=
end
> on spring.jar
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
Of
> Lachezar Dobrev
> Sent: Tuesday, December 20, 2005 9:23 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] orm.hibernate* missing from
> spring.jar in nightly builds
>
>   Ahmm... Maybe if Spring uses the Class-Path attribute in the jars'
> MANIFEST.MF this problem would be solved by merely dropping a couple of j=
ars
> into the library directory without mangling a project's class path.
>   Spring.jar should have in the manifest:
>   Class-Path: spring-hibernate2.jar spring-hibernate-3.jar ...
>
>   Then the developers would only need to drop the required subset of
> sub-jars.
>
> 2005/12/15, Colin Sampaleanu <col...@ex...>:
> > mraible (sent by Nabble.com) wrote:
> >
> > It's not about splitting it out just to split it out. The problem is
> > that having both the Hibernate 2 and Hibernate 3 code together leads
> > to a lot of confusion. People end up importing the wrong classes all
> > the time. The actual class names are identical, and the packages as
> > identical except for one extra char, so it's easy to import the wrong
> > one when you do an auto import in Eclipse. I see this over and over
> > during trainings, among other places. So back in the summer I
> > suggested we split things out to separate jars and have people just
> > include whichever one they wanted, but it didn't make sense (for drop
> > in compatibility reasons) to do this in a 1.2 point release, but
> > rather only now with 2.0...
> >
> > Colin
> >
> > --
> > Colin Sampaleanu
> > Interface21 Principal Consultant
> > Spring Training, Consulting and Support - "From the Source"
> > http://www.springframework.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>