Feedback on 2.1.CR1
by Galder Zamarreno
Hi guys,
I've been playing around with tools 2.1.CR1 and specially the
build/publish area. I wanted to make a few comments on this:
1.- Is there a way to do a Build Archive (Full) and Publish in just one
click?
2.- I get no feedback when I do "Build Archive (Full)". IOW, did
anything change? Or didn't it build anything cos nothing had changed?
Maybe I forgot to rebuild? I get no type of feedback.
3.- If I do a publish on an archive that hasn't changed (maybe cos I
forgot to rebuild the archive and hence the build archive did nothing,
but don't know at this stage), the event log says:
-> Publishing [1 modules, 0 files changed]
-> [Full, no change] .jar
This is very misleading cos in fact it didn't do anything even though
the even says "Publishing...". It didn't deploy the jar cos it hasn't
changed. Also, what does "0 files changed" mean?
If the archive had actually changed and the publish has really occurred,
you get:
-> Publishing [1 modules, 0 files changed]
-> [Full, Changed] .jar
I have to extend the event to actually realise that the jar changed was
actually published, even thought the title of the even still says "0
files changed".
Bottom line, the event log needs to be clearer in what happened without
having to do too many clicks. Besides, each publish cannot be
distinguished, maybe it's worth adding a timestamp or something to each
publish event?
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
15 years, 11 months
IMPORTANT! Merged docs for 2.1.x branch and trunk
by Max Rydahl Andersen
Hi,
I were about to merge down the updates I did to the docs for using the released jdocbook and other misc updates I did and saw
that the recent updates for documentation were done in trunk and not in the 2.1.x branch - meaning it will not go out with the GA release.
I have now merged branch and trunk so they should be in sync at this moment in time.
Please be *carefull* about where you are comitting things and if things needs to be in both branches then remember to commit to them both
and *please* use something like svnmerge.py so you can keep track of what have been merged and what have been blocked etc.
See http://www.orcaware.com/svn/wiki/Svnmerge.py#Release_branches for info.
Please take the time to learn to use that if you are working on multiple branches - thanks!
Thank you,
/max
15 years, 11 months
Re: Richfaces 3.2 ?
by Max Rydahl Andersen
> RichFaces 3.2.1 is expected at the middle of May.
cool - any chance you could let us know when you have a build with the updated TLD's
so we could start integrating ASAP ?
/max
> ----- Original Message -----
> From: "Max Rydahl Andersen" <max.andersen(a)redhat.com>
> To: "Sergey Smirnov" <sim(a)exadel.com>; "Alexey Kazakov"
> <akazakov(a)exadel.com>
> Cc: <jbosstools-dev(a)lists.jboss.org>; "Sergey Vasilyev"
> <svasilyev(a)exadel.com>; "Nikolay Belaevski" <nbelaevski(a)exadel.com>;
> "Alexander Smirnov" <asmirnov(a)exadel.com>
> Sent: Wednesday, May 07, 2008 1:11 PM
> Subject: Re: Richfaces 3.2 ?
>
>
>>> We have never been change this number inside tld. It was 1.2 from the
>>> very
>>> first version. Mainly, because it does not make any since for run-time.
>>
>> Any tools and introspection tool would like to have it ;)
>>
>>> We
>>> store the true version in the manifest.mf located close to tlds files
>>> inside
>>> the META-INF instead.
>>> Actually, the standard limits the content of this tag. It must only
>>> numbers
>>> divided by up to 3 dots. So, we cannot put the exact version there like
>>> 3.2.0.GA or 3.2.0.SP1
>>
>> Just having the 3.2.0 would be sufficient for us since what comes after
>> the 4th dot should
>> be irelevant.
>>
>>> So, starting with RichFaces 3.2.1, we will turn CDK generator to generate
>>> three number divided by dots. It is not ideal, but close to.
>>
>> Its way better ;)
>>
>> When is 3.2.1 expected ?
>>
>>> In general, we can enhance CDK to generate not only TLD, but the
>>> meta-data
>>> for code extended assist. In this way, JBDS just needs to take this
>>> meta-file from the jar file instead of the place it takes now. It will
>>> help
>>> to migrate from version to version more smoothly and without extra work
>>> from
>>> the JBDS team.
>>
>> sounds like something we should investigate and do it in a way other lib's
>> could use too.
>>
>> Kazakov - comments ?
>>
>> /max
>>
>>>
>>> I told with Alexey about this feature, but looks like this topic was just
>>> forgotten between the other more actual themes on that moment.
>>>
>>> ----- Original Message -----
>>> From: "Max Rydahl Andersen" <max.andersen(a)redhat.com>
>>> To: "Alexey Kazakov" <akazakov(a)exadel.com>
>>> Cc: <jbosstools-dev(a)lists.jboss.org>; "Sergey Vasilyev"
>>> <svasilyev(a)exadel.com>; "Sergey Smirnov" <sim(a)exadel.com>
>>> Sent: Wednesday, May 07, 2008 10:25 AM
>>> Subject: Re: Richfaces 3.2 ?
>>>
>>>
>>>>>> How long time would it take to add code completion support for RF 3.2
>>>>>> ?
>>>>>>
>>>>> If we want to have RF 3.1.x by default (if we can't recognize the
>>>>> version of lib) then there will be a problem.
>>>>
>>>> But isn't the schemas distinct enough to always recognize the correct
>>>> version ?
>>>>
>>>> Note: if we can't recognize the version i'm probably fine by falling
>>>> back
>>>> to 3.2 by default.
>>>> btw. why is hard to set a specific version as the default ? Is it
>>>> hardcoded to take the latest version as default or ?
>>>>
>>>>> Richaces TLD version tag has not been updated since 1.2.
>>>>> So we are not able to tell one from the other.
>>>>
>>>> Are you telling me the richfaces team does not update their TLD's ?
>>>> I thought the CDK where supposed to make that "easy" ?
>>>>
>>>> I've cc'ed in Sergey S. to get his opinion on how we should go about
>>>> supporting
>>>> updates to richfaces if the libraries does not maintain their schema
>>>> version id's..?
>>>>
>>>>> It would take about one day to provide code completion for RF 3.2 but
>>>>> only default lib will work.
>>>>
>>>> ?
>>>>
>>>> /max
>>>
>>>
>>
>>
>>
>
>
15 years, 11 months
Re: Richfaces 3.2 ?
by Max Rydahl Andersen
> We have never been change this number inside tld. It was 1.2 from the very
> first version. Mainly, because it does not make any since for run-time.
Any tools and introspection tool would like to have it ;)
> We
> store the true version in the manifest.mf located close to tlds files inside
> the META-INF instead.
> Actually, the standard limits the content of this tag. It must only numbers
> divided by up to 3 dots. So, we cannot put the exact version there like
> 3.2.0.GA or 3.2.0.SP1
Just having the 3.2.0 would be sufficient for us since what comes after the 4th dot should
be irelevant.
> So, starting with RichFaces 3.2.1, we will turn CDK generator to generate
> three number divided by dots. It is not ideal, but close to.
Its way better ;)
When is 3.2.1 expected ?
> In general, we can enhance CDK to generate not only TLD, but the meta-data
> for code extended assist. In this way, JBDS just needs to take this
> meta-file from the jar file instead of the place it takes now. It will help
> to migrate from version to version more smoothly and without extra work from
> the JBDS team.
sounds like something we should investigate and do it in a way other lib's could use too.
Kazakov - comments ?
/max
>
> I told with Alexey about this feature, but looks like this topic was just
> forgotten between the other more actual themes on that moment.
>
> ----- Original Message -----
> From: "Max Rydahl Andersen" <max.andersen(a)redhat.com>
> To: "Alexey Kazakov" <akazakov(a)exadel.com>
> Cc: <jbosstools-dev(a)lists.jboss.org>; "Sergey Vasilyev"
> <svasilyev(a)exadel.com>; "Sergey Smirnov" <sim(a)exadel.com>
> Sent: Wednesday, May 07, 2008 10:25 AM
> Subject: Re: Richfaces 3.2 ?
>
>
>>>> How long time would it take to add code completion support for RF 3.2 ?
>>>>
>>> If we want to have RF 3.1.x by default (if we can't recognize the
>>> version of lib) then there will be a problem.
>>
>> But isn't the schemas distinct enough to always recognize the correct
>> version ?
>>
>> Note: if we can't recognize the version i'm probably fine by falling back
>> to 3.2 by default.
>> btw. why is hard to set a specific version as the default ? Is it
>> hardcoded to take the latest version as default or ?
>>
>>> Richaces TLD version tag has not been updated since 1.2.
>>> So we are not able to tell one from the other.
>>
>> Are you telling me the richfaces team does not update their TLD's ?
>> I thought the CDK where supposed to make that "easy" ?
>>
>> I've cc'ed in Sergey S. to get his opinion on how we should go about
>> supporting
>> updates to richfaces if the libraries does not maintain their schema
>> version id's..?
>>
>>> It would take about one day to provide code completion for RF 3.2 but
>>> only default lib will work.
>>
>> ?
>>
>> /max
>
>
15 years, 11 months
Richfaces 3.2 ?
by Max Rydahl Andersen
Hi,
RF 3.2 were not released when we specified the goals for JBT 2.1, but it seems there is enough difference between RF 3.1 and RF 3.2 for it to be a pain for users of our code completion and VPE.
We need to be compatible with RF 3.1.x since that is what Seam's uses so keep that in mind when trying to answer the following ;)
How long time would it take to add code completion support for RF 3.2 ?
How long time would it take to add in any major missing RF 3.2 components ?
/max
15 years, 11 months
Fwd: [JBoss JIRA] Commented: (JBQA-1585) Install compat-libstdc++-33 on RHEL x86 nodes in hudson
by Max Rydahl Andersen
Denis/Marshall - is everything ok on the build side now ?
-max
------- Forwarded message -------
From: "Prabhat Jha (JIRA)" <jira-events(a)lists.jboss.org>
To: max.andersen(a)redhat.com
Cc:
Subject: [JBoss JIRA] Commented: (JBQA-1585) Install compat-libstdc++-33 on RHEL x86 nodes in hudson
Date: Tue, 06 May 2008 17:13:20 +0200
[ http://jira.jboss.com/jira/browse/JBQA-1585?page=comments#action_12411885 ]
Prabhat Jha commented on JBQA-1585:
-----------------------------------
Marshall, how are builds looking? Did you see any error because of missing lib?
> Install compat-libstdc++-33 on RHEL x86 nodes in hudson
> -------------------------------------------------------
>
> Key: JBQA-1585
> URL: http://jira.jboss.com/jira/browse/JBQA-1585
> Project: JBoss QA
> Issue Type: Task
> Components: JBoss IDE
> Reporter: Marshall Culpepper
> Assigned To: Prabhat Jha
>
> We need to verify that all the RHEL x86 nodes have the following yum package installed:
> compat-libstdc++-33
> So that our visual designer unit tests etc work reliably on all nodes in the hudson configuration..
15 years, 11 months
CR1 is out
by Max Rydahl Andersen
See the details at http://in.relation.to/Bloggers/JBossTools210CR1Released
Thanks everyone for making this happen!
GA should now only be very minor fixes in the 2.1.x branch and we should now start talking about
next version and how Ganymede fits into this....I feel a JBoss Tools 3 coming up ;)
/max
15 years, 11 months
Build Status
by Rob Stryker
Ok... so...
A full JBDS build was created. It worked about 50% of the time. I know
this sounds horrible, but, it did ;) The times it did *not* work was
because of a ClassCastException in eclipse in the very same class that's
been our problem the entire time.
I've come to the conclusion that their entire JEEDeployableFactory is
crap, a conclusion validated by the fact that theyv'e changed it
entirely in 3.0.
Either way, I added in further exception checks. I am confident that
this is the only thing standing in our way. A new build is being started
right now. It should be finished in an hour or three... and when it is,
it would be excellent if it could be tested extensively!
Good luck, and I'll be back online in 6 hours or so!
- Rob Stryker
15 years, 11 months
