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

[Design of JBoss Build System] - New Release Process

by pgier

Here is an outline of what we are thinking as far as a release process for jboss projects: 1) Project lead notifies all developers that no more commits should happen until the release is over. 2) Project lead runs mvn release:prepare -DdryRun=true. This verifies that all the build settings required for a release are available. The release version, and the new trunk version should be communicated to release engineering. 3) Release engineering team runs mvn release:prepare. This creates the tag in svn, and defines the version to be released. 4) Release engineering team runs mvn release:perform. This generates all artifacts from the new tag and deploys them to a staging server. 5) QA uses the artifacts on the staging server to verify that everything works correctly 1. If QA does not find any issues, go to step 6. 2.If QA does find issues with the build, the project goes back to development. Once the issues are resolved, the tag is deleted and the process goes back to step 2. 6)Release engineering promotes the files to production servers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032117#4032117 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032117

18 years, 11 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven repository being maintained?

by mosabua

Here is a list of JIRA issue numbers I added to: JBPM-899 JBRULES-522 JBSEAM-983 There are probably others that will result from these since the dependencies will also need to added to the repo. Thats it for now though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032114#4032114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032114

18 years, 11 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Maven repository being maintained?

by mosabua

Thanks guys. I will do that. Is there any plan to at least host the artifacts generated from the current build in the repo. All you would have to do it use the maven install plugin to install into a svn checkout of the repo and commit the new files. That would mean that the dependencies are not correct but at least the artifacts would be available somewhere. At the moment every Maven user will do that internally in their organisation or manually on their machine only. I will post a list of issues I comment/voted/watched a bit later. manfred View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032109#4032109 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032109

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by alesj

"kabir.khan(a)jboss.com" wrote : | Whereever it goes I think it will be a trivial change, so I will wait for you two to figure out whether it is part of the API or not. In any case the "lifecycle information holder" (currently LifecycleBeanMetaData) will need renaming/moving into something visble from the dependency project. Maybe ControllerContextAction's place is really plugins, but at least its .spi. package should be renamed. We could introduce new CallbackControllerContextAction (extends ControllerContextAction) which would define the API behind your callbacks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032091#4032091 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032091

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by kabir.khan＠jboss.com

Fixed mistakes in previous post View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032082#4032082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032082

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : The default implementation is to callback on the ControllerContext, | | i.e. the last step is necessarily going to happen if the context implementation | does not extend AbstractControllerContext. | You mean if a ControllerContext impl does NOT extend AbstractControllerContext then we miss out on the callbacks. "adrian(a)jboss.org" wrote : | I'm arguing that the lifecycle callbacks should apply to at least all | AbstractControllerContext implementations, not just POJO. | I agree and understand that "adrian(a)jboss.org" wrote : | Ales thinks that ControllerContextAction should be part of the API so it would | apply everywhere? Whereever it goes I think it will be a trivial change, so I will wait for you two to figure out whether it is part of the AOP or not. In any case the "lifecycle information holder" (currently LifecycleBeanMetaData) will need renaming/moving into something visble from the dependency project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032081#4032081 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032081

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Lifecycle aspects revisited

by adrian＠jboss.org

That's the same question that Ales has. :-) In practice, only AbstractControllerContext defines a per state callback. MC -> AbstractControllerContext -> ControllerContextAction The default implementation is to callback on the ControllerContext, i.e. the last step is necessarily going to happen if the context implementation does not extend AbstractControllerContext. I'm arguing that the lifecycle callbacks should apply to at least all AbstractControllerContext implementations, not just POJO. Ales thinks that ControllerContextAction should be part of the API so it would apply everywhere? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032058#4032058 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032058

18 years, 11 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Deployment failure

by thomas.heute＠jboss.com

Please use the User forum... I'm moving your topic View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032019#4032019 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032019

18 years, 11 months

1
0
0 / 0

[Design of JBoss Portal] - Deployment failure

by portal_man

Hello, I'm developping a simple portlet for Jboss portal 2.6 beta and i have a problem when I try to deploy it... When I copy my portlet in the repository %JBOSS_INSTALL%\server\defaut\deply before starting Jboss, Jboss can't start correctly (it block on my simple portlet war file ).However when i deploy my portlet after having started Jboss, this one functions correcty(so my WAR seems to correctly configured). Is this problem dependent with BETA Version ? I don't understant .... help ! thks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032018#4032018 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032018

18 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: spaces versus tabs

by tom.baeyens＠jboss.com

the code profile is checked in (2 spaces). if everyone uses spaces for indentation, that is the most important. if it matters for you, feel free to use another indentation size in your component consistently. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032008#4032008 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4032008

18 years, 11 months

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 2007