classpath containers
by Max Rydahl Andersen
Just saw https://jira.jboss.org/jira/browse/JBIDE-3836 which shows how
bad it is that we now have the classpath containers duplicated.
That issue I see as being just as relevant for WS, AS and ESB....not
something that should just be fixed in the ESB classpath container.
Could we please move the base set of functionality (source/java doc
attachement and basic CPC func) back into AS core and all base
on that at least for GA ?
/max
17 years
For the Record
by Rob Stryker
max:
For the record, you already cannot download standalone AS Tools without
errors.
It requires Archives and JMX.
17 years
3.0.0.GA Code freeze reminder
by Max Rydahl Andersen
Hi,
Just to remind everyone that the codefreeze for JBoss Tools trunk is
Friday 27th.
*All* bugs should be fixed by then. Only critical/showstopper's will be
fixed after 27th.
The release GA build is scheduled to be March the 11th so we can have
everything ready
for EclipseCon.
Thanks,
/max
17 years
[Fwd: [eclipse-dev] Planning Meeting Notes - Feb 25, 2009]
by Max Rydahl Andersen
See first item - Anyone wants to work on forms ? :)
-------- Original Message --------
Subject: [eclipse-dev] Planning Meeting Notes - Feb 25, 2009
Date: Wed, 25 Feb 2009 10:28:49 -0500
From: Mike Wilson <Mike_Wilson(a)ca.ibm.com>
Reply-To: General development mailing list of the Eclipse project.
<eclipse-dev(a)eclipse.org>
To: eclipse-dev(a)eclipse.org
-------------------
Discussion Topics
-------------------
User Assistance:
- org.eclipse.ui.forms is approaching a point where it has no committers
with time to work on it. Can we find someone to work on this component?
If not what is our fallback plan?
--------
Status
--------
JDT UI:
- various fixes in Runnable Jar Exporter
- enabled Rename refactoring quick assist in Java compare editors
- Inline Local Variable and Inline Constant refactorings now insert
necessary explicit casts if there was an implicit conversion that
widened the initializer's type to the variable's type
- bug fixing
- inbox tracking
Platform Text and JDT Text:
- continued work on 'Open Implementation' hyperlink detector
- continued work on adding 'Show in Properties File' action to
NLS key hover
- adopted range differencer API from Compare and got rid of our
own implementation
- bug fixing
- inbox tracking
Platform Search:
- inbox tracking
Debug:
- new extension point to contribute Java breakpoint listeners (bug 260910)
- continued work on EclipseCon tutorial
- bug fixing
PDE:
- continued enhancements to new Target Platform preference page:
- removed old preference page from the build
- API tooling:
- baselines now pickup bundles from dropins folder
- enhanced analysis of split bundles
- cleaned up unreliable performance tests
- investigating performance improvements for incremental build
- DS 1.1 support completed
- work in progress around removing config.ini from launcher/product
definitions in favor of list of properties
- bug fixing
User Assistance:
- working on search index performance but have yet to get much improvement.
- bug fixing
- reviewing bugs in the inbox
Rel. Eng.:
- testing new p2 slicer
- merging metadata etc in preparation for 3.4.2 release this wed.
- testing using comparator to use when mirroring from repos in the build
- bug fixing
Workspace:
- inbox tracking
- working on 3.5 M6:
- http://www.eclipse.org/eclipse/platform-team/team3.5/plan.php#m6
- fixing regression in the compare editor
- final work on bug 220457, bug 201116 (multiple contentMergeViewers
for the same content type, file extension)
- new API to instantiate and apply arbitrary hunks (bug 183226, bug 265824)
- compare core plug-in changed to 3.5 (was 1.0)
Platform UI:
- 3.5 bug fixing
- We are going to change our bug triage process:
- http://wiki.eclipse.org/Platform_UI/Bug_Triage
17 years
Re: [jbosstools-dev] Use of Console view for server events
by John Graham
> The console just shows the output stream from the AS process.
So, I should see a stream of events on server start/stop? If so, then
that is not working for me.
-- John
On Tue, 2009-02-17 at 18:12 -0500, Max Rydahl Andersen wrote:
> The console just shows the output stream from the AS process.
>
> The Server Event Log should collect the more highlevel events like
> stop, start, deploy, redeploy etc.
>
>
> /max
>
> ----- "John Graham" <jgraham(a)redhat.com> wrote:
>
> > I'm experiencing some strange behavior with the Console view when
> > using
> > the Servers view. I thought the Console view was supposed to show
> > server
> > activity as would be seen by starting/stopping/etc. a server from the
> > command line. The Console view does not register this output for me
> > on
> > server start and, at seemingly random times during development, it
> > will
> > start registering events and work (as I assumed it was going to)
> > after
> > that. Usually, however, it never displays server
> > start/stop/publish/etc.
> > events at all. Nothing in the error log, though once a while ago
> > before
> > I was looking at this issue I noticed some stack traces from the
> > console. Sorry, didn't save those ;(
> >
> > Is the Console supposed to work that way with the Server view and, if
> > so, is it working for others?
> >
> > -- John
> >
> > Environment: FC8, JBDS 2.0CR2, SOA-P 4.3
> >
> > _______________________________________________
> > jbosstools-dev mailing list
> > jbosstools-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
17 years
Rethinking internationalisation approach (LONG)
by Sean Flanigan
Hi everyone,
While waiting for the trunk code freeze to be over (so that I can get
back to externalising strings in the source code), I've been thinking
about the approach. (The plan was to have Gettext .po files kept in a
separate part of the source tree, with Ant tasks to generate .properties
files at build time, to create fragment plugins and an update site, etc
etc.)
(I'm sorry this is so long. You might want to skip down to THE ACTUAL
POINT...)
I've realised there are a number of issues:
1. It turns out there is at least one independent effort to translate
JBoss Tools, an effort which has naturally been using .properties files.
Converting these files into .po files is easy on a one-off basis, but
how should we handle/merge future updates to these translations?
2. Fragment plugins seem to be a rarely-used feature of Eclipse, and
thus a bit of an edge case. There does finally seem to be a way of
getting Eclipse 3.4 to work with fragments (by modifying P2 metadata
after generation), but the whole area is still a bit... iffy.
3. Even though Red Hat translators use Gettext format internally, they
do work on other projects which use .properties files. They just wait
until the relevant project's (eg Mozilla's) string freeze, convert
.properties into .po, do their thing, and convert .po into .properties
and submit to the project CVS/SVN. This means they can't do continous
translation (they have to wait for a string freeze), but they have to
work to a schedule anyway...
4. I have created Ant tasks/scripts which can generate .properties files
and fragment plugins, but smoothly integrating this with (a) Eclipse
development environments and (b) Hudson builds, will still be a lot of
work; work which I can't do without help. (NB: if your translations
only exist in plugin jars, it's quite painful to get a self-hosted
Eclipse to pick them up[1].)
5. My Ant scripts interpret the directory structure of the source code
to work out the owning plugin for each file. This is kind of ugly, but
it seems to be working okay, because the JBT source base is laid out
pretty consistently. But if this ever changes, langpacks will probably
break. This happens to the Babel project whenever it processes a plugin
with a different directory structure. No doubt this will be fixed, but
the point is that it is a fragile approach.
6. Having separate translation fragment plugins implies (a) modifying
the installer to install these plugins, (b) having a separate update
site for translations, (c) and leads to problem with upgrades: a user
might upgrade, say, Hibernate Tools - how do we make sure they update
the translations too?
If I recall correctly, these were the reasons for this approach:
1. We don't want dozens of languages bloating the JBoss Tools install;
we want to keep the size down. But YAGNI. Initially, there will only
be 5 or 6 languages anyway. At present, the English .properties files
(for all of JBoss Tools) take up 355KB compressed. Even if you multiply
that by 100, you only have 35MB. Even if we start adding per-language
images (best avoided), it won't add that much. I think we can ignore
this problem for a long while.
2. Restricting check-in access to the main source tree. I think that
was originally my suggestion; I'm not sure how important that is really,
but I'm sure there are options. I think most open source projects just
trust their translators with committer access.
3. Not wanting to hold up GA waiting for localisation. I'm not sure
about the best way to deal with this. Is it acceptable to say that
JBT/JBDS x.0 is English only, and x.0.1 is localised? Or perhaps you
could distinguish the multilingual version x.0 from the English-only
x.0? But I now think that generating separate langpacks and
corresponding update-site is more overhead than it's worth.
THE ACTUAL POINT
----------------
In short, I have been bludgeoned by reality into changing my mind. I
would now recommend:
1. *Keep translations in .properties form*, right next to the English
files, in the plugin directories *in SVN*. The translations will
automatically be included in the plugin whether at development/debug
time, or when the JBDS installer is generated, or via the main update site.
2. *Do away with the i18n build*. This means we don't have to integrate
i18n with the Hudson build, or with Eclipse, and means we eliminate its
dependencies on (currently) external Maven artifacts like Tennera
Ant-Gettext and JGettext.
I still don't like .properties files, but fighting them is not worth it!
If we go with the flow, it should be possible to release
internationalised versions of JBT/JBDS a lot sooner, since we can leave
out a lot of extra release engineering work.
3. Shortly before (or perhaps immediately after) GA, enact a *string
freeze* on the release branch. Note that this *does not apply* to JBT
3.0.0, since there is still more string externalisation to be done after
GA. (But it would make sense to have a string freeze in the 3.0 branch
after the externalisation work is finished.)
Once the string freeze starts, developers shouldn't change *any* of the
properties files. The Localisation team grabs all the properties files,
converts to their preferred translation format (currently Gettext/PO),
and eventually converts the translated text into properties files again,
checking them in. This will *clobber* the properties files in SVN.
That's why the string freeze is needed. I realise fitting in a string
freeze will be an adjustment, but it's a pretty standard way of making
room for localisation[2] [3].
Eventually, it would be good to point a web translation tool, such as
Flies[4], directly at the source tree, so that no-one will have to look
at .properties files *or* PO files, and I'm hopeful that Flies workflow
support will eventually remove the need for string freezes.
Regards
Sean.
[1] http://www.jboss.org/community/docs/DOC-13256 See "Installing
langpacks the hard way (launching JBT from within Eclipse)"
[2] http://fedoraproject.org/wiki/Releases/10/Schedule#Key_Milestones
[3] http://wiki.eclipse.org/Galileo#Should_Do
[4] https://fedorahosted.org/flies/
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
17 years
Re: [Soa-tools-list] Example of why consistent jar usage is important
by Max Rydahl Andersen
>>
>> The short term solution is to drop the ESB specific classpath
>> container IMO.
>> And let the AS classpath container calculate which jars to return
>> dependent on which facets are installed.
>>
>> That will allow for dynamic calculation - I don't really understand
>> why it wasn't done like this in the beginning.
>> Denny / Rob can you let us know ?
> ESB project has two main functions
> one is creating a ESB project for developing ESB by set up classpath
> and another is deploying ESB project,
> ESB register itself to AS runtime, is just for deploying project using
> WTP deployment way.
>
> Let me explain why there is a ESB specified classpath container:
> Firstly, AS server runtime can not ensure that it can provide a proper
> ESB runtime any time,
> because not all JBoss Servers contain ESB runtime, if a user just want
> set up a development environment by
> a standalone ESB runtime and there is not a ESB specified classpath
> container, how could he do?
Eh - how do you do if there is not an ESB in the runtime ? You would be
in the same situation, right ?
>
> Currently, there are two options for creating ESB classpath container,
> 1. get ESB runtime jars from specified AS runtime
> 2. get jars from a specified ESB runtime which predefined in
> preference page.
> for now, AS classpath container is used as non-facet related
> classpath, I don't think it can pick up jars
> for all project facet, there maybe JBossWS facet, it need JBossWS
> runtime, JBoss ESB facet need
> ESB runtime, and Seam facet Seam runtime, AS classpath container
> almost don't know where the
> location and structure of an new added runtime.
Seam facet is not doable because Seam jar's are not part of the AS
runtime (it is "outside" and needs deploying inside the app),
ESB and WS are all "inside" the AS runtime and AS could calculate these.
btw. I think all of this is more for jbosstools-dev than SOA tools since
it is not soa specific.
> If AS classpath container can provide a extension point for new facet
> and runtime, every new facet
> just need extend the extension point by providing a jars calculation
> logic and AS runtime pick jars
> from extensions. that would be good.
Yes - maybe runtime components can do this ?
/max
>
> Denny
>
>
>>
>> Nor do I understand how users is supposed to know which jars' to
>> compile/run against with the current platform
>> setup we have ;)
>>
>> /max
>>> I've been looking into this during the morning, and so far here is what
>>> I've got:
>>>
>>> This appears to be a case of SOA-P using an AS capability that the
>>> tooling has no easy way to accommodate at present. That is, SOA-P is
>>> able to override certain libraries contained in AS by default for its
>>> own use, and thus applications written for SOA-P (as opposed to just
>>> AS)
>>> need to be configured accordingly. Now, we might wish that the world is
>>> flat, but reality intrudes with much more complex demands. The simple
>>> fact that there are library/classloader scope capabilities in AS that
>>> are not readily supported by the current tools means that other more
>>> complex enterprise applications could run into similar issues.
>>> A potential solution (though not in this release of tools) is to
>>> provide
>>> a Eclipse launch configuration that allows for classpath container
>>> manipulation and perhaps makes some educated guesses ("if ESB and
>>> duplicate jar between ESB and AS, remove AS jar from classpath" for
>>> example) in the default settings. This would enable users to handle a
>>> host of classpath configuration details when developing with AS, not
>>> just for ESB.
>>>
>>> For the short term (this release), I think the only viable option is to
>>> identify the known overlap and work-around it as best as possible. This
>>> might include dropping known problematic jars from the classpath or
>>> simply user documentation.
>>>
>>> -- John
>>>
>>> On Fri, 2009-02-13 at 15:22 +0000, Mark Little wrote:
>>>> Hi Max. I'm not sure why this email is blank (at least I can't use
>>>> it). Anyway, I've asked John to take a look at the problem from our
>>>> side since I'm on vacation next week. I think we all know what we want
>>>> to be able to do with tooling, so let's identify the issues and get
>>>> them fixed. I don't believe this is an insurmountable issue.
>>>>
>>>>
>>>> Mark.
>>>>
>>>>
>>>>
>>>> On 13 Feb 2009, at 14:46, Max Rydahl Andersen wrote:
>>>>
>>>>>
>>>> ----
>>>>
>>>>
>>>> Mark Little
>>>> mlittle(a)redhat.com
>>>>
>>>>
>>>> JBoss, a Division of Red Hat
>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in
>>>> UK and Wales under Company Registration No. 3798903 Directors:
>>>> Michael Cunningham (USA), Charlie Peters (USA), Matt
>>>> Parsons (USA) and Brendan Lane (Ireland)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Soa-tools-list mailing list
>>>> Soa-tools-list(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Soa-tools-list mailing list
>> Soa-tools-list(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>
17 years
