resteasy-developers — The main list for RESTEasy developers to discuss project development

[Resteasy-developers] grizzly?

[Martin A. <sp...@ma...>]

I'm a Grizzly nuub... when you run in Grizzly do you get our grizzly  
dependencies provided by the servlet container or do you need to  
include them in your war?

M

[Resteasy-developers] updated pom.xml

[Martin A. <sp...@ma...>]

Most pom.xml have been updated and tidied. I try to remove as much  
unnecessary duplication of code as possible (by pulling it up into the  
parent). I've also gone through the resteasy-jaxrs dependencies and  
marked optional as discussed - don't know if this is contentious, I  
hope not.

End result is that resteasy-jaxrs-war now pulls in very few jars (the  
bare minimum) - but I'd like to change this by declaring explicit  
dependencies in that war module to become the "full" drop in version  
with all libraries.

On another note - I disconnected jaxrs-api from the parent-pom  
structure since I think it will be tidier to treat this as a separate  
3rd party jar - I envisage that we eventually will stop having it  
local and get it from some authoritative maven distribution point. I  
also changed the version number of it to reflect the spec version (0.8  
I believe it is).

M

Re: [Resteasy-developers] Optional Libraries/distribution structure WAS Re: Providers and Future Bloat

[Martin A. <sp...@ma...>]

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

Re: [Resteasy-developers] some dirs

[Bill B. <bb...@re...>]

Martin Algesten wrote:
> Nah, I don't care particularly for it :)
> 
> The question I guess is whether you envisage to keep this test suite  
> working and whether it should be run on each release?
> 

YES!  It will be working and running on each release.  It is part of the 
testsuite and overall integration testing with JBoss, Spring, (and we 
probably need ones for Tomcat and Jetty).

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Providers and Future Bloat

[Bill B. <bb...@re...>]

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

Re: [Resteasy-developers] some dirs

[Martin A. <sp...@ma...>]

Nah, I don't care particularly for it :)

The question I guess is whether you envisage to keep this test suite  
working and whether it should be run on each release?

M

On 9 Jul 2008, at 14:42, Bill Burke wrote:

> Its just a test suite.  Do we really care about version numbers and  
> putting it into the repository?
>
> Martin Algesten wrote:
>> /*jboss-integration-testing*/ looks kinda abandoned with regards to  
>> version numbers and maven - should it be brought into line at some  
>> point, what's the plan?
>> /*assembly*/ is an empty folder - remove?
>> M
>> ------------------------------------------------------------------------
>> -------------------------------------------------------------------------
>> 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

[Resteasy-developers] Optional Libraries/distribution structure WAS Re: Providers and Future Bloat

[Bill B. <bb...@re...>]

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

Re: [Resteasy-developers] Providers and Future Bloat

[Martin A. <sp...@ma...>]

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

Re: [Resteasy-developers] Providers and Future Bloat

[Bill B. <bb...@re...>]

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

Re: [Resteasy-developers] Providers and Future Bloat

[Ryan J. M. <ry...@da...>]

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-

Re: [Resteasy-developers] Providers and Future Bloat

[Bill B. <bb...@re...>]

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

Re: [Resteasy-developers] some dirs

[Bill B. <bb...@re...>]

Its just a test suite.  Do we really care about version numbers and 
putting it into the repository?

Martin Algesten wrote:
> 
> /*jboss-integration-testing*/ looks kinda abandoned with regards to 
> version numbers and maven - should it be brought into line at some 
> point, what's the plan?
> 
> /*assembly*/ is an empty folder - remove?
> 
> M
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

Re: [Resteasy-developers] Providers and Future Bloat

[Martin A. <sp...@ma...>]

>> 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

Re: [Resteasy-developers] AsychronousDispatcher.java vs AsynchronousDispatcher.java

[Bill B. <bb...@re...>]

Ugh, Intellij f'd up.... sorry.

Ryan J. McDonough wrote:
> I just did an update and found that is both a  
> AsychronousDispatcher.java and a AsynchronousDispatcher.java. The SVN  
> repo confirm it as of version 250:
> 
> http://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/
> 
> I assume that was a refactoring and somehow the older version  
> (AsychronousDispatcher.java ) stuck around. If that's the case, I'll  
> delete it.
> 
> Just FYI, I ran into similar issues doing the major refactoring on the  
> 3rd, it was a real pain. The original files were not removed from the  
> repo on a refactor and the subsequent update ended up having both  
> package names.
> 
> Ryan-
> 
> -------------------------------------------------------------------------
> 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

Re: [Resteasy-developers] stale?

[Bill B. <bb...@re...>]

Martin Algesten wrote:
> I assume the source tree of interest is completely under:
> 
> https://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk/jaxrs
> 

and trunk/mom

