-
1. Re: Cleaned up security project
anil.saldhana Nov 28, 2006 11:27 AM (in response to starksm64)Some dependencies like XB have not really updated the maven artifacts.
I cannot build because I am pulling injboss/jbossxb/jbossxb/1.0.1.TEST
which defines a dependency on<dependency> <groupId>jboss.common.core</groupId> <artifactId>jboss-common-core</artifactId> <version>1.0.1.TEST</version> <scope>compile</scope> </dependency>
which does not exist.
What should be done here?
Maybe XB should do a maven update. -
2. Re: Cleaned up security project
starksm64 Nov 28, 2006 11:51 AM (in response to starksm64)There is no 1.0.1.TEST jboss-common-core so this dependency is wrong. There are two jbossxbs: one with a group id of jboss.jbossxb and another with a group id of jboss. We need to cleanup the maven repository and adopt a common group id convention of just jboss.
My security trunk is building, but it must be due to having built jbossxb and populating the local repository. We need a valid jbossxb release to the maven repo. I'll create a jira issue in jbossxb to get this done. -
3. Re: Cleaned up security project
anil.saldhana Nov 28, 2006 11:58 AM (in response to starksm64)For the time being, I changed the pom for xb for 1.0.1.TEST to use
<dependency> <groupId>jboss</groupId> <artifactId>jboss-common-core</artifactId> <version>2.0.2.GA</version> <scope>compile</scope> </dependency>
Once xb creates a formal maven release, we can update it. -
4. Re: Cleaned up security project
starksm64 Nov 28, 2006 12:00 PM (in response to starksm64)Actually I can find some jboss common 1.0.1.TEST artifacts under here for example:
http://repository.jboss.com/maven2/jboss/logging/jboss-logging-spi/1.0.1.TEST/
but I can't believe these are valid. The maven repo is just garbage right now. -
5. Re: Cleaned up security project
anil.saldhana Nov 28, 2006 12:20 PM (in response to starksm64)Not totally. All the xxx.xxx.TEST maven stuff is what Ruel did for POC.
So those projects need to have a formal maven release into the repo and all the xxx.TEST stuff thrown away. -
6. Re: Cleaned up security project
starksm64 Nov 28, 2006 12:21 PM (in response to starksm64)Another dependency that still needs to be cleaned up are these jbossas references:
<dependency> <groupId>jboss</groupId> <artifactId>jboss-j2ee</artifactId> <version>SNAPSHOT</version> </dependency> <dependency> <groupId>jboss</groupId> <artifactId>jboss-j2se</artifactId> <version>5.0-SNAPSHOT</version> </dependency> <dependency> <groupId>jboss</groupId> <artifactId>jboss-system</artifactId> <version>5.0-SNAPSHOT</version> </dependency> <dependency> <groupId>jboss</groupId> <artifactId>jboss-transaction</artifactId> <version>5.0-SNAPSHOT</version> </dependency> <dependency> <groupId>jboss</groupId> <artifactId>jboss</artifactId> <version>5.0-SNAPSHOT</version> </dependency> <dependency> <groupId>jboss</groupId> <artifactId>jnpserver</artifactId> <version>5.0-SNAPSHOT</version> </dependency> <dependency> <groupId>jboss</groupId> <artifactId>jboss-mbeans</artifactId> <version>5.0-SNAPSHOT</version> </dependency>
Some should just be removed and the security project refactored to remove the dependency. Others need the jbossas project to be splitup. -
7. Re: Cleaned up security project
starksm64 Nov 28, 2006 12:33 PM (in response to starksm64)"anil.saldhana@jboss.com" wrote:
Not totally. All the xxx.xxx.TEST maven stuff is what Ruel did for POC.
So those projects need to have a formal maven release into the repo and all the xxx.TEST stuff thrown away.
Yes. jbossxb has no valid maven release so I'll see what I can do about that today. -
8. Re: Cleaned up security project
starksm64 Nov 28, 2006 7:48 PM (in response to starksm64)Check that you can build trunk with the latest pom.xml. It has been updated to refer to the jbossxb-1.0.0.CR8 release which I created from the jbossxb-1.0.0.CR7 tag and just fixed the maven dependencies.
-
9. Re: Cleaned up security project
anil.saldhana Nov 28, 2006 8:40 PM (in response to starksm64)I can build the trunk.
I am going to be creating the sub projects in security along the lines of common. This will also make the dependencies matrix much clearer.
Thanks for doing the xb release as well as the research on maven publish to repositories(we need that) -
10. Re: Cleaned up security project
anil.saldhana Nov 29, 2006 3:52 PM (in response to starksm64)As part of http://jira.jboss.com/jira/browse/SECURITY-25, I created sub projects under security (security-spi, security-jboss-sx and security-optional) along the lines of the "common" project.
The optional sub project is currently empty.
I was not able to remove the aforementioned dependencies unless we start moving the low priority code into the optional subproject.When I removed the class "org.jboss.security.auth.login.LoginConfigInterceptor", I was able to get the MBeans dependency out
Do you remember why Dimitris wrote this interceptor? -
11. Re: Cleaned up security project
starksm64 Nov 29, 2006 4:17 PM (in response to starksm64)The jboss-transaction dependency is due to a simple utility class that really should be in the common or some j2ee util.
The LoginConfigInterceptor was a prototype to look at being able to introduce security configs by finding a login-config.xml in the deployment. Its obsolete for jboss5 and the vdf, and should in fact be a security config deployer in jbossas, not in the security project. -
12. Re: Cleaned up security project
anil.saldhana Nov 29, 2006 4:29 PM (in response to starksm64)"scott.stark@jboss.org" wrote:
The jboss-transaction dependency is due to a simple utility class that really should be in the common or some j2ee util.
The LoginConfigInterceptor was a prototype to look at being able to introduce security configs by finding a login-config.xml in the deployment. Its obsolete for jboss5 and the vdf, and should in fact be a security config deployer in jbossas, not in the security project.
The jboss-transaction dependency is due to DatabaseServerLoginModule. I already removed the LoginConfigInterceptor.
By the way, do you think it is worthwhile to basically list some of the classes with some of the doubtful dependencies, such that you can comment on where in jbas, it can be refactored? -
13. Re: Cleaned up security project
starksm64 Nov 29, 2006 4:38 PM (in response to starksm64)We need to list all the code pulling in the jbossas dependencies and then either rewrite it to avoid it, move it, or provide a legitimate jbossas spi jar. So yes, let's do that.
-
14. Re: Cleaned up security project
anil.saldhana Nov 30, 2006 12:16 PM (in response to starksm64)Some more:
<artifactId>jboss-system</artifactId> All the ServiceMBeanSupport extended MBean services are affected
Looks like jboss-system has a dependency on jboss-j2se, because removal of jboss-j2se makes ServiceMBeanSupport unhappy due to dependence on org.jboss.mx.util.JBossNotificationBroadcasterSupport<artifactId>jnpserver</artifactId> All the naming provide context factories choke (org.jboss.security.jndi)
I do not think we need jboss.jar. so that can be removed.