Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-10-04 12:12:19
|
Darren, =20 While this is certainly a worthwhile extension, I'm not sure if we = should raise the size of the Spring core distribution with a further 1.3 = MB jar file for such special functionality, in particular for a library = that is still in 0.x (i.e. whose API is not guaranteed to stay stable). = I'm a bit worried in that respect... Do you know what timeframe the next = FOP major release is scheduled for?=20 =20 Thus, I suggest to put the FOP support classes into the sandbox for the = time being... like we do for Commons Validator and co. People will use = it from there too, like they already do with the Commons Validator = support and the Portlet stuff... We can always move it over once we = agree that the time is right. Another option would be to start shipping = a separate extension distribution... =20 Opinions? (both on FOP support and the extension distribution idea...) =20 Juergen =20 _____ =20 Von: spr...@li... im Auftrag = von Darren Davison Gesendet: Mo 04.10.2004 11:16 An: spr...@li... Betreff: [Springframework-developer] XSL-FO (Apache-FOP) There have been a couple of posts in the forums about FOP ( http://forum.springframework.org/search.php?search = <http://forum.springframework.org/search.php?search&search_keywords=3Dfop= > &search_keywords=3Dfop) and we now have a similar requirement here in one of our projects. It's actually pretty trivial to implement when extending = AbstractXsltView but I think it's useful to include the generic parts in the framework. = Additional build dependencies include only fop.jar (~1.3MB) although the target app = will have to include batik.jar and the avalon framework jar as runtime = dependencies since FOP is hardlinked to Avalon logging in the current stable branch. = This will change to commons logging in the next major release. I'd like to commit this if there are no objections. No modifications = are required to existing framework classes and it could go in for 1.1.2 I = think. (Any comments welcome from those with significant FOP experience as I = don't have a great deal). -- Darren Davison Public Key: #DD356B0D ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give = us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-10-04 13:24:04
|
Darren, > would some of the currently core things then move into the 'extension' > distro (Velocity/FreeMarker/POI et al)? I'm unsure how this works.. Actually, I'd like to keep everything that we currently ship in the = core, to provide a single comprehensive distribution package. It's just about *further* dependencies for things that are not fully = tested/reviewed yet or that we are not completely happy with. There = probably will never be a clear line here: We'd have to decide on a = case-by-cases basis what should go into the core or into the extension = package. FOP support should definitely go into the sandbox! People will use this = and give further feedback on it. (We're lucky that we have quite a lot = of "sandbox-aware" users!) I'd just like to defer adding it to the core = for a while, until things have clarified a bit further. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Darren Davison Sent: Monday, October 04, 2004 3:02 PM To: spr...@li... Subject: Re: [Springframework-developer] XSL-FO (Apache-FOP) On Mon, October 4, 2004 13:13, j=FCrgen h=F6ller [werk3AT] said: > Darren, > > While this is certainly a worthwhile extension, I'm not sure if we = should > raise the size of the Spring core distribution with a further 1.3 MB = jar file > for such special functionality, in particular for a library that is = still in > 0.x (i.e. whose API is not guaranteed to stay stable). I'm a bit = worried in > that respect... Do you know what timeframe the next FOP major release = is > scheduled for? It's a big jar for such a small class, agreed. But then again, 1.3Mb = isn't much on top of what is already a 26MB+ download. The 0.x version is annoying, but also slightly misleading. A lot of = projects these days hugely overuse the 0.x versioning - particularly in the GNU = space where some software has been in production use for years (literally) and = yet still has a 0.x version number. 0.20.5 is a stable, supported branch of = FOP.=20 The API *will* change in the rewrite (currently only available via CVS), = see http://xml.apache.org/fop/dev/index.html#lines for more info. But then = that's not really any different to other projects that we currently ship a = dependency for as they could change their API in the next major release. Changes = to the FOP API should be hidden within the View implementation in Spring and = won't affect end users. I'm not overly concerned if it goes in the sandbox or not at all since = it's trivial to code it as an extension in my apps. It just seemed like a = useful addition that we needed anyway and others had already asked for. Just my $0.02 - be interested to hear anyone else's. > Thus, I suggest to put the FOP support classes into the sandbox for = the time > being... like we do for Commons Validator and co. People will use it = from > there too, like they already do with the Commons Validator support and = the > Portlet stuff... We can always move it over once we agree that the = time is > right. Another option would be to start shipping a separate extension > distribution... > > Opinions? (both on FOP support and the extension distribution idea...) would some of the currently core things then move into the 'extension' = distro (Velocity/FreeMarker/POI et al)? I'm unsure how this works.. --=20 Darren Davison Public Key: #DD356B0D ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give = us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Darren D. <da...@da...> - 2004-10-04 14:19:00
|
On Mon, October 4, 2004 14:25, j=FCrgen h=F6ller [werk3AT] said: > It's just about *further* dependencies for things that are not fully > tested/reviewed yet or that we are not completely happy with. There pro= bably > will never be a clear line here: We'd have to decide on a case-by-cases= basis > what should go into the core or into the extension package. ok. > FOP support should definitely go into the sandbox I'll commit it there promptly. Thanks! --=20 Darren Davison Public Key: #DD356B0D |
|
From: Rod J. <ro...@in...> - 2004-10-04 16:54:04
|
I think the time has come for an extensions package. Also possibly a = contrib area. For example, scripting support for Jython and Rhino. We will ship Groovy = and Beanshell support in the core in 1.2, but users who want other languages could download the extensions... If we don't do this, the download size will snowball, and some people = will get put off Spring as a whole. (Wrongly, but that's not the point.) R -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Dmitriy Kopylenko Sent: 04 October 2004 14:13 To: spr...@li... Subject: Re: [Springframework-developer] XSL-FO (Apache-FOP) +1 for extension distribution. Regards, Dmitriy. j=FCrgen h=F6ller [werk3AT] wrote: > Darren, > =20 > While this is certainly a worthwhile extension, I'm not sure if we=20 > should raise the size of the Spring core distribution with a further > 1.3 MB jar file for such special functionality, in particular for a=20 > library that is still in 0.x (i.e. whose API is not guaranteed to stay = > stable). I'm a bit worried in that respect... Do you know what=20 > timeframe the next FOP major release is scheduled for? > =20 > Thus, I suggest to put the FOP support classes into the sandbox for=20 > the time being... like we do for Commons Validator and co. People will = > use it from there too, like they already do with the Commons Validator = > support and the Portlet stuff... We can always move it over once we=20 > agree that the time is right. Another option would be to start=20 > shipping a separate extension distribution... > =20 > Opinions? (both on FOP support and the extension distribution idea...) > =20 > Juergen > =20 > > ---------------------------------------------------------------------- > -- > *Von:* spr...@li... im=20 > Auftrag von Darren Davison > *Gesendet:* Mo 04.10.2004 11:16 > *An:* spr...@li... > *Betreff:* [Springframework-developer] XSL-FO (Apache-FOP) > > > There have been a couple of posts in the forums about FOP=20 > = (http://forum.springframework.org/search.php?search&search_keywords=3Dfo > p > = <http://forum.springframework.org/search.php?search&search_keywords=3Dfo > p>) > and > we now have a similar requirement here in one of our projects. > > It's actually pretty trivial to implement when extending=20 > AbstractXsltView but I think it's useful to include the generic parts=20 > in the framework. > Additional > build dependencies include only fop.jar (~1.3MB) although the target=20 > app will have to include batik.jar and the avalon framework jar as=20 > runtime dependencies since FOP is hardlinked to Avalon logging in the=20 > current stable branch. This will change to commons logging in the=20 > next major release. > > I'd like to commit this if there are no objections. No modifications=20 > are required to existing framework classes and it could go in for=20 > 1.1.2 I think. > > (Any comments welcome from those with significant FOP experience as I=20 > don't have a great deal). > > > -- > Darren Davison > Public Key: #DD356B0D > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on = ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give = us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give = us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Nick L. <nic...@es...> - 2004-10-05 01:16:40
|
> > > On Mon, October 4, 2004 15:10, Colin Sampaleanu said: > > > From what you're saying it sounds like it doesn't make > sense to put it > > into the sandbox on the basis that FOP is immature. > > Hi Colin, > > you replied to my post but I'm unsure if this is directed at > me or Juergen..? > > If me, then in my opinion FOP itself is not that immature - > their choice of > version number is simply inappropriate. FOP has been in > fairly widespread use > for well over 3 years now. > We have used FOP fairly extensivly in the past, and I would have to disagree about it's maturity. We had a fair bit of trouble with its dependancies - from memory it required a specific version of batik, which in turn required a specific version of Xerces. This might have been fixed in the over the last year - I'm just relaying my experiences. Nick |
|
From: Darren D. <da...@da...> - 2004-10-04 13:02:30
|
On Mon, October 4, 2004 13:13, j=FCrgen h=F6ller [werk3AT] said: > Darren, > > While this is certainly a worthwhile extension, I'm not sure if we shou= ld > raise the size of the Spring core distribution with a further 1.3 MB ja= r file > for such special functionality, in particular for a library that is sti= ll in > 0.x (i.e. whose API is not guaranteed to stay stable). I'm a bit worrie= d in > that respect... Do you know what timeframe the next FOP major release i= s > scheduled for? It's a big jar for such a small class, agreed. But then again, 1.3Mb isn= 't much on top of what is already a 26MB+ download. The 0.x version is annoying, but also slightly misleading. A lot of proj= ects these days hugely overuse the 0.x versioning - particularly in the GNU sp= ace where some software has been in production use for years (literally) and = yet still has a 0.x version number. 0.20.5 is a stable, supported branch of = FOP.=20 The API *will* change in the rewrite (currently only available via CVS), = see http://xml.apache.org/fop/dev/index.html#lines for more info. But then t= hat's not really any different to other projects that we currently ship a depen= dency for as they could change their API in the next major release. Changes to= the FOP API should be hidden within the View implementation in Spring and won= 't affect end users. I'm not overly concerned if it goes in the sandbox or not at all since it= 's trivial to code it as an extension in my apps. It just seemed like a use= ful addition that we needed anyway and others had already asked for. Just my $0.02 - be interested to hear anyone else's. > Thus, I suggest to put the FOP support classes into the sandbox for the= time > being... like we do for Commons Validator and co. People will use it fr= om > there too, like they already do with the Commons Validator support and = the > Portlet stuff... We can always move it over once we agree that the time= is > right. Another option would be to start shipping a separate extension > distribution... > > Opinions? (both on FOP support and the extension distribution idea...) would some of the currently core things then move into the 'extension' di= stro (Velocity/FreeMarker/POI et al)? I'm unsure how this works.. --=20 Darren Davison Public Key: #DD356B0D |
|
From: Dmitriy K. <dko...@ru...> - 2004-10-04 13:11:37
|
+1 for extension distribution. Regards, Dmitriy. jürgen höller [werk3AT] wrote: > Darren, > > While this is certainly a worthwhile extension, I'm not sure if we > should raise the size of the Spring core distribution with a further > 1.3 MB jar file for such special functionality, in particular for a > library that is still in 0.x (i.e. whose API is not guaranteed to stay > stable). I'm a bit worried in that respect... Do you know > what timeframe the next FOP major release is scheduled for? > > Thus, I suggest to put the FOP support classes into the sandbox for > the time being... like we do for Commons Validator and co. People will > use it from there too, like they already do with the Commons Validator > support and the Portlet stuff... We can always move it over once we > agree that the time is right. Another option would be to start > shipping a separate extension distribution... > > Opinions? (both on FOP support and the extension distribution idea...) > > Juergen > > > ------------------------------------------------------------------------ > *Von:* spr...@li... im > Auftrag von Darren Davison > *Gesendet:* Mo 04.10.2004 11:16 > *An:* spr...@li... > *Betreff:* [Springframework-developer] XSL-FO (Apache-FOP) > > > There have been a couple of posts in the forums about FOP > (http://forum.springframework.org/search.php?search&search_keywords=fop > <http://forum.springframework.org/search.php?search&search_keywords=fop>) > and > we now have a similar requirement here in one of our projects. > > It's actually pretty trivial to implement when extending > AbstractXsltView but > I think it's useful to include the generic parts in the framework. > Additional > build dependencies include only fop.jar (~1.3MB) although the target > app will > have to include batik.jar and the avalon framework jar as runtime > dependencies > since FOP is hardlinked to Avalon logging in the current stable > branch. This > will change to commons logging in the next major release. > > I'd like to commit this if there are no objections. No modifications are > required to existing framework classes and it could go in for 1.1.2 I > think. > > (Any comments welcome from those with significant FOP experience as I > don't > have a great deal). > > > -- > Darren Davison > Public Key: #DD356B0D > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Colin S. <col...@ex...> - 2004-10-04 14:11:46
|
Darren Davison wrote: >On Mon, October 4, 2004 13:13, jürgen höller [werk3AT] said: > > >>Darren, >> >>While this is certainly a worthwhile extension, I'm not sure if we should >>raise the size of the Spring core distribution with a further 1.3 MB jar file >>for such special functionality, in particular for a library that is still in >>0.x (i.e. whose API is not guaranteed to stay stable). I'm a bit worried in >>that respect... Do you know what timeframe the next FOP major release is >>scheduled for? >> >> > >It's a big jar for such a small class, agreed. But then again, 1.3Mb isn't >much on top of what is already a 26MB+ download. > >The 0.x version is annoying, but also slightly misleading. A lot of projects >these days hugely overuse the 0.x versioning - particularly in the GNU space >where some software has been in production use for years (literally) and yet >still has a 0.x version number. 0.20.5 is a stable, supported branch of FOP. >The API *will* change in the rewrite (currently only available via CVS), see >http://xml.apache.org/fop/dev/index.html#lines for more info. But then that's >not really any different to other projects that we currently ship a dependency >for as they could change their API in the next major release. Changes to the >FOP API should be hidden within the View implementation in Spring and won't >affect end users. > >I'm not overly concerned if it goes in the sandbox or not at all since it's >trivial to code it as an extension in my apps. It just seemed like a useful >addition that we needed anyway and others had already asked for. > >Just my $0.02 - be interested to hear anyone else's. > > > >>Thus, I suggest to put the FOP support classes into the sandbox for the time >>being... like we do for Commons Validator and co. People will use it from >>there too, like they already do with the Commons Validator support and the >>Portlet stuff... We can always move it over once we agree that the time is >>right. Another option would be to start shipping a separate extension >>distribution... >> >>Opinions? (both on FOP support and the extension distribution idea...) >> >> > >would some of the currently core things then move into the 'extension' distro >(Velocity/FreeMarker/POI et al)? I'm unsure how this works.. > > > From what you're saying it sounds like it doesn't make sense to put it into the sandbox on the basis that FOP is immature. The question to me becomes how much we let Spring grow, and what are 'core' features that must ship with it, and what are 'extensions', and what are related projects? I was chatting a bit with Keith on the weekend about the validator stuff that's currently in the sandbox, but has become pretty mature, and is used by the Spring Rich Client Project, and could probably be of use to other Spring users. There's a question of where that would go. It's probably big enough that it should maybe be its own project, which is manageable I guess. But once you start splitting off all these little bits and pieces you open up the potential at least for a lot of dependency issues. Extensions I guess is a bit different than related project, since at least it would probably be built one-to-one with the main project... Colin |
|
From: Darren D. <da...@da...> - 2004-10-04 15:03:21
|
On Mon, October 4, 2004 15:10, Colin Sampaleanu said: > From what you're saying it sounds like it doesn't make sense to put it > into the sandbox on the basis that FOP is immature. Hi Colin, you replied to my post but I'm unsure if this is directed at me or Juerge= n..? If me, then in my opinion FOP itself is not that immature - their choice = of version number is simply inappropriate. FOP has been in fairly widesprea= d use for well over 3 years now. If not me, ignore the above :) Regards, --=20 Darren Davison Public Key: #DD356B0D |
