Re: GWT Widget as JAR
On 20 January 2011 13:39, Hilco Wijbenga wrote: > During development of a widget JAR, however, I need to be able to > change HTML/CSS and see the effect in the browser with a simple > refresh. I don't know how to do that without using a WAR. So how do > you work on your widgets? Or do you not run/try out your widgets > separately? Mmmh, it seems that war packaging is not required to get it to run with gwt:run and Jetty. I'm going to see how far I can get with a profile that adds support for running in DevMode. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: GWT Widget as JAR
Hi Jesse, I know all about Maven and how to do things in the mythical "Maven Way". I also understand GWT and GWT widgets. The problem is in the efficient combination. I would like to have a clean JAR for the widget and a WAR for integration testing (of that widget). That's all easy. During development of a widget JAR, however, I need to be able to change HTML/CSS and see the effect in the browser with a simple refresh. I don't know how to do that without using a WAR. So how do you work on your widgets? Or do you not run/try out your widgets separately? I'm sure that once a widget is "done", and used by a few apps, it doesn't need much TLC any more. The question is, how do you efficiently get to that stage? I take it you're happy with your process, so how do you go about creating a widget? Cheers, Hilco - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: GWT Widget as JAR
Hello, On Thu, Jan 20, 2011 at 1:24 PM, Hilco Wijbenga wrote: > On 20 January 2011 06:26, Jesse Farinacci wrote: >> >> This is by far the best solution. If you want to create widgets to be >> shared across multiple projects, just make a packaging=jar and make >> sure src/main/java is part of build.resources. Then include >> src/main/java/com/acme/gwt/client/MyWidget.java and >> src/main/resources/com/acme/gwt/MyWidgets.gwt.xml as part of the >> project and install it as per usual (mvn install). > > I agree but only from a build/Maven's point of view. This is the Maven mailing list.. ;-) And what's good for Maven is almost always good for the developers. If you find this not to be the case, I suggest you re-evaluate your process because fighting Maven isn't really worth it. Maven is opinionated software. >> I'm not unsympathetic to this, but you can't have it both ways. You >> either want re-usable components a la a library, which has a bit of >> steadiness to it, or you want rapid development -- they are competing >> goals. > > I think I *can* have it both ways. It's working now. :-) I didn't tell you any of the several philosophically non-Maven ways that would enable it to "work". I'm glad you got it working for you specifically, but everything you're apparently doing seems counter to Maven design goals. More soon. >>> Option 2: Put everything in a single WAR project. Integration testing >>> uses this WAR and development can make changes that are reflected >>> after a simple refresh. >> >> Yep, you can definitely do this, but it goes against the (unstated by >> OP) goal of reusability of components. > > It may not have been stated very clearly but it was certainly implied. > :-) Reusability is why I'm trying to do all this. Reusability.. hm. I am thinking about reusability of a particular GWT widget from multiple, possibly unrelated, consumer projects. Unnecessarily dumping everything into a WAR project seems incredibly naive and wasteful. You already admit that you're breaking Maven convention by producing multiple artifacts from the same module; you're forcing Maven to do something it doesn't want to, and you most likely (even if you aren't aware of why) don't want to do either. Unless you're creating a full-on web application, you shouldn't use the war packaging type. Reusable GWT widgets are best suited for jar packaging artifact. You can still run normal jUnit and HtmlUnit tests. I guess my mistake here is presuming that your generically reusable widget is actually tested outside of where you are using it in specific projects.. you seem to want to tweak this reusable widget as you are using it, as if it weren't fully developed when you start using it. This smells to me of you not fully understanding the needs of said widget ahead of time. That's fine, but let us agree that that design strategy is fully outside the realm of normal library engineering. >>> Problem: We need a JAR, not a WAR for our other GWT projects that want >>> to reuse the widget. >> >> Your war project which wants to incorporate the reusable widget jar >> need only to add and then >> utilize MyWidget somewhere. It will be properly compiled, and since >> you include src/main/java as part of the reusable widget's >> build.resources, GWT compiler will be happy. > > Not quite following you here. What you say is true, and it's what I'm > doing, but I don't see how it relates to the problem. I need a JAR, > not a WAR, as a dependency. (Well, strictly speaking, a WAR would work > too but I'd have to unzip it before using [parts of] it.) I think you're quite confused about how Maven should be utilized. And possibly about how WAR overlays work (which I am not recommending for your solution!), not to mention the GWT compiler. >>> The only "solution" that I can see is to go with option 2 and create a >>> second (JAR) project that depends on the WAR and strips away all its >>> "web-app-ness" to create the JAR I referred to in option 1. This >>> achieves all my goals but isn't very elegant. Can anyone think of a >>> better way to do this? >> >> Best of luck to you, I have had a lot of success with the method I've >> outlined. I have about two dozen general purpose widgets, twice that >> in general reusable GWT async services, and incorporated them into >> about 20 internal projects. Everything works quite nicely... > > I take it you don't have to deal with many other people (specifically > non-developer people). :-) But even if it were just me, it's really > nice to be able to see changes reflected after a refresh instead of a > full rebuild of both a JAR and a WAR. About a half dozen internal consumers of my GWT libraries who are human, other than me. I think your desire to be able to tweak these re-usable widgets on the fly demonstrates precisely that you are trying to force reusability as an afterthought. You're developing the widget as you need it, and want to get proper separation of concerns happening, but you're just not th
Re: GWT Widget as JAR
On 20 January 2011 06:26, Jesse Farinacci wrote: > Greetings Hilco, > > On Wed, Jan 19, 2011 at 8:07 PM, Hilco Wijbenga > wrote: >> >> Option 1: It's easy to write a POM that creates a JAR for a GWT widget >> including CSS and other resources. It's also easy to then write a POM >> that depends on that JAR and creates a WAR for integration testing. So >> far so good. > > This is by far the best solution. If you want to create widgets to be > shared across multiple projects, just make a packaging=jar and make > sure src/main/java is part of build.resources. Then include > src/main/java/com/acme/gwt/client/MyWidget.java and > src/main/resources/com/acme/gwt/MyWidgets.gwt.xml as part of the > project and install it as per usual (mvn install). I agree but only from a build/Maven's point of view. >> Problem: Making changes in (e.g.) the CSS requires a full rebuild of >> both the JAR and the WAR. This is a real productivity issue. > > I'm not unsympathetic to this, but you can't have it both ways. You > either want re-usable components a la a library, which has a bit of > steadiness to it, or you want rapid development -- they are competing > goals. I think I *can* have it both ways. It's working now. :-) >> Option 2: Put everything in a single WAR project. Integration testing >> uses this WAR and development can make changes that are reflected >> after a simple refresh. > > Yep, you can definitely do this, but it goes against the (unstated by > OP) goal of reusability of components. It may not have been stated very clearly but it was certainly implied. :-) Reusability is why I'm trying to do all this. I don't think it "goes against" this, it just makes it a bit harder. >> Problem: We need a JAR, not a WAR for our other GWT projects that want >> to reuse the widget. > > Your war project which wants to incorporate the reusable widget jar > need only to add and then > utilize MyWidget somewhere. It will be properly compiled, and since > you include src/main/java as part of the reusable widget's > build.resources, GWT compiler will be happy. Not quite following you here. What you say is true, and it's what I'm doing, but I don't see how it relates to the problem. I need a JAR, not a WAR, as a dependency. (Well, strictly speaking, a WAR would work too but I'd have to unzip it before using [parts of] it.) >> The only "solution" that I can see is to go with option 2 and create a >> second (JAR) project that depends on the WAR and strips away all its >> "web-app-ness" to create the JAR I referred to in option 1. This >> achieves all my goals but isn't very elegant. Can anyone think of a >> better way to do this? > > Best of luck to you, I have had a lot of success with the method I've > outlined. I have about two dozen general purpose widgets, twice that > in general reusable GWT async services, and incorporated them into > about 20 internal projects. Everything works quite nicely... I take it you don't have to deal with many other people (specifically non-developer people). :-) But even if it were just me, it's really nice to be able to see changes reflected after a refresh instead of a full rebuild of both a JAR and a WAR. The current setup is working quite nicely. My WAR project generates a JAR as well and this JAR contains just the files needed for a GWT widget. I was a little worried because the JAR and WAR share the same POM (with war) but that does not seem to be a problem. Cheers, Hilco - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: GWT Widget as JAR
Greetings Hilco, On Wed, Jan 19, 2011 at 8:07 PM, Hilco Wijbenga wrote: > > Option 1: It's easy to write a POM that creates a JAR for a GWT widget > including CSS and other resources. It's also easy to then write a POM > that depends on that JAR and creates a WAR for integration testing. So > far so good. This is by far the best solution. If you want to create widgets to be shared across multiple projects, just make a packaging=jar and make sure src/main/java is part of build.resources. Then include src/main/java/com/acme/gwt/client/MyWidget.java and src/main/resources/com/acme/gwt/MyWidgets.gwt.xml as part of the project and install it as per usual (mvn install). > Problem: Making changes in (e.g.) the CSS requires a full rebuild of > both the JAR and the WAR. This is a real productivity issue. I'm not unsympathetic to this, but you can't have it both ways. You either want re-usable components a la a library, which has a bit of steadiness to it, or you want rapid development -- they are competing goals. > Option 2: Put everything in a single WAR project. Integration testing > uses this WAR and development can make changes that are reflected > after a simple refresh. Yep, you can definitely do this, but it goes against the (unstated by OP) goal of reusability of components. > Problem: We need a JAR, not a WAR for our other GWT projects that want > to reuse the widget. Your war project which wants to incorporate the reusable widget jar need only to add and then utilize MyWidget somewhere. It will be properly compiled, and since you include src/main/java as part of the reusable widget's build.resources, GWT compiler will be happy. > The only "solution" that I can see is to go with option 2 and create a > second (JAR) project that depends on the WAR and strips away all its > "web-app-ness" to create the JAR I referred to in option 1. This > achieves all my goals but isn't very elegant. Can anyone think of a > better way to do this? Best of luck to you, I have had a lot of success with the method I've outlined. I have about two dozen general purpose widgets, twice that in general reusable GWT async services, and incorporated them into about 20 internal projects. Everything works quite nicely... -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: GWT Widget as JAR
On 19 January 2011 17:49, Wayne Fay wrote: >> achieves all my goals but isn't very elegant. Can anyone think of a >> better way to do this? > > A couple thoughts... > > 1) You can create a jar out of a war project by binding the jar plugin > to your build. Excellent, with a few excludes and attach-artifact I now have exactly what I need in a single POM. Thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: GWT Widget as JAR
> achieves all my goals but isn't very elegant. Can anyone think of a > better way to do this? A couple thoughts... 1) You can create a jar out of a war project by binding the jar plugin to your build. 2) You may want to look at the maven-remote-resources-plugin and think about putting the GWT widget in its own bundle. I guess this is pretty much option #1 though. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
GWT Widget as JAR
Hi all, Option 1: It's easy to write a POM that creates a JAR for a GWT widget including CSS and other resources. It's also easy to then write a POM that depends on that JAR and creates a WAR for integration testing. So far so good. Problem: Making changes in (e.g.) the CSS requires a full rebuild of both the JAR and the WAR. This is a real productivity issue. Option 2: Put everything in a single WAR project. Integration testing uses this WAR and development can make changes that are reflected after a simple refresh. Problem: We need a JAR, not a WAR for our other GWT projects that want to reuse the widget. The only "solution" that I can see is to go with option 2 and create a second (JAR) project that depends on the WAR and strips away all its "web-app-ness" to create the JAR I referred to in option 1. This achieves all my goals but isn't very elegant. Can anyone think of a better way to do this? Cheers, Hilco - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org