> and the other stuff under
> 
> https://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk
> 
> is just old? (resteasy-mom, resteasy-resourcemanager etc etc)
> 

Yes, this is Ryan's old RESTEasy code (non-jaxrs).


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] ExceptionMapper + exceptions from an EJB invocation

[Bill B. <bb...@re...>]

:(

You'll have to wrap your own provider.  I brought up this issue of 
wrapped exceptions in the EG and we're addressing it, although you'll 
still have to write a provider even with that solution...

However, I should probably have some good EJB integration and have a 
ExceptionMapper for EJBException...

Adam Jordens wrote:
> Here’s the situation.
> 
> I’ve got a resource implemented as a Stateless EJB (/exposed via a Seam 
> application but that’s neither here nor there/).
> 
> @Stateless
> @Local(SpecimensClient.class)
> @Name("specimens")
> @Path("/rest/specimens")
> public class SpecimensBean implements SpecimensClient, Serializable
> {
>     public ExtSpecimen getSpecimen(Long id)
>     {
>         try
>         {
>             Specimen specimen = (Specimen)
>                     em.createQuery("XYZ").getSingleResult();
> 
>             ...     
>             return extSpecimen;
>         }
>         catch (NoResultException e)
>         {
>             throw new 
> WebApplicationException(HttpURLConnection.HTTP_NOT_FOUND);
>         }
>     }
> }
> 
> Now accessing that resource with an invalid id is resulting in the 
> WebApplicationException getting thrown.  However instead of it 
> propagating up as a InvocationTargetException with the 
> WebApplicationException as it’s cause, the InvocationTargetException is 
> wrapping an EJBException which in turn is wrapping the 
> WebApplicationException.
> 
> What’s the opinion on the best way to handle this, short of having to 
> implement a @Provider to do the unwrapping of the EJBException myself 
> (/which does seem to work/).
> 
> 
> Kind Regards,
> Adam  
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

Re: [Resteasy-developers] Providers and Future Bloat

[Ryan J. M. <ry...@da...>]

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

Re: [Resteasy-developers] Providers and Future Bloat

[Martin A. <sp...@ma...>]

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

Re: [Resteasy-developers] request: can we publish source artifacts to the maven repo

[Martin A. <sp...@ma...>]

Cool. I'm doing another pom cleanup to prepare for the release plugin.  
Is it okay to check it in? It changes all the poms.

M

On 9 Jul 2008, at 13:36, Ryan J. McDonough wrote:

> Martin,
>
> I cleaned up the POMs quite a bit last week. These pom changes were  
> not in beta-5 so its very likely that there's been no sources  
> published with those releases.
>
> Ryan-
>
> On Jul 9, 2008, at 3:38 AM, Martin Algesten wrote:
>
>>
>> And I'm now less confused - it's in the <pluginManagement> section,  
>> hence not used.
>>
>> M
>>
>> On 9 Jul 2008, at 09:34, Martin Algesten wrote:
>>
>>>
>>> And I'm confused - looking at the parent pom.xml it looks like the  
>>> stuff you suggest below is already there.
>>>
>>> M
>>>
>>> On 9 Jul 2008, at 09:11, Martin Algesten wrote:
>>>
>>>>
>>>> Hi Adam,
>>>>
>>>> Are you running against "released" beta versions or building your  
>>>> own jar from the source tree? I'm about to sort out releases  
>>>> using the maven-release-plugin which means the source code would  
>>>> be bundled anyway - doesn't help if you're compiling your own  
>>>> though.
>>>>
>>>> M
>>>>
>>>> On 9 Jul 2008, at 03:04, Adam Jordens wrote:
>>>>
>>>>> Essentially I’m asking if we can add the maven-source-plugin to  
>>>>> the resteasy-jaxrs-all parent artifact POM.
>>>>>
>>>>> Something similar to the following would probably suffice:
>>>>>
>>>>> <plugin>
>>>>>   <groupId>org.apache.maven.plugins</groupId>
>>>>>   <artifactId>maven-source-plugin</artifactId>
>>>>>   <version>2.0.2</version>
>>>>>   <executions>
>>>>>     <execution>
>>>>>       <goals>
>>>>>         <goal>jar</goal>
>>>>>       </goals>
>>>>>     </execution>
>>>>>   </executions>
>>>>> </plugin>
>>>>>
>>>>> It’s always nice to be able to debug with source code in your  
>>>>> IDE (IntelliJ in my case) and this helps automate that.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Adam
>>>>> -------------------------------------------------------------------------
>>>>> 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
>>
>> -------------------------------------------------------------------------
>> 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
>

Re: [Resteasy-developers] stale?

[Ryan J. M. <ry...@da...>]

On Jul 9, 2008, at 3:31 AM, Martin Algesten wrote:

>
> I assume the source tree of interest is completely under:
>
> https://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk/jaxrs
>
> and the other stuff under
>
> https://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk
>
> is just old? (resteasy-mom, resteasy-resourcemanager etc etc)


with the exception of resteasy-mom, the other projects are the initial  
version of RESTEasy wich are pre JAX-RS and before I started talking  
to Bill.

Ryan-

>
>
> M
>
>
> -------------------------------------------------------------------------
> 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

Re: [Resteasy-developers] request: can we publish source artifacts to the maven repo

[Ryan J. M. <ry...@da...>]

Martin,

I cleaned up the POMs quite a bit last week. These pom changes were  
not in beta-5 so its very likely that there's been no sources  
published with those releases.

Ryan-

On Jul 9, 2008, at 3:38 AM, Martin Algesten wrote:

>
> And I'm now less confused - it's in the <pluginManagement> section,  
> hence not used.
>
> M
>
> On 9 Jul 2008, at 09:34, Martin Algesten wrote:
>
>>
>> And I'm confused - looking at the parent pom.xml it looks like the  
>> stuff you suggest below is already there.
>>
>> M
>>
>> On 9 Jul 2008, at 09:11, Martin Algesten wrote:
>>
>>>
>>> Hi Adam,
>>>
>>> Are you running against "released" beta versions or building your  
>>> own jar from the source tree? I'm about to sort out releases using  
>>> the maven-release-plugin which means the source code would be  
>>> bundled anyway - doesn't help if you're compiling your own though.
>>>
>>> M
>>>
>>> On 9 Jul 2008, at 03:04, Adam Jordens wrote:
>>>
>>>> Essentially I’m asking if we can add the maven-source-plugin to  
>>>> the resteasy-jaxrs-all parent artifact POM.
>>>>
>>>> Something similar to the following would probably suffice:
>>>>
>>>> <plugin>
>>>>   <groupId>org.apache.maven.plugins</groupId>
>>>>   <artifactId>maven-source-plugin</artifactId>
>>>>   <version>2.0.2</version>
>>>>   <executions>
>>>>     <execution>
>>>>       <goals>
>>>>         <goal>jar</goal>
>>>>       </goals>
>>>>     </execution>
>>>>   </executions>
>>>> </plugin>
>>>>
>>>> It’s always nice to be able to debug with source code in your IDE  
>>>> (IntelliJ in my case) and this helps automate that.
>>>>
>>>>
>>>> Cheers,
>>>> Adam
>>>> -------------------------------------------------------------------------
>>>> 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
>
> -------------------------------------------------------------------------
> 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

Re: [Resteasy-developers] Providers and Future Bloat

[Martin A. <sp...@ma...>]

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

Re: [Resteasy-developers] Providers and Future Bloat

[Martin A. <sp...@ma...>]

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

[Resteasy-developers] some dirs

[Martin A. <sp...@ma...>]

jboss-integration-testing looks kinda abandoned with regards to  
version numbers and maven - should it be brought into line at some  
point, what's the plan?

assembly is an empty folder - remove?

M

Re: [Resteasy-developers] request: can we publish source artifacts to the maven repo

[Martin A. <sp...@ma...>]

And I'm now less confused - it's in the <pluginManagement> section,  
hence not used.

M

On 9 Jul 2008, at 09:34, Martin Algesten wrote:

>
> And I'm confused - looking at the parent pom.xml it looks like the  
> stuff you suggest below is already there.
>
> M
>
> On 9 Jul 2008, at 09:11, Martin Algesten wrote:
>
>>
>> Hi Adam,
>>
>> Are you running against "released" beta versions or building your  
>> own jar from the source tree? I'm about to sort out releases using  
>> the maven-release-plugin which means the source code would be  
>> bundled anyway - doesn't help if you're compiling your own though.
>>
>> M
>>
>> On 9 Jul 2008, at 03:04, Adam Jordens wrote:
>>
>>> Essentially I’m asking if we can add the maven-source-plugin to  
>>> the resteasy-jaxrs-all parent artifact POM.
>>>
>>> Something similar to the following would probably suffice:
>>>
>>> <plugin>
>>>   <groupId>org.apache.maven.plugins</groupId>
>>>   <artifactId>maven-source-plugin</artifactId>
>>>   <version>2.0.2</version>
>>>   <executions>
>>>     <execution>
>>>       <goals>
>>>         <goal>jar</goal>
>>>       </goals>
>>>     </execution>
>>>   </executions>
>>> </plugin>
>>>
>>> It’s always nice to be able to debug with source code in your IDE  
>>> (IntelliJ in my case) and this helps automate that.
>>>
>>>
>>> Cheers,
>>> Adam
>>> -------------------------------------------------------------------------
>>> 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