This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In Java EE any jar can be a JavaEE module. The only requirement is the existence of the beans.xml file. NetBeans 7.4 does currently not offer "create beans.xml" for plain Maven "jar" projects. Make "create beans.xml" wizard available for JAR maven projects.
Do we support this in Ant?
I do not think it's supported in ant also. beans.xml depends on ee platform version, for ee6 and ee7 is different, current wizard handle it itself and it can't be used as it is for "plain" jar project. Also if we will add beans.xml and we will need to handle this project as ee after this addition it may be more complex issue rather then just enable/add a wizard here.
I believe we were looking into analogous requests for other kinds of files. For example, it may make sense to create a Servlet in a jar file (library project), and then put this jar file into WEB-INF/lib of a web module. Isn't that a similar case? > we will need to handle this project as ee after this addition What does that mean in terms of APIs, lookup content etc.? What exactly do we need from the project to make CDI support work on it? Thanks.
It may need to start support of any cdi hints and analysis, but it may be enabled by default nad may not be main problem, also there is no ee api on classpath by default, so beans can't be declared by default as *Scoped etc. I can't yet specify all possible issues here. I'm not sure we need to do this foe usual java application, it may nice to keep it as simple as possible, we may need to introduce some new project type like "ee library" instead.
Regarding analysis, currently it depends on server class path + existence of beans.xml and also beans.xml attributes, it will need to be different without server/ee classpath. or another approach we may allow to create ee files but without any verification if it's not ee project. But some users may complain. Unfortunately I don't know yet what ee environment will do with beans.xmL conflict and beans conflicts (unsatisfied and ambiguous dependencies) from different jars and if we should support this resolution in nb in hints/warnings/proposed fixes also. So my resolution the proper fix is complex but we may try to add something anyway, but we need some design decision in this case.
You are right about the classpath. The wizard should add the EE 7 (or EE 6) APIs to the classpath, if it's not already there. To address that aspect, IMO enhancement issue 231443 would be useful: then we would have an easy way to programmatically add EE APIs from the Maven repository to the classpath. Do you agree? An easier and less general solution would be to only implement enhancing the classpath for Maven projects, which do have an easy way to do that using the Maven project APIs.
if I got it right from "An archive which: contains a beans.xml file with the bean-discovery-mode of none, or, contains an extension and no beans.xml file is not a bean archive. An explicit bean archive is an archive which contains a beans.xml file: with a version number of 1.1 (or later), with the bean-discovery-mode of all, or, with no version number, or, that is an empty file. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation, or one or more session beans. When determining which archives are bean archives, the container must consider: Library jars, EJB jars or application client jars The WEB-INF/classes directory of a war Directories in the JVM classpath" It's not necessary to have beans.xml to be bean archive in cdi 1.1. I start to change my mind and may be just enable beans.xml creation without any special handling will be enough, also keep user responsibility to have ee api on classpath if necessary, and with the only additional option is to select version in beans.xml wizard. But I need to switch to issues fixes for now instead of new features, hope it can be reevaluated a bit later.
Regarding maven specific classpath, even the enhancement is filed for maven, it's nice to implement it similar way for ant/maven. User may want to choose if one want embedded jar on classpath or expose server classpath etc, if want full implementation or api only. Abien, can you provide more complete use case? Nice if there will be two,some simple and may be some more complex also, and/or cdi 1.0/1.1.