Hello, On Thu, Jan 20, 2011 at 1:24 PM, Hilco Wijbenga <[email protected]> wrote: > On 20 January 2011 06:26, Jesse Farinacci <[email protected]> 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 <inherits name="com.acme.gwt.MyWidgets"/> 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 there yet. I think you'd be more along the Maven-way if you just created a test GWT application to exploit the general, reusable, widget. Then you could get instant feedback about how the widget looks and behaves without compromising library reusability. > 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 <packaging>war</packaging>) but that does not seem to be a > problem. Yah. This is a bastardization of everything that is holy in Maven. :-) Best of luck to you, really, but I am not going to get further involved trying to help a project that deliberately subverts all the good intentions of Maven -- and I suspect a lot of people on this list will state roughly the same thing. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
