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

[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement

by ALRubinger

Hmm, this gets slippery. "scott.stark(a)jboss.org" wrote : The potential for 4 exists regardless of whether or not snapshots are used. Yes, but the question is - when? If snapshots in the parent are prohibited, projects get switched over to the new dependency's release very late in the game, nearing a milestone. That can hold up the whole works, because of: "scott.stark(a)jboss.org" wrote : Any update of the shared parent needs coordination and should result in rollback if existing builds fail. So now AS requires Dependency Version 2, which breaks EJB3. CR1 is held up because a switch was flipped right before the milestone, and EJB3 needs to resolve the errors before CR1 can ship. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136466#4136466 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136466

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Removing HSQLDB

by alex.guizar＠jboss.com

+1 to making H2 the default. It is not included in the JDK so we can ship it with whatever version we want. As for JavaDB, I've yet to hear any good comment about it, large footprint and slow performance are cited instead. Its only advantage is probably the Apache license. On the other hand, H2 will certainly require a larger footprint to support isolation, probably on par with JavaDB. For unit tests, space is not as big a concern as time, so overall I prefer H2 over JavaDB. I believe we should switch in the SOA branch first, for consistency with the ESB test environment and to better address the recent concurrency concerns. Once that is in a stable shape, we can merge the changes to head. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136464#4136464 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136464

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement

by scott.stark＠jboss.org

"ALRubinger" wrote : | What is the reasoning behind this? If snapshots are done only at the project level, then: | | 1) AS increments to snapshot of project A | 2) EJB3 remains on release 1 of project A | 3) AS requires release 2 of project A, updates shared parent | 4) EJB3 implicitly gets release 2 now, and has version conflict because it hasn't been seeing snapshot changes all along. Possible compile and runtime problems. | Too many projects are affected by an unknown release. A project may not even allow snapshot releases in its build policy. The potential for 4 exists regardless of whether or not snapshots are used. Any update of the shared parent needs coordination and should result in rollback if existing builds fail. Snapshots simply cannot be adequately coordinated in my view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136463#4136463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136463

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Shared Parent POM for dependencyManagement

by ALRubinger

"scott.stark(a)jboss.org" wrote : org.jboss:jboss-parent is too general for that. Yes, this is what I'm getting at. "scott.stark(a)jboss.org" wrote : We still need to get a handle on whether there is an acceptable version range policy (only minor version, custom jboss policy, etc.). Though related, and will affect the values of a shared parent, I don't think this is a requirement to move forward in centralizing the dependencies. "scott.stark(a)jboss.org" wrote : I would also suggest that snapshot version cannot be introduced into the common parent. It has to be done in the project. | What is the reasoning behind this? If snapshots are done only at the project level, then: 1) AS increments to snapshot of project A 2) EJB3 remains on release 1 of project A 3) AS requires release 2 of project A, updates shared parent 4) EJB3 implicitly gets release 2 now, and has version conflict because it hasn't been seeing snapshot changes all along. Possible compile and runtime problems. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136458#4136458 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136458

18 years

1
0
0 / 0

[Design of POJO Server] - Re: @RunAs annotations on Servlet Classes

by anil.saldhana＠jboss.com

Sure, Scott. If that is what is needed to end the rollercoaster ride of JBCTS-593, then there will I be. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136451#4136451 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136451

18 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Not very useful error message

by kabir.khan＠jboss.com

The error means that there is no container/domain found with the name "Intercepted Bean". I have replaced this exception with a log.warn() message, and will release by tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136440#4136440 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136440

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Group and artifact ID's

by pgier

I added a wiki page here: http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenProjectNaming The general maven convention is to use the base package name as the groupId. Some of the stuff in the repository now doesn't follow this convention so that it can have a direct mapping with the old location in the thirdparty repo. Eventually all the projects should follow this convention. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136438#4136438 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136438

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: Snapshot vs. release repository

by pgier

Which two repositories are you referring to? We're moving off of the jboss repository, so that we need to have one less repository. If you are asking about the maven snapshots and releases repositories, the reason is because the behaviour is different between the two. Snapshot builds are not stored in svn, deploying snapshots generates timestamped artifacts, and a few other differences. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136430#4136430 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136430

18 years

1
0
0 / 0

[Design of JBoss Build System] - Handling resource files in thirdparty dependencies

by rrajesh

Moving Paul's post to a separate thread: "I'm not sure about the best way to handle the "resources" folders in some of the app server dependencies. I created a workaround in the plugin that allows the plugin to copy files from the directory "thirdparty/src/main/resources" to the appropriate locations, but this has some drawbacks because these files are now version controlled in the app server source tree instead of their respective projects. In the long term maybe the projects should jar these files and create an artifact with a classifier of "resources" that can be downloaded to the appropriate place. So for example aop would have a file called something like "aop-2.0-resources.jar". I'm open to suggestions on this if anyone has ideas of how to best handle it. " We need to come up with a solution for this and have projects implement it, because the jbossws config files under "thirdparty/src/main/resources" are already outdated. Projects currently identified with resource files: jacorb aop jbossts jbossws messaging View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136428#4136428 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136428

18 years

1
0
0 / 0

[Design of JBoss Portal] - ContentResponse properties

by chris.laprun＠jboss.com

Any reason why they are immutable? There's basically no way (that I found at least) to add new properties after the ContentResponse is created and it's created without properties by MimeResponseImpl.getResponse()... Maybe I'm not understanding the proper usage, but I'd like to be able to add properties to the ContentResponse dynamically after it's created (i.e. in HeaderInterceptor to inject header content). Ideas? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136426#4136426 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136426

18 years

1
0
0 / 0

2026

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