Menu
▾
▴
resteasy-developers
|
From: Ryan J. M. <ry...@da...> - 2008-07-08 13:02:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I had a few more ideas for some other provider types and I realized that if we're not carful about, we could get fat really quickly. Here's a few provider ideas that Bill and I tossed around on this list: POI provider SVG Provider PGP/GPG Provider Given these 3 alone, we now have dependencies on the following projects: Jakarta POI Apache Batik Bouncy Castle or other PGP api It got me thinking: should we have an optional provider module(s)? Personally, I don't care. I think we've have the value-add of tons of kick-ass providers with no fuss, it wouldn't matter. But you know inevitably, there'd be a TSS article or collection of blog posts about how bloated RESTEasy is so bloated, yada yada yada. Does anyone else think this is a potential issue that we may want to address sooner than later? Ryan- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF CRyFIK8Gpu9B2FwzNs+vE+w= =fWJM -----END PGP SIGNATURE----- |
|
From: Martin A. <sp...@ma...> - 2008-07-08 13:06:25
|
It's nice to have the extras. But I'd like to see them in a separate jar. The main jar should imo just be a bare bones JAX-RS implementation. M On 8 Jul 2008, at 15:02, Ryan J. McDonough wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I had a few more ideas for some other provider types and I realized > that if we're not carful about, we could get fat really quickly. > Here's a few provider ideas that Bill and I tossed around on this > list: > > POI provider > SVG Provider > PGP/GPG Provider > > Given these 3 alone, we now have dependencies on the following > projects: > > Jakarta POI > Apache Batik > Bouncy Castle or other PGP api > > It got me thinking: should we have an optional provider module(s)? > Personally, I don't care. I think we've have the value-add of tons of > kick-ass providers with no fuss, it wouldn't matter. But you know > inevitably, there'd be a TSS article or collection of blog posts about > how bloated RESTEasy is so bloated, yada yada yada. Does anyone else > think this is a potential issue that we may want to address sooner > than later? > > Ryan- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF > CRyFIK8Gpu9B2FwzNs+vE+w= > =fWJM > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2008-07-08 13:56:56
|
Maybe a separate download/distro for optional providers? Ryan J. McDonough wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I had a few more ideas for some other provider types and I realized > that if we're not carful about, we could get fat really quickly. > Here's a few provider ideas that Bill and I tossed around on this list: > > POI provider > SVG Provider > PGP/GPG Provider > > Given these 3 alone, we now have dependencies on the following projects: > > Jakarta POI > Apache Batik > Bouncy Castle or other PGP api > > It got me thinking: should we have an optional provider module(s)? > Personally, I don't care. I think we've have the value-add of tons of > kick-ass providers with no fuss, it wouldn't matter. But you know > inevitably, there'd be a TSS article or collection of blog posts about > how bloated RESTEasy is so bloated, yada yada yada. Does anyone else > think this is a potential issue that we may want to address sooner > than later? > > Ryan- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF > CRyFIK8Gpu9B2FwzNs+vE+w= > =fWJM > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Martin A. <sp...@ma...> - 2008-07-09 09:50:04
|
I just ran into a snag here. I'm working on the pom.xml straightening out the dependencies. When depending on resteasy-jaxrs we currently pull in things like tjws and httclient. Basically I want all dependencies that are not required to fulfil the spec to be optional and not pulled in. This will require some work in RegisterBuiltin.java since it currently registers all providers whether optional or not. Required by spec: ByteArrayProvider DefaultTextPlain DataSourceProvider FormUrlEncodedProvider InputStreamProvider JAXBProvider StringTextStar (are we missing providers for Reader, File and javax.xml.transform.Source?) Optional: DataContentProvider (not in use, delete?) IIOImageProvider JettisonProvider MimeMultipartProvider StreamingOutputProvider M On 8 Jul 2008, at 15:58, Bill Burke wrote: > Maybe a separate download/distro for optional providers? > > Ryan J. McDonough wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I had a few more ideas for some other provider types and I realized >> that if we're not carful about, we could get fat really quickly. >> Here's a few provider ideas that Bill and I tossed around on this >> list: >> >> POI provider >> SVG Provider >> PGP/GPG Provider >> >> Given these 3 alone, we now have dependencies on the following >> projects: >> >> Jakarta POI >> Apache Batik >> Bouncy Castle or other PGP api >> >> It got me thinking: should we have an optional provider module(s)? >> Personally, I don't care. I think we've have the value-add of tons of >> kick-ass providers with no fuss, it wouldn't matter. But you know >> inevitably, there'd be a TSS article or collection of blog posts >> about >> how bloated RESTEasy is so bloated, yada yada yada. Does anyone else >> think this is a potential issue that we may want to address sooner >> than later? >> >> Ryan- >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.7 (Darwin) >> >> iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF >> CRyFIK8Gpu9B2FwzNs+vE+w= >> =fWJM >> -----END PGP SIGNATURE----- >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic >> lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Ryan J. M. <ry...@da...> - 2008-07-09 12:31:19
|
On Jul 9, 2008, at 5:49 AM, Martin Algesten wrote: > > I just ran into a snag here. I'm working on the pom.xml > straightening out the dependencies. When depending on resteasy-jaxrs > we currently pull in things like tjws and httclient. Basically I > want all dependencies that are not required to fulfil the spec to be > optional and not pulled in. > > This will require some work in RegisterBuiltin.java since it > currently registers all providers whether optional or not. > > Required by spec: > ByteArrayProvider > DefaultTextPlain > DataSourceProvider > FormUrlEncodedProvider > InputStreamProvider > JAXBProvider > StringTextStar > > (are we missing providers for Reader, File and > javax.xml.transform.Source?) > Yes. I am working on Source now. File is bit odd IMHO and warrents some more discussion. > Optional: > DataContentProvider (not in use, delete?) No, don't delete. This is still a WIP and it's being considered as required by JAX-RS. > IIOImageProvider This provider has no deps other than the JDK itself. I'd say leave it because it can come in handy and it's add no additional dependency. > JettisonProvider Leave, everyone wants JSON. RESTlet and Jersey will ship this by default. > MimeMultipartProvider Not required, but very much needed. RESTlet and Jersey will ship this by default. > StreamingOutputProvider StreamingOutput is required. It's at the top of page 22 in the latest spec. > > M > > > On 8 Jul 2008, at 15:58, Bill Burke wrote: > >> Maybe a separate download/distro for optional providers? >> >> Ryan J. McDonough wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> I had a few more ideas for some other provider types and I realized >>> that if we're not carful about, we could get fat really quickly. >>> Here's a few provider ideas that Bill and I tossed around on this >>> list: >>> >>> POI provider >>> SVG Provider >>> PGP/GPG Provider >>> >>> Given these 3 alone, we now have dependencies on the following >>> projects: >>> >>> Jakarta POI >>> Apache Batik >>> Bouncy Castle or other PGP api >>> >>> It got me thinking: should we have an optional provider module(s)? >>> Personally, I don't care. I think we've have the value-add of tons >>> of >>> kick-ass providers with no fuss, it wouldn't matter. But you know >>> inevitably, there'd be a TSS article or collection of blog posts >>> about >>> how bloated RESTEasy is so bloated, yada yada yada. Does anyone else >>> think this is a potential issue that we may want to address sooner >>> than later? >>> >>> Ryan- >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.7 (Darwin) >>> >>> iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF >>> CRyFIK8Gpu9B2FwzNs+vE+w= >>> =fWJM >>> -----END PGP SIGNATURE----- >>> >>> ------------------------------------------------------------------------- >>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>> Studies have shown that voting for your favorite open source >>> project, >>> along with a healthy diet, reduces your potential for chronic >>> lameness >>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>> _______________________________________________ >>> Resteasy-developers mailing list >>> Res...@li... >>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic >> lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08_______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Martin A. <sp...@ma...> - 2008-07-09 12:39:38
|
>> IIOImageProvider > > This provider has no deps other than the JDK itself. I'd say leave > it because it can come in handy and it's add no additional dependency. Yeah. In the tweak I treat it as optional since relying on it would tie you to the jax-rs implementation - however it would always be available since the dependency is in JDK. >> JettisonProvider > > Leave, everyone wants JSON. RESTlet and Jersey will ship this by > default. > >> MimeMultipartProvider > > Not required, but very much needed. RESTlet and Jersey will ship > this by default. Do you think it's a good change to dynamically load these depending on the existence of jettison and javax.mail respectively? I checked in a tweak that does just that. >> StreamingOutputProvider > > StreamingOutput is required. It's at the top of page 22 in the > latest spec. Yeah, I noticed. M |
|
From: Bill B. <bb...@re...> - 2008-07-09 13:02:43
|
Martin Algesten wrote: > Do you think it's a good change to dynamically load these depending on > the existence of jettison and javax.mail respectively? I checked in a > tweak that does just that. > Its a good tweak, but see my previous email about a configuration option for provders instead of RegisterBuiltin. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Bill B. <bb...@re...> - 2008-07-09 12:44:01
|
Martin Algesten wrote: > > I just ran into a snag here. I'm working on the pom.xml straightening > out the dependencies. When depending on resteasy-jaxrs we currently pull > in things like tjws and httclient. Basically I want all dependencies > that are not required to fulfil the spec to be optional and not pulled in. > tjws is required by the server. It is our shipped "embedded" JAX-RS server. Apache HttpClient is required by our client framework. > This will require some work in RegisterBuiltin.java since it currently > registers all providers whether optional or not. > I want to refactor RegisterBuiltin into an XML configuration file that lists providers that the user can remove/replace, etc... or maybe we can just list the providers in web.xml as a context param instead of having a separate Resteasy config file? I'm thinking users might like this more. > *Required by spec:* > ByteArrayProvider > DefaultTextPlain > DataSourceProvider > FormUrlEncodedProvider > InputStreamProvider > JAXBProvider > StringTextStar > > (are we missing providers for Reader, File and javax.xml.transform.Source?) > Mark Little might be implementing these. > *Optional:* > DataContentProvider (not in use, delete?) No, we need this for the spec. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Ryan J. M. <ry...@da...> - 2008-07-09 12:44:08
|
On Jul 9, 2008, at 5:49 AM, Martin Algesten wrote: > I just ran into a snag here. I'm working on the pom.xml > straightening out the dependencies. When depending on resteasy-jaxrs > we currently pull in things like tjws and httclient. Basically I > want all dependencies that are not required to fulfil the spec to be > optional and not pulled in. I this case, we've been talking about separating the client and common code from the resteasy-jaxrs code base. No doubt, client will have a dep on HTTPClient whereas resteasy-common and resteasy-jaxrs will not. I'd rather manage the dependencies that way than try and manage this in a single pom. I also don't want to get too carried away with this too. RESTEasy is still pretty small and we'd also like to the project to bring additional value over other JAX-RS implementations. I have some concerns with making every non-JAX-RS provider optional, even if it doesn't add any additional dependency to the developer. If we've got nothing to offer over the JAX-RS RI, why choose RESTEasy at all? I think we need to be a bit more pragmatic as to what is include in the stock RESTEasy distribution vs. what will be optional. No doubt, separating out client from server will help resolve some of those issues. My thinking is that if we have providers that require heavy 3rd-party dependencies, meaning you'd be pulling in more than 1 additional JAR that wouldn't likely be available by the JDK or an appserver, then it should be optional. With this line of thinking, the Multipart provider would be ok since the dependencies are generally included with the app server. Things like a POI or SVG provider would be optional since you'd now be looking at 2MB of dependencies. Thoughts? Ryan- |
|
From: Martin A. <sp...@ma...> - 2008-07-09 13:13:03
|
On 9 Jul 2008, at 14:44, Ryan J. McDonough wrote: > > On Jul 9, 2008, at 5:49 AM, Martin Algesten wrote: > >> I just ran into a snag here. I'm working on the pom.xml >> straightening out the dependencies. When depending on resteasy- >> jaxrs we currently pull in things like tjws and httclient. >> Basically I want all dependencies that are not required to fulfil >> the spec to be optional and not pulled in. > > I this case, we've been talking about separating the client and > common code from the resteasy-jaxrs code base. No doubt, client will > have a dep on HTTPClient whereas resteasy-common and resteasy-jaxrs > will not. I'd rather manage the dependencies that way than try and > manage this in a single pom. Okay. I agree the separation of the client code solves the dependency and is a nice thing to do. On 9 Jul 2008, at 14:46, Bill Burke wrote: > tjws is required by the server. It is our shipped "embedded" JAX-RS > server. Yeah. I understand what tjws is, but is it your intention to always include the tjws-jar file for everyone linking to resteasy? > I also don't want to get too carried away with this too. RESTEasy is > still pretty small and we'd also like to the project to bring > additional value over other JAX-RS implementations. I have some > concerns with making every non-JAX-RS provider optional, even if it > doesn't add any additional dependency to the developer. If we've got > nothing to offer over the JAX-RS RI, why choose RESTEasy at all? > I think we need to be a bit more pragmatic as to what is include in > the stock RESTEasy distribution vs. what will be optional. No doubt, > separating out client from server will help resolve some of those > issues. My thinking is that if we have providers that require heavy > 3rd-party dependencies, meaning you'd be pulling in more than 1 > additional JAR that wouldn't likely be available by the JDK or an > appserver, then it should be optional. With this line of thinking, > the Multipart provider would be ok since the dependencies are > generally included with the app server. Things like a POI or SVG > provider would be optional since you'd now be looking at 2MB of > dependencies. Thoughts? I don't think I've got insight enough to have an opinion on how RESTEasy sits compared to the JAX-RS RI. I should leave the strategy to you guys. I agree that providing lots of interesting providers and other value adds is a good way of differentiating. Another would be to be robust, fast and lean. These objectives don't preclude each other. I guess my main thought is to make it possible for the user to chose what functionality to use in RESTEasy. I.e. let the user decide whether they want those 3rd party jars (and the functionality that provides in RESTEasy) by declaring them <optional>. That way we can both ship the value-add at the same time as we don't clutter our user's project with jars they're not using. M |
|
From: Bill B. <bb...@re...> - 2008-07-09 13:19:18
|
Martin Algesten wrote: > On 9 Jul 2008, at 14:46, Bill Burke wrote: >> tjws is required by the server. It is our shipped "embedded" JAX-RS >> server. > > > Yeah. I understand what tjws is, but is it your intention to always > include the tjws-jar file for everyone linking to resteasy? > No, but it sure made creating the assembly easier ;) Especially since I'm such a maven noob. > I guess my main thought is to make it possible for the user to chose > what functionality to use in RESTEasy. I.e. let the user decide > whether they want those 3rd party jars (and the functionality that > provides in RESTEasy) by declaring them <optional>. That way we can > both ship the value-add at the same time as we don't clutter our > user's project with jars they're not using. > Most users won't care, IMO. What most users care about is how easy is it to get installed/running out-of-the-box. Plus, many users (most?) will not be using maven. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Bill B. <bb...@re...> - 2008-07-09 13:13:42
|
Ryan J. McDonough wrote:
> On Jul 9, 2008, at 5:49 AM, Martin Algesten wrote:
>
>> I just ran into a snag here. I'm working on the pom.xml
>> straightening out the dependencies. When depending on resteasy-jaxrs
>> we currently pull in things like tjws and httclient. Basically I
>> want all dependencies that are not required to fulfil the spec to be
>> optional and not pulled in.
>
> I this case, we've been talking about separating the client and common
> code from the resteasy-jaxrs code base. No doubt, client will have a
> dep on HTTPClient whereas resteasy-common and resteasy-jaxrs will not.
> I'd rather manage the dependencies that way than try and manage this
> in a single pom. I also don't want to get too carried away with this
> too. RESTEasy is still pretty small and we'd also like to the project
> to bring additional value over other JAX-RS implementations. I have
> some concerns with making every non-JAX-RS provider optional, even if
> it doesn't add any additional dependency to the developer. If we've
> got nothing to offer over the JAX-RS RI, why choose RESTEasy at all?
>
> I think we need to be a bit more pragmatic as to what is include in
> the stock RESTEasy distribution vs. what will be optional. No doubt,
> separating out client from server will help resolve some of those
> issues. My thinking is that if we have providers that require heavy
> 3rd-party dependencies, meaning you'd be pulling in more than 1
> additional JAR that wouldn't likely be available by the JDK or an
> appserver, then it should be optional. With this line of thinking, the
> Multipart provider would be ok since the dependencies are generally
> included with the app server. Things like a POI or SVG provider would
> be optional since you'd now be looking at 2MB of dependencies. Thoughts?
>
Well, there's two different types of users. One set just wants it as
easy as possible to run things, the other wants a fine tuned
distribution. IMO, the majority of users just want things to run.
That's why the zip just has a war file within it with everything so that
they can just plop the WAR file into Tomcat or their application server.
Since Resteasy is young, you want as few steps as possible to get things
to run. So, I'd like to keep a WAR that has everything within it
(except probably the client-framework pieces and tjws/grizzly).
For the 2nd type of user, I think we can solve that with documentation.
Specify which jars are optional which aren't.
So, maybe the distribution should look like this?
/lib/
/client/
httpclient.jar
resteasy-jaxrs-client.jar
/server/
resteasy-jaxrs.jar
tjws.jar
servlet-api.jar
(anything required by core server engine)
/providers/
resteasy-providers.jar
jettison.jar
(...any libraries optional providers pull in)
Another thought here is to just distribute a maven repository of
resteasy and its dependencies.
/resteasy-jaxrs.war/
WEB-INF/lib/
...all from lib/server
...all from lib/providers
Here we'd have duplicate libraries in distribution, but again, I want it
very easy to start up.
/docs/
javadocs/
docbook/
html/
html_single/
pdf/
Don't know if you've seen my previous email, but I wrote a tool to
scrape JBoss Wiki to generate docbook.
/examples/
example1/
build.xml (ant using /lib directories)
pom.xml (using repository.jboss.org)
We should have both ant and maven support. Many (most?) developers
still use ant.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Martin A. <sp...@ma...> - 2008-07-09 10:29:56
|
StreamingOutputProvider is required - missed that one. M On 9 Jul 2008, at 11:49, Martin Algesten wrote: > > I just ran into a snag here. I'm working on the pom.xml > straightening out the dependencies. When depending on resteasy-jaxrs > we currently pull in things like tjws and httclient. Basically I > want all dependencies that are not required to fulfil the spec to be > optional and not pulled in. > > This will require some work in RegisterBuiltin.java since it > currently registers all providers whether optional or not. > > Required by spec: > ByteArrayProvider > DefaultTextPlain > DataSourceProvider > FormUrlEncodedProvider > InputStreamProvider > JAXBProvider > StringTextStar > > (are we missing providers for Reader, File and > javax.xml.transform.Source?) > > Optional: > DataContentProvider (not in use, delete?) > IIOImageProvider > JettisonProvider > MimeMultipartProvider > StreamingOutputProvider > > M > > > On 8 Jul 2008, at 15:58, Bill Burke wrote: > >> Maybe a separate download/distro for optional providers? >> >> Ryan J. McDonough wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> I had a few more ideas for some other provider types and I realized >>> that if we're not carful about, we could get fat really quickly. >>> Here's a few provider ideas that Bill and I tossed around on this >>> list: >>> >>> POI provider >>> SVG Provider >>> PGP/GPG Provider >>> >>> Given these 3 alone, we now have dependencies on the following >>> projects: >>> >>> Jakarta POI >>> Apache Batik >>> Bouncy Castle or other PGP api >>> >>> It got me thinking: should we have an optional provider module(s)? >>> Personally, I don't care. I think we've have the value-add of tons >>> of >>> kick-ass providers with no fuss, it wouldn't matter. But you know >>> inevitably, there'd be a TSS article or collection of blog posts >>> about >>> how bloated RESTEasy is so bloated, yada yada yada. Does anyone else >>> think this is a potential issue that we may want to address sooner >>> than later? >>> >>> Ryan- >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.7 (Darwin) >>> >>> iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF >>> CRyFIK8Gpu9B2FwzNs+vE+w= >>> =fWJM >>> -----END PGP SIGNATURE----- >>> >>> ------------------------------------------------------------------------- >>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>> Studies have shown that voting for your favorite open source >>> project, >>> along with a healthy diet, reduces your potential for chronic >>> lameness >>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>> _______________________________________________ >>> Resteasy-developers mailing list >>> Res...@li... >>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic >> lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08_______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Martin A. <sp...@ma...> - 2008-07-09 11:48:26
|
Checked in a tweak to RegisterBuiltin that loads the optional providers dynamically if the library dependencies are detected on the classpath. M On 9 Jul 2008, at 12:29, Martin Algesten wrote: > > StreamingOutputProvider is required - missed that one. > > M > > On 9 Jul 2008, at 11:49, Martin Algesten wrote: > >> >> I just ran into a snag here. I'm working on the pom.xml >> straightening out the dependencies. When depending on resteasy- >> jaxrs we currently pull in things like tjws and httclient. >> Basically I want all dependencies that are not required to fulfil >> the spec to be optional and not pulled in. >> >> This will require some work in RegisterBuiltin.java since it >> currently registers all providers whether optional or not. >> >> Required by spec: >> ByteArrayProvider >> DefaultTextPlain >> DataSourceProvider >> FormUrlEncodedProvider >> InputStreamProvider >> JAXBProvider >> StringTextStar >> >> (are we missing providers for Reader, File and >> javax.xml.transform.Source?) >> >> Optional: >> DataContentProvider (not in use, delete?) >> IIOImageProvider >> JettisonProvider >> MimeMultipartProvider >> StreamingOutputProvider >> >> M >> >> >> On 8 Jul 2008, at 15:58, Bill Burke wrote: >> >>> Maybe a separate download/distro for optional providers? >>> >>> Ryan J. McDonough wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> I had a few more ideas for some other provider types and I realized >>>> that if we're not carful about, we could get fat really quickly. >>>> Here's a few provider ideas that Bill and I tossed around on this >>>> list: >>>> >>>> POI provider >>>> SVG Provider >>>> PGP/GPG Provider >>>> >>>> Given these 3 alone, we now have dependencies on the following >>>> projects: >>>> >>>> Jakarta POI >>>> Apache Batik >>>> Bouncy Castle or other PGP api >>>> >>>> It got me thinking: should we have an optional provider module(s)? >>>> Personally, I don't care. I think we've have the value-add of >>>> tons of >>>> kick-ass providers with no fuss, it wouldn't matter. But you know >>>> inevitably, there'd be a TSS article or collection of blog posts >>>> about >>>> how bloated RESTEasy is so bloated, yada yada yada. Does anyone >>>> else >>>> think this is a potential issue that we may want to address sooner >>>> than later? >>>> >>>> Ryan- >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.7 (Darwin) >>>> >>>> iD8DBQFIc2VPK/xjmUY6JwURAqFAAKCBdgm+Rcz7Yg2jXLViRoVACRjKBwCgkweF >>>> CRyFIK8Gpu9B2FwzNs+vE+w= >>>> =fWJM >>>> -----END PGP SIGNATURE----- >>>> >>>> ------------------------------------------------------------------------- >>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>> Studies have shown that voting for your favorite open source >>>> project, >>>> along with a healthy diet, reduces your potential for chronic >>>> lameness >>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>> _______________________________________________ >>>> Resteasy-developers mailing list >>>> Res...@li... >>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> >>> ------------------------------------------------------------------------- >>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>> Studies have shown that voting for your favorite open source >>> project, >>> along with a healthy diet, reduces your potential for chronic >>> lameness >>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>> _______________________________________________ >>> Resteasy-developers mailing list >>> Res...@li... >>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic >> lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08_______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08_______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Martin A. <sp...@ma...> - 2008-07-09 13:39:58
|
On 9 Jul 2008, at 15:15, Bill Burke wrote: > Well, there's two different types of users. One set just wants it > as easy as possible to run things, the other wants a fine tuned > distribution. IMO, the majority of users just want things to run. > That's why the zip just has a war file within it with everything so > that they can just plop the WAR file into Tomcat or their > application server. Since Resteasy is young, you want as few steps > as possible to get things to run. So, I'd like to keep a WAR that > has everything within it (except probably the client-framework > pieces and tjws/grizzly). > > For the 2nd type of user, I think we can solve that with > documentation. Specify which jars are optional which aren't. > > So, maybe the distribution should look like this? > > /lib/ > /client/ > httpclient.jar > resteasy-jaxrs-client.jar > /server/ > resteasy-jaxrs.jar > tjws.jar > servlet-api.jar > (anything required by core server engine) > /providers/ > resteasy-providers.jar > jettison.jar > (...any libraries optional providers pull in) > > Another thought here is to just distribute a maven repository of > resteasy and its dependencies. > > > /resteasy-jaxrs.war/ > WEB-INF/lib/ > ...all from lib/server > ...all from lib/providers > > Here we'd have duplicate libraries in distribution, but again, I > want it very easy to start up. > > > /docs/ > javadocs/ > docbook/ > html/ > html_single/ > pdf/ > > > Don't know if you've seen my previous email, but I wrote a tool to > scrape JBoss Wiki to generate docbook. > > /examples/ > example1/ > build.xml (ant using /lib directories) > pom.xml (using repository.jboss.org) I agree this looks like a sensible layout for the full fledged out-of- the-box distribution. It doesn't matter we're repeating jars - this is for people that want something running quickly. > We should have both ant and maven support. Many (most?) developers > still use ant. Most use ant?! I certainly hope not :) I think there's two things two different questions in here. One is what we use to build/distribute RESTEasy. This hardly matters for anyone but us, and maven is an excellent choice. The other is how people are using the library in their own projects. It seems we're arriving in two distributions here, one .zip which is like a kitchen sink, it just has everything to run quickly, the other is the standalone jars. If we get maven configured correctly this provides a way of downloading the jar as well as linking to the pom.xml to get dependencies right. I don't see how ant comes into the picture? M |
Thanks for helping keep SourceForge clean.
X