Who decided they're not going to support EAP6.0? Your company or JBoss/Red Hat?
I don't think the jboss community version fully support Maven, at least not for jboss.org 5.0 and earlier (which EAP 5 is based on). The thing is that it is hard to do magic when the individual components don't use Maven. For jboss.org 7+ (which EAP 6 is based on) Maven will be used, from what I've heard, so then they will be able to support a EAP repo. But I believe that two of the main Maven guys at Jboss are listening to this list so they could clarify? /Anders On Fri, Dec 2, 2011 at 13:39, Steve Cohen <[email protected]> wrote: > On 12/02/2011 01:47 AM, Anders Hammar wrote: >> >> I recognize your situation and here's what I've done for JBoss EAP >> (4.3 and 5.0): >> >> For all the runtime artifacts of the platform, I've created a tool >> that analyzes the dependencies between those artifacts. Based on this >> information I've created poms for all the artifact with this >> dependency info. The approach has been a best-effort, and might not be >> absolutely correct. For example, I'm not sure that dependencies due to >> annotations will be reflected. >> >> For the GAVs I've decided to give all artifacts the same groupId >> ("mycompany-jbosseap"), the artifactId is the original name of the jar >> and the version is the version number of the complete platform >> ("5.0.0.GA" for example). >> The reason for the groupId was to make sure that there would never be >> clash with something that JBoss/Red Hat would release. Using the >> version number of the platform is because it almost impossible to >> figure out the original version of some of the artifacts. >> >> Also, I've created import poms with dependencyManagement for all the >> artifacts. I have such an import pom for server side (the production >> server config) and one for client side. >> >> This approach works ok, but there are drawbacks. Also, some of the >> original decision I would probably do differently today if I started >> from a clean sheet. >> One drawback is that you could get the same artifact included twice, >> if some 3rd party dependency uses it's original GA. For example, >> "servlet-api" as it's original groupId is "javax.servlet" and not >> "mycompany-jbosseap". This is not a problem for a knowledgeable Maven >> user as you just add exclusions. But for normal developers I find that >> this is magic and they normally never analyze their dependency tree. >> If I would do this again, I would spend time figuring out the correct >> groupId (and artifactId) for the artifactId, at least for the >> non-jboss ones (many of the jboss ones have changed groupId recently, >> which make them tricky). The version number could then be some thing >> like "5.0.0.GA-jbosseap" to make sure it would not interfere with any >> official version. >> >> All developers are instructed to use these artifacts instead of any >> other, if possible. This will ensure that even compilation is done >> towards what will be the runtime platform. Then unit testing will use >> the same artifacts as are used in runtime. Any issues will be found as >> early as possible, which is important IMHO. >> >> A (customized) zip of the platform is also available from the repo. >> Which makes it possible to use Codehaus Cargo to automate ITs where >> the app server is installed, configured, started, and the application >> deployed to, as part of a Maven build. Quite nifty if you ask me. >> >> If you're in fact using JBoss EAP, I should inform you that Red Hat >> has created their own EAP 5.0 Maven repo. However, they do not have >> any dependency information in their poms which make their solution >> less good than mine IMO. They claim this will be fixed for the EAP 6.0 >> repo as Maven will then be used to build the platform. If I recall >> correctly they have the correct groupIds and artifactIds though. >> Search for "Project Wolf" to find out more. >> >> /Anders >> On Thu, Dec 1, 2011 at 21:00, Steve Cohen<[email protected]> wrote: >>> >>> I am perplexed by the following situation: >>> >>> I work for a very large corporation with strict bureaucratic rules about >>> what you can use. Nonetheless, they have a maven repository administered >>> by >>> very helpful people. However the maven repository people don't talk so >>> much >>> to the technical standards people (they don't even know each other) and >>> therein lies the problem. >>> >>> The technical standards folks mandate that certain versions of >>> application >>> servers (for example, JBoss) must be used. These are not the publicly >>> available versions commonly found but "enterprise versions" that are >>> either >>> built by RedHat for specific corporate clients or available to any paying >>> corporate client, I'm not sure which. These come packaged in .zip files >>> that may be downloaded from an internal corporate web site. >>> >>> That would be okay if all I was concerned about was creating a server to >>> develop on. But I also need to develop against the "targeted runtime" of >>> that server, and I want to use Maven, as I could with the publicly >>> available >>> versions of the server. To do that, I need to have these server runtime >>> jars as "Provided" dependencies in my project. However, there are no >>> poms >>> included with this zip file. I could load every jar in the package into >>> a >>> team-private "third party" repo in the central repo, but this would then >>> be >>> just a bunch of jars with no inter-dependency information available. >>> Even >>> if POMs were available, getting them all into the repository is a >>> non-trivial task. >>> >>> How does one cope with this situation? >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > Thanks, as I feared. What a piece of @#$$%. So those who pay for JBoss get > development tools worse than the community version and those who negotiate > such contracts don't know what Maven is. And they've already decided they > are NOT going to support EAP6.0 for some reason and go straight to EAP 7.0 > when they finally move off EAP 5. So it will be like never before we get > the support we need. I guess I will just manually put in the repo and call > dependencies those things that I import in my code. Ridiculous. If they > can do it for the community version why can't they do it for the EAP > version? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
