[Design of JBoss Build System] - Re: jboss common maven build
by pgier
"scott.stark(a)jboss.org" wrote : So let's get the first step of never looking to external repositories. Is this something that can be enforced at the project pom level, or does the user settings always allow for an override of the repo?
|
The central maven repo is defined in the super pom that all poms inherit from.
This repository can be disabled or overridden by defining a repository with the id "central" in your pom. I can change the jboss-parent pom so that the central repository is not used when performing a release. I would prefer to still allow the central repository during development builds, because this will allow us to download dependencies using the dependency plugin . The copy-dependencies goal can be used to copy all required dependencies for a project to a location on the file system. For example, a local checkout of the cvs repository.
I would like to have a separate thirdparty repository for this, because we might want the behaviour to be different between the jboss releases repo and the thirdparty repo, but for now we can just check in deps to the current repository (repository.jboss.org).
Does this sound ok?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032898#4032898
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032898
17 years, 9 months
[Design of POJO Server] - Re: Implicit container dependencies
by scott.stark@jboss.org
"wolfc" wrote : "adrian(a)jboss.org" wrote : This has been turned off in JBoss5 (at least for EJB2).
| |
| | 1) The code was not (is not) portable
| |
| | 2) Just because remote access to jndi (either another member of the cluster
| | or a thirdparty jms provider) is flakey, you don't want it to create a queue
| |
| | 3) It obscures the most common problem, which is that you mistyped the jndi name
| |
| I want this functionality. The feature is that if you're running EJB3 with JBoss Messaging, EJB3 will create a queue for you if needed.
|
| 1. We only do it when running JBoss Messaging, so it's not ment to be portable.
|
| 2. We don't stuff anything in JNDI, we ask JBoss Messaging for a queue.
|
| It's similar to JBCTS-541, only there j2ee-mods is asking for a queue. I don't see a problem in that. Either admin, j2ee-mods or EJB3 deployer is creating a queue.
|
| BTW. I want to get JBCTS-541 out of the way. Shall I create a new DestinationManager which hooks into ServerPeer?
Yes, update the existing cts porting layer to work. There is an example org.jboss.test.jbossmessaging.JBossMessagingAdmin implementation in the testsuite that I noted on the issue.
Whether or not the ejb container creates destinations has to be a manageable, metadata driven policy. This is ultimately overridable by the managment layer/policy service as whether or not a given environment allows for dynamic creation of destinations is an admin policy decision. It has nothing to do with whether ejb3 and jbm exist in the same environment.
In terms of ease of use for testing, embedded, you should be able to setup the metadata defaults to allow for this. That should be a trivial configuration of the externalized policy.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032893#4032893
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032893
17 years, 9 months