March 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Build System] - Re: Build Contract for jbossall-client.jar

by clebert.suconic＠jboss.com

Why not just change the build.xml on JBAS5-trunk/build to generate the file using classpath instead of exploding the files? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140300#4140300 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140300

17 years

1
0
0 / 0

[Design of EJB 3.0] - RoleBasedAuthorizationInterceptorFactory dependencies

by scott.stark＠jboss.org

A problem I see in the jbossas startup when an ejb3 deployment exists is the RoleBasedAuthorizationInterceptorFactory attempting to do a lookup for the java:/jaas/* content to obtain the security domain binding. With the current security refactoring, this context is established by a separate JBossSecurityJNDIContextEstablishment bean on which there is no dependency. For now that dependency should be part of the configuration specifying the RoleBasedAuthorizationInterceptorFactory. More … [View More]

17 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - The version format

by scott.stark＠jboss.org

Ok, osgi has a separate Bundle-Version header for the bundle version information which would be needed. The java spec/implementation manifest headers would default to the maven version format still. Looking at the: http://maven.apache.org/shared/maven-archiver/index.html#class_manifest there is no way to transform the version other than specifying a new set of header values. It really comes down to needing a version policy so that there is only one pom.version specification that gets mapped to … [View More]

17 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Build Contract for jbossall-client.jar

by ALRubinger

So...option 2 then. :) "ALRubinger" wrote : 2) We revisit the use of the manifest's Class-Path entry and share a common .mf file Where could this live? A new AS Component project with its own POM? Then it may be sucked in by the AS Assembly and AS Consumers. Requirements: * Needs to be consumable outside of AS * Must be easily maintained and bound to AS build cycle, so cannot be external project * Is not locked-down, so cannot be in "integration" S, ALR View the original post : http://… [View More]

17 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - The version format

by pgier

"scott.stark(a)jboss.org" wrote : | | The osgi versioning convention is simply what we describe as ours here: | http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning. Its just two short sections from the osgi r4 core spec: | | I understand the versioning from the spec, but I wasn't sure how these versions are actually used in the application when loading an OSGi component. Will we loose some compatibility if we use the maven standard for versions? Or can we put the … [View More]

17 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Build Contract for jbossall-client.jar

by scott.stark＠jboss.org

The solution we talked about being reasonable was to make the jbossall-client.jar a manifest only jar that references its content via the standard jar Class-Path manifest header. That way the client jars can easily be patched and jbossall-client.jar easily patched by updating the manifest, and there would be no duplicated content. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140273#4140273 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140273

17 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven Version ranges - The version format

by scott.stark＠jboss.org

"pgier" wrote : | I don't understand enough about how OSGi works, but as a second option, can we translate the maven version to something OSGi compatible in our builds? So maybe use the maven standard versions in our poms, but then put the equivalent OSGi version string into jar metadata, or somewhere else that it can be used? | The osgi versioning convention is simply what we describe as ours here: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning. Its just two short … [View More]

17 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Move dependency management back into app server svn stru

by ALRubinger

"adrian(a)jboss.org" wrote : 4) Longer term EJB3 wants to go its own way anyway so shared dependencies aren't even the correct solution. Yes, but in the interim, EJB3 requires the AS runtime and component-matrix was built to ensure that our compile/runtime dependencies would match. "adrian(a)jboss.org" wrote : 5) The correct way to integrate things is via interfaces NOT implementations. | | In my view EJB3 is just being lazy (can't be bothered creating a version | of EJB3 that isn't so … [View More]

17 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Build Contract for jbossall-client.jar (Repost)

by clebert.suconic＠jboss.com

The problem is maintaining it and repackaging it. There are things we can't repackage... Anyway... I don't take that decision... I had a similar request for JbossMessaging on jboss-dev-list, and that started a short discussion about jboss-allclient. I don't know if we should remove it or not.. but it can't be the way it's currently done. For instance, for JbossMessaging jbossall-client is next to useless as it doesn't include trove and some other thirdparty libraries we need. View the … [View More]

17 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Build Contract for jbossall-client.jar (Repost)

by clebert.suconic＠jboss.com

We need an input from Scott or Dimitris on this. (I was going to write this before but I pressed submit by accident) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140245#4140245 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140245

17 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008