Release Process
by Marshall Culpepper
Hey guys..
I wanted to hash out the release process we're going to use for the
upcoming betas and GAs of JBossTools and RHDS.
Below I've listed what I think should be our release process moving
forward. This is heavily based on the process we used for JBossIDE, with
some changes to accomodate our new QA resources.
1) All top level components (i.e. "jsf", "richfaces", "hibernatetools",
"as", etc) are given a tag. In the case of major releases (GAs / major
functionality changes), we branch instead of tag. In the case of a
branch, we use HEAD of that branch as the tag (any changes needing to be
made during the release process will be just committed to HEAD in that
branch rather than re-tagging/re-branching)
2) An integration build is ran on those tags. If there are any errors in
the build, the offending components must fix any code/bugs and re-tag.
3) All component owners do smoke testing of their respective code (this
is just a smoke test to ensure things are working properly).
4) If there are any problems in the smoke testing, the component owner
is responsible for making the change, re-tagging, and we will re-run the
integration build (coming back to step #2)
5) Once we have an integration build that everyone is happy with, we
will run the release build, and pass that on to QA for testing. Any
problems in this process go back to step #2 for fixing/re-tagging
(though at this point we continue with release builds instead of
integration builds)
6) When QA gives the thumbs up we can make the release. The build is
uploaded to our update site, which receives one last smoke test from
each component lead. (Any problems are fixed/re-tagged/re-tested).
7) Finally we upload the release to Sourceforge, our build server, the
public update site, and make the announcement on forums, blogs, the
download pages, etc.
--
Marshall Culpepper
Redhat Dev Studio, JBoss Tools
http://jboss.org/tools
email: marshall(a)jboss.org
skype: marshall.culpepper
17 years, 4 months
Core Plugins
by Rob Stryker
Hi. Just thought I'd let you all know what I'm doing in SVN right now,
and with the core plugins.
As Marshall outlined a month ago in email, most of the core plugins are
simply legacy. Some do contain functionality we'd like to keep, others
do not. Last night I moved several of the ones that are definitely not
going to be included into a new legacy folder. The structure now (thanks
to Marshall) should also conform to the rest of the SVN structure.
So, what I plan to do is as follows:
1) move xdoclet, the old web services, aop, and defunct test cases
into legacy immediately (done)
2) refactor / remove the ejb3 plugin. As per Marshall's reply
yesterday, his old classpath containers will be restored so that a user
can add ejb3 jars to any project that they want.
3) combine the J2EE API / source libraries (J2EE 1.3, 1.4 libraries),
with the ejb3 classpath container, into one plugin, tentatively to be
placed under the AS Tools module in a plugin dedicated to housing
classpath containers of these types. (EJB3 source API will also be added)
4) move to legacy any jdt.* plugins who's APIs are not being used by
others.
5) move to legacy org.jboss.ide.eclipse.product
6) continue with the goal of consolidating similar code into fewer
plugins and excising old outdated code.
Eventually, I may look to see what in XDoclet is broken and remedy it. I
realize it's an old technology and not to be encouraged anymore,
however, if it turns out, as I suspect, that the breakage right now is
minimal, I'll patch it up but it will remain in legacy.
I personally would like to see two levels of legacy modules, one which
is essentially a garbage pail, and the other being a lost-and-found /
abandoned one. For example, old web services would go to the trash heap,
but xdoclet would go to abandoned. Your input is most welcome on this,
but there's plenty of time to decide on that. That isn't a rush situation.
Either way, my goal here is to consolidate the good, trim away the bad,
and take ownership of these areas.
Of these changes, the only one I'm going to try to sneak in before this
week's release is the ejb3 change, for several reasons. First, I think
having two ejb3 project types will confuse the user. Second, any user
who does use our ejb3 project type will see it snatched out from under
him by next month's release, and he'll have to re-import all of his code
from source, which could become a royal pain.
All other changes will be executed on a branch of the core module to
refrain from build-breaking, because otherwise I'd have to anticipate an
angwy smiley wiking and all the loud hagar-ish noises that come with it ;)
- Rob Stryker
17 years, 4 months
WTP-server actions
by Rob Stryker
Hi All:
I noticed today another toolbar in the jboss tools which seems to mimic
the action set I already have there. Should I be removing my action set
for this new toolbar? As of now it looks kinda silly having two J icons
right next to each other., one with a pulldown allowing you only to
select a server (using the toolbar actions next to it to
start/stop/debug etc), the other having a pulldown allowing you to set
the server and start / stop / debug it as well.
Just thought I'd point this out.
- Rob
17 years, 5 months
throw/catch Exception is evil
by Max Rydahl Andersen
Hi,
Just being trying to hunt down some issues I bumped into within the seam
builder and views and I spent a looong time figuring out what was going on.
And eventually it boiled down to the over usage of just doing throw and
catch Exception instead of actually trying to only handle the exceptions
the code actually can handle.
So *please* stop doing things like
try {
sp.store();
} catch (Exception e) {
SeamCorePlugin.getPluginLog().logError("Error storing build results
for " + sp.getProject().getName());
}
that code should be:
try {
sp.store();
} catch (IOException e) {
SeamCorePlugin.getPluginLog().logError("Error storing build results for
" + sp.getProject().getName(), e);
}
So what's the difference:
Catching Exception also catches RuntimeExceptions like
NullPointerException meaning it swallows bugs! QA has zero change of
catching such bugs if we hide it from them (plus all the exception
handling code becomes useless when just using Exception).
Thus I changed the store() operation to only throw what it actually
throws (IOException) plus actually logging the exception to be able to
figure out why the IOException occurred.
Thanks ;)
/max
17 years, 5 months
Re: [jbosstools-dev] Seam features
by Max Rydahl Andersen
igels(a)exadel.com wrote:
> No, we just use wtp validation framework for easier way to run validator
> and manage error markers.
> We can implement such features ourself but it needs time.
> We chose wst validation famework because we knew that our Seam Project
> requires WTP JSF facet in first version of Seam tools. And it let us to
> save time.
> As I understood we don't need to support simple Java project in first
> version of seam tools.
well we should not add things that prevent us from doing so ;)
AFAIK wst validations can actually run on any kind of project - it is
just up to the validator to state what natures it requires.
/max
>
>
>> igels(a)exadel.com wrote:
>>> Seam validation based on WST framework. It means that the project should
>>> be WTP Project. So you have to create it via our New Seam Project
>>> Wizard.
>>> So if you just add seam nature and builder to .project it's not enough.
>> ah bummer ;(
>>
>> does that stuff really require a full dynamic web project to work ?
>> (makes it hard for us to support seamgen'ed or just simple java projects
>> with seam components in them)
>>
>> /max
>>
>>>
>>>> btw. any idea on how I get the seam validations to bug me ?
>>>>
>>>> currently I can't seem to make it run...
>>>>
>>>> what are the magic steps to enable it ? :)
>>>>
>>>> /max
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I've added a "Add/Remove Seam support" to the jbosstools project
>>>>> (JBIDE-581) so humans can try out the new seam features - we will need
>>>>> to have something similar in the final product, but just not in the
>>>>> default right click menu (JBIDE-582)
>>>>>
>>>>> Just wanted to say that I like the seam view and completion features
>>>>> we
>>>>> already have in there. Still alot of polishing to be done, but good
>>>>> stuff! Great work guys.
>>>>>
>>>>> /max
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>> jbosstools-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>
>>
>
17 years, 5 months
Re: [jbosstools-dev] Seam features
by Max Rydahl Andersen
igels(a)exadel.com wrote:
> Seam validation based on WST framework. It means that the project should
> be WTP Project. So you have to create it via our New Seam Project Wizard.
> So if you just add seam nature and builder to .project it's not enough.
ah bummer ;(
does that stuff really require a full dynamic web project to work ?
(makes it hard for us to support seamgen'ed or just simple java projects
with seam components in them)
/max
>
>
>> btw. any idea on how I get the seam validations to bug me ?
>>
>> currently I can't seem to make it run...
>>
>> what are the magic steps to enable it ? :)
>>
>> /max
>>
>>> Hi guys,
>>>
>>> I've added a "Add/Remove Seam support" to the jbosstools project
>>> (JBIDE-581) so humans can try out the new seam features - we will need
>>> to have something similar in the final product, but just not in the
>>> default right click menu (JBIDE-582)
>>>
>>> Just wanted to say that I like the seam view and completion features we
>>> already have in there. Still alot of polishing to be done, but good
>>> stuff! Great work guys.
>>>
>>> /max
>>>
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
17 years, 5 months
Seam features
by Max Rydahl Andersen
Hi guys,
I've added a "Add/Remove Seam support" to the jbosstools project
(JBIDE-581) so humans can try out the new seam features - we will need
to have something similar in the final product, but just not in the
default right click menu (JBIDE-582)
Just wanted to say that I like the seam view and completion features we
already have in there. Still alot of polishing to be done, but good
stuff! Great work guys.
/max
17 years, 5 months
Re: [jbosstools-dev] JSF 1.1.0.1 Reference Impl vs JSF 1.2
by Gurkan Erdogdu
In WTP JSF project, you can create JSF library with wizard, then add jsf-runtime you wish and use it. But it also provides
default runtime, while creating the Dynamic Web Project with JSF facet.
Maybe exadel could do this;
Gurkan
----- Original Message ----
From: Max Rydahl Andersen <max.andersen(a)redhat.com>
To: Igor Shabalov <ishabalov(a)exadel.com>
Cc: jbosstools-dev(a)lists.jboss.org
Sent: Monday, July 16, 2007 1:21:24 PM
Subject: Re: [jbosstools-dev] JSF 1.1.0.1 Reference Impl vs JSF 1.2
Igor Shabalov wrote:
> 4.2.0 have JSF 1.2 under the hood by default. It is not expected to be compatible with any JSF 1.1 templates.
>
> We need some way to prevent deploying incompatible projects. I'd love to throw JSF 1.1 away completely, but I suspect
> that users of 4.0.5 will not appreciate such radical solution.
> Any ideas?
Isn't that was project facets are for in WTP ?
There the runtime tells you what it can actually support.
/max
>
> -----Original Message-----
> From: jbosstools-dev-bounces(a)lists.jboss.org [mailto:jbosstools-dev-bounces@lists.jboss.org] On Behalf Of Marshall
> Culpepper
> Sent: Thursday, July 12, 2007 3:22 PM
> To: jbosstools-dev(a)lists.jboss.org
> Subject: [jbosstools-dev] JSF 1.1.0.1 Reference Impl vs JSF 1.2
>
> Hey guys..
>
> I've been running through a demo I'm going to give tonight at a local
> JBoss User Group meeting, and I noticed some strange behavior with our
> JBoss 4.2.0.GA and using the "JSF 1.1.0.1 Reference Impl" configuration
> from the new JSF project wizard.
>
> Basically, whenever the jsf project is deployed to my clean copy of
> JBoss 4.2.0 , lots of exceptions show up (though the application itself
> seems to work fine). When I start changing things from their default
> configuration (I'm using the kickstart as a quick startup for the demo),
> JBoss consistently throws exceptions until I hard undeploy/deploy the
> app from the App Server.
>
> On the other hand, if I select a "JSF 1.2" configuration in the wizard,
> the project deploys/redeploys with no errors, and seems to work without
> a hitch with any changes I make. I guess what I'm getting at is -- if
> we're going to use JSF 1.1.0.1 Reference Implementation as the "default"
> selection in the new JSF project wizard, shouldn't we be testing it's
> "noiseyness factor"?. Would it be a problem to have JSF 1.2 selected as
> default (or maybe another configuration that JBoss 4.2.0.GA likes?)
>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
____________________________________________________________________________________
Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
17 years, 5 months
ISeamProject and seam nature seperation ?
by Max Rydahl Andersen
Hi guys,
wouldn't it make more sense if ISeamProject doesn't implement the nature
aspect ? isn't that what most other natures do ? separates the project
aspect from the nature ?
/max
17 years, 5 months
JSF 1.1.0.1 Reference Impl vs JSF 1.2
by Marshall Culpepper
Hey guys..
I've been running through a demo I'm going to give tonight at a local
JBoss User Group meeting, and I noticed some strange behavior with our
JBoss 4.2.0.GA and using the "JSF 1.1.0.1 Reference Impl" configuration
from the new JSF project wizard.
Basically, whenever the jsf project is deployed to my clean copy of
JBoss 4.2.0 , lots of exceptions show up (though the application itself
seems to work fine). When I start changing things from their default
configuration (I'm using the kickstart as a quick startup for the demo),
JBoss consistently throws exceptions until I hard undeploy/deploy the
app from the App Server.
On the other hand, if I select a "JSF 1.2" configuration in the wizard,
the project deploys/redeploys with no errors, and seems to work without
a hitch with any changes I make. I guess what I'm getting at is -- if
we're going to use JSF 1.1.0.1 Reference Implementation as the "default"
selection in the new JSF project wizard, shouldn't we be testing it's
"noiseyness factor"?. Would it be a problem to have JSF 1.2 selected as
default (or maybe another configuration that JBoss 4.2.0.GA likes?)
--
Marshall Culpepper
Redhat Dev Studio, JBoss Tools
-
http://jboss.org/tools
email: marshall(a)jboss.org
skype: marshall.culpepper
17 years, 5 months