Weld Maven 2 Archetype Proposal| JBoss.org Content Archive (Read Only)

15. Re: Weld Maven 2 Archetype Proposal

dan.j.allen Nov 9, 2009 6:38 AM (in response to sboscarine)

This is also recommended since eventually, the presence of faces-config.xml is what will activate JSF rather than the servlet definition in web.xml. That's true on GlassFish v3 today, but hopefully in the spec very soon.

16. Re: Weld Maven 2 Archetype Proposal

sboscarine Nov 9, 2009 2:43 PM (in response to sboscarine)

Dan Allen wrote on Nov 09, 2009 06:24:

Why is jetty-env.xml in src/test/resources and not src/main/resources?

As you mentioned in the next post, it'll get packaged into the war. Regarding src/jetty/resources or src/main/webapp-jetty...

The fundamental question is where should Jetty-specific configuration go?

In my mind, the archetype is meant to be optimized to help the novice programmer or new weld user start a project.

There are many effective solutions to this problem, in my opinion, we should choose what is friendliest to the most common archetype user. I personally think we should balance technical elegance to friendliest to the point that we create the friendliest starting point that doesn't have any stupid technology decisions in it.

What is the popular convention for which directory to store your jetty-env.xml in?

To my knowledge, there is no popular convention yet. I quickly glanced at their documentation this morning and it appears they advocate putting it in the WEB-INF dir
http://docs.codehaus.org/display/JETTY/jetty-env.xml. That's not suitable to me as the instant you start doing useful work, some password or sensitive information will end up in that file (JDBC, SMTP, Encryption, etc) and we don't want someone with access to the war files figuring out the testing values if there is an easy alternative.

I personally still like putting things in src/test/resources for a bunch of small reasons.

For one thing, any maven-enabled IDE will recognize it as a source folder without extra configuration.

I don't think it is semantically incorrect to call jetty-env.xml testing configuration as I don't thing many people actually deploy to Jetty today. I think most Jetty users use it for testing but ultimately deploy to Tomcat, JBoss, or another container. When I run the app in Jetty, I am personally always testing.

If you never plan on using Jetty and just use another container, I think it's friendlier to delete the file than a configuration folder.

I think jetty-specific folder are perfect if you're dedicated to using Jetty. I'd guess that over half of the users won't, so deleting jetty-env.xml from src/test/resources is quick and easy. I don't think any harm comes from having it available in your unit test's classpath.

I think novice users will get intimidated by lots of folders or profiles in pom.xml. If the generated app looks like every application they've seen in the past, I think it'll be a better experience and less overwhelming.

Of course, I don't feel TOO strongly about this. This isn't for me, but for the community, and I don't have the final say. What do you people think?

17. Re: Weld Maven 2 Archetype Proposal

sboscarine Nov 9, 2009 4:00 PM (in response to sboscarine)

Dan Allen wrote on Nov 09, 2009 06:13:

Also, I think you should add the empty faces-config.xml file. Otherwise, it's a pain for developers to have to go find the right root declaration when creating one. It's easy enough to delete.

Great suggestion. I think that will be very helpful. I've put it up on the latest prototype:

src/main/resources/archetype-resources/src/main/webapp/WEB-INF/faces-config.xml

18. Re: Weld Maven 2 Archetype Proposal

dan.j.allen Nov 9, 2009 6:53 PM (in response to sboscarine)

I think you may be overthinking this a bit. I am a big believe in gut instinct and not in arbitrary conventions that someone has claimed to define. To me, and many others, it's perfectly clear what is going on when you use src/main/webapp-jetty (or even src/jetty/webapp, though I prefer the former).

I really don't see why you would ever want jetty-env.xml in src/test/resources. It's not a resource file, it's a web artifact. So it should be in something with webapp in it.

19. Re: Weld Maven 2 Archetype Proposal

dan.j.allen Nov 9, 2009 8:15 PM (in response to sboscarine)

Wherever you have @Named @RequestScoped you can now use @javax.enterprise.inject.stereotype.Model (as of Weld 1.0, which is being released as I write this).

20. Re: Weld Maven 2 Archetype Proposal

sboscarine Nov 9, 2009 8:44 PM (in response to sboscarine)

Dan Allen wrote on Nov 09, 2009 06:08:

Many of the Weld developers are running JBoss AS continuously and will have to change this setting each time. These are the ports we tend to use:

JBoss AS - 8080

Tomcat - 8080 (I know, the same as JBoss AS, but folks tend to pick either JBoss AS or Tomcat and stick with it)

GlassFish - 7070

Embedded Jetty (or Tomcat) - 9090

Makes sense. I'll be happy to put those changes in. I'll try to get them in tonight.

Are you talking about JBoss launched from the IDE or running as a service? If you have a cool means of developing (publishing changes to a running container) that differs from standard Eclipse WTP, that might be something cool to add to the getting started guide.

21. Re: Weld Maven 2 Archetype Proposal

dan.j.allen Nov 9, 2009 8:57 PM (in response to sboscarine)

Meaning JBoss AS running standalone. We just don't want devs to run into errors starting the embedded if they have JBoss AS running as a service (which is going to be pretty typical in this crowd).

As for deploying changes to a running server, I don't really have anything that I can suggest. The Maven 2 JBoss plugin just does a reploy, much like the Tomcat plugin does (tomcat:deploy, tomcat:undeploy, jboss:deploy, jboss:undeploy). So the best we can support for JBoss at this point is a replacement of the deployed app.

22. Re: Weld Maven 2 Archetype Proposal

barbacena Nov 10, 2009 3:04 AM (in response to sboscarine)

Hi,

As with faces-config.xml maybe we could have this following besides a empty beans.xml.

<beans xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
    http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
<alternatives />
<decorators />
<interceptors />
</beans>

Nice work. Hope to see HelloWorldTest.java soon.

23. Re: Weld Maven 2 Archetype Proposal

dan.j.allen Nov 10, 2009 3:25 AM (in response to sboscarine)

Great suggestion!

24. Re: Weld Maven 2 Archetype Proposal

sboscarine Nov 10, 2009 3:48 AM (in response to sboscarine)

Marcell Barbacena wrote on Nov 10, 2009 03:04:

Nice work. Hope to see HelloWorldTest.java soon.

So do I. :) I am following JBoss' lead on this one. As soon as they publish recommendations, I'll get them in there.

I added the beans.xml boilerplate you recommended.

25. Re: Weld Maven 2 Archetype Proposal

sboscarine Nov 10, 2009 4:02 AM (in response to sboscarine)

Dan Allen wrote on Nov 09, 2009 06:35:

Unless I put beans.xml in src/main/resources/META-INF, the application does not pick up the helloWorld bean when I run:
mvn clean
mvn jetty:run

That is a major breakthrough. It publishes classes now!
Change added.

26. Re: Weld Maven 2 Archetype Proposal

sboscarine Nov 10, 2009 4:10 AM (in response to sboscarine)

Dan Allen wrote on Nov 09, 2009 06:22:

Don't know why this happens. Do we need these lines in the parent?
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

That's pretty disappointing. I added the change. Hopefully maven will do something about this in a future version.

27. Re: Weld Maven 2 Archetype Proposal

sboscarine Nov 10, 2009 4:25 AM (in response to sboscarine)

Dan Allen wrote on Nov 09, 2009 06:32:

Also, I suggest you should use Jetty's web.xml override mechanism to register the listener and JNDI resource.

Sorry if this is a dumb question. My wife secretly replaced my regular coffee with decaf this morning :)

Why do we want to do this?

Isn't org.jboss.weld.environment.servlet.Listener required for Tomcat?

28. Re: Weld Maven 2 Archetype Proposal

dan.j.allen Nov 10, 2009 5:02 AM (in response to sboscarine)

Ah, now I get what you were saying about it not publishing the classes. Our brains were operating on parallel planes. Yes, this seems to be a limitation of the Weld scanner that it can't make the connection between the Maven classpath and the WEB-INF directory when running on top of embedded Jetty.

Anyway, the solution is reasonable enough. I mean really, you don't really need beans.xml to be in WEB-INF anyway. It makes more sense to me to have it in the classpath, wherever that is.

29. Re: Weld Maven 2 Archetype Proposal

dan.j.allen Nov 10, 2009 5:12 AM (in response to sboscarine)

Not a dumb question. The logic depends on the context. I just need to explain where I am going with this.

Using override-web.xml is about multi-container support. In an official CDI environment (as defined by the spec) the web.xml does not need to have any special elements. When you use CDI in servlet containers, you have to add-on additional configuration. Therefore, if you think about this as a progressive configuration, then you want all the extra elements to appear in addon or override files. Hence, the need for Jetty's overrideWebXml.

Of course, you need the same thing for Tomcat as well, but again, Tomcat support is an addon. The downside is that Tomcat doesn't have an overrideWebXml configuration element. So, I'll admit that the approach does break down there. Perhaps we need to patch the Tomcat Maven plugin to add this ability.

But still, I need to explain why we are adding on. Well, to support a standard environment, you should be able to use the base configuration. That would be a web.xml w/o any listeners. So if I ran:

mvn package

then by default I should get a WAR ready to run on Java EE 6. If I add a profile, like Jetty, then it activates the override file and adds any additional JARs.

mvn package -Pjetty

I feel strongly about using profiles even if you only have one profile and it is active by default. It's a matter of documentation. We don't want people to think they always need weld-servlet.jar. They should understand that they need that when using the Jetty or Tomcat container profile. Same with the Weld listener.