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

16 years, 1 month

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 generally this should be a jndi @Resource type of dependency that gets mapped to a bean that provides the jndi binding via an alias on an mc bean for example. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140298#4140298 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140298

16 years, 1 month

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 all of the version uses. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140281#4140281 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140281

16 years, 1 month

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://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140278#4140278 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140278

16 years, 1 month

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 OSGi compatible version string somewhere in our jars even though the pom has the maven compatible version? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140275#4140275 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140275

16 years, 1 month

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

16 years, 1 month

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 sections from the osgi r4 core spec: "osgi 4.0.1 core spec" wrote : | 3.2.4 Version | Version specifications are used in several places. A version token has the following grammar: | | version ::= | major( '.' minor ( '.' micro ( '.' qualifier )? )? )? | major ::= number | minor ::= number | micro ::= number | qualifier ::= ( alphanum | â_â | '-' )+ | | A version token must not contain any white space. The default value for a | version is 0.0.0. | | 3.2.5 Version Ranges | A version range describes a range of versions using a mathematical interval notation. See [31] Mathematical Convention for Interval Notation. | The syntax of a version range is: | | version-range ::= interval | atleast | interval ::= ( '[' | '(' ) floor ',' ceiling ( ']' | ')' ) | atleast ::= version | floor ::= version | ceiling ::= version | | If a version range is specified as a single version, it must be interpreted as the range [version,â). The default for a non-specified version range is 0, which maps to [0.0.0,â). | Note that the use of a comma in the version range requires it to be enclosed in double quotes. For example: | | Import-Package: com.acme.foo;version="[1.23, 2)", com.acme.bar;version="[4.0, 5.0)" | | In the following table, for each specified range in the left-hand column, a | version x is considered to be a member of the range if the predicate in the | right-hand column is true. | | Table 2 Examples of version ranges | Example Predicate | [1.2.3, 4.5.6) 1.2.3 <= x < 4.5.6 | [1.2.3, 4.5.6] 1.2.3 <= x <= 4.5.6 | (1.2.3, 4.5.6) 1.2.3 < x < 4.5.6 | (1.2.3, 4.5.6] 1.2.3 < x <= 4.5.6 | 1.2.3 1.2.3 <= x | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140272#4140272 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140272

16 years, 1 month

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 brittle to thirdparty implementation details and versions) | and forcing JBossAS to jump through hoops because of that. You assume that we have access to the SPI/API/interfaces required for us to build. At the moment, the "integration" project (http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/) holds SPIs for a whopping 3 projects. Until all of our AS Component dependencies are properly extracted into SPI/Impl, we'll depend on implementations and hence have a cyclic dependency preventing release. The EJB3 team's efforts towards Mavenization has lead to the discovery of cyclic dependencies in AS. The problems were already there, and the new build tool is bringing them to the surface. For this laziness, you are welcome. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140261#4140261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140261

16 years, 1 month

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 original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140243#4140243 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140243

16 years, 1 month

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

16 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008