Re: Moving to XulRunner 1.9
by Maksim Areshkau
On Tue, 2009-05-19 at 08:27 -0400, Max Rydahl Andersen wrote:
> > > I don't have the resources to promise that the javaxpcom will
> > work/be
> > > maintained so i guess for now we will just continue to bundle the
> > > eclipse/mozilla custom built one so any security issues is not
> > exposed
> > > in the general browser but only in the development tooling
> > > where it is less of an issue since it is primarily used to access
> > > local sites.
> > >
> > > /max
>
> > What does this mean for question move VPE on xulrunner 1.9 or not?
> > /Maksim Areshkau
>
> That beyo8nd xulrunner 1.9 removing features we depend on we now also
> need someone to maintain the xpcom interfaces...afaik ATF did that before.
Java XPCOM bridge provided by mozilla, what doing ATF gays - just
provided a plugin with this interfaces, if so it's not difficult to do.
> Who does it now ?
>
> /max
Almost all xpcom interfaces that used by us has frozen status and
shouldn't changed, so this doesn't needed to change something.
--
Maksim Areshkau
15 years, 8 months
Cluster Feature Collecting
by Rob Stryker
Hi All:
I'd like to hear any and all clustering use cases relevant to tooling
that any of you have run into. Whether it be creating multiple servers /
runtimes / profiles, actions you'd like supported on a cluster type node
in the view, anything you can imagine. Spit it out. Speak up. Or
forever hold your peace ;)
15 years, 11 months
Moved fix for from M1 to M2
by Max Rydahl Andersen
Hi,
In case you haven't noticed I've moved all 260+ issues that were still
open and not directly required for M1's release to M2.
This is only a shortterm solution since we really need to cut down the
number of issues we have assigned to one release,
i.e. this time we hadd about 260 issues too many.
Please remember that *you* should be keeping jira uptodate for the
components you work on - if you won't fix 200 issues for
the next release then please move it to another future release. You can
see the current tentative dates for the various releases
so you can know what to plan for.
In any case if you are resolving issues before M1 gets build (next week)
pleae remember to set the fix version to M1.
/max
15 years, 11 months
Re: [jbosstools-dev] Re: Status: 25 May 2009
by Max Rydahl Andersen
>>>
>>> Neither I :(
>>>
>>> If you find an answer to this, please let me know!
>>>
>>> Let me cc the jboss tools team in case they know cos they're the
>>> Eclipse gurus :)
>> What maven plugin are you using ?
> I am using m2eclipse (http://m2eclipse.codehaus.org/) and it is
> actually working correctly (my first search was misleading as there
> truly are zero callers to AbstractController.setExecutor()). I am
> using the "import maven projects" option on the "File/Import" menu in
> Eclipse 3.4.2.
Okey - so it is actually working correctly ? ;)
-max
15 years, 11 months
Re: Status: 25 May 2009
by Galder Zamarreno
Scott Marlow wrote:
> Last Week:
> </snip>
>
> * Finish setting up my eclipse workspace for AS
> I can view source for any component but cannot effectively find callers
> to classes that aren't part of jbossas. For example, searching for all
> callers to AbstractController.setExecutor(Executor) return no matches
> (this is currently the case for any class that eclipse loads via the
> maven plugin).
Neither I :(
If you find an answer to this, please let me know!
Let me cc the jboss tools team in case they know cos they're the Eclipse
gurus :)
>
>
> Scott
>
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
15 years, 11 months
Remembering to help improve Eclipse 3.5/Galieleo before it is too late!
by Max Rydahl Andersen
Hi,
Eclipse 3.5/Galileo has now reached their Release Candidate build cycle,
meaning that they are very close to their GA build (26/6/2009 - see more
at http://www.eclipse.org/projects/project-plan.php?projectid=galileo).
I know that some of you have already been reporting bugs against Eclipse
and that is great - but I just want to remind everyone that our projects
are dependent on Eclipse and *any* bug we find whether it is small or big
we should report to bugs.eclipse.org so our projects does not get
affected by it.
We are one of the few teams that are developing against Galileo and thus
part of the few people that will be able to catch these bugs and help
getting them fixed before the GA of Eclipse 3.5.
Remember that if we don't get them fixed now, we might have to wait a
whole year (365+ days!) before issues gets fixed.
Thus, please - Speak up when you find a bug; don't assume someone else will!
Thanks!
/max
15 years, 12 months
Warnings in Eclipse
by Dmitry Geraskov
Hi, folks,
anybody know how to explore warning name in eclipse which can be used
@SuppressWarnings annotation?
Thanks
--
Best regards,
Dmitry Geraskov
dgeraskov(a)exadel.com
Senior Developer
Exadel Inc
16 years
Re-thinking the EE Modules Page
by Rob Stryker
The EE Modules page needs to be improved (IMO). I'm gonna list some of
the problems here with it, and then ask for feedback as to how (or even
if) I should spend time on this patch. I've spent a bit of time today
familiarizing myself with the code.
Some details:
1) Every EAR project has a designated "lib" folder. This is stored in
the application.xml (if one exists) or just defaults to "lib".
2) On a raw xml file level, each child project (utility projects, web
projects) can designate it's deploy directory inside the EAR by using
the "deploy-path" attribute in the components xml file. The current page
doesn't show this.
a) In fact, the current page only has is a checkbox as to whether
it's in the designated lib folder or not... and this checkbox is often wrong
b) And the checkbox uses really weird logic to initialize itself
(ugly code) and there's a delay before it appears, and when it does
appear it appears on the left, and then 2 seconds later moves itself
over to column 3. Really odd.
3) Binary child modules are treated... oddly.
a) If the binary module is in the EarContent folder, it's listed in
the viewer (but cannot be relocated in this prop. page).
b) If the binary module is in the lib folder (EarContent/lib or
whatever application.xml says is right), it's listed in the viewer (but
cannot be relocated in this prop page)
c) If the binary module is... anywhere else in the project, it's not
even listed, even if it should be. I've traced through. It gets filtered
out. Odd.
4) When on this property page, if I select "Add Jar", It lets me browse
the workspace for jars (in any project) that I want to be in this
project (I think? Not sure if it's just for classpath or not)... however
if I select a jar that's already in the ear project, nothing happens.
a) Adding jars from other projects does add a line to the
components xml file, but not quite sure it's behaviour yet (bundle or
just CP entry)
5) Adding an external jar seems to work fine. The only difference
between adding a workspace jar and external jar seems to be absolute or
relative path.
6) You can add classpath variable entries. Still have not yet
investigated how exactly they work.
7) You can change the Library directory in the application xml. Any
reference that has the current lib directory as its deploy path will be
re-assigned the newly-typed value as the new one.
Now, I can clearly use whatever logic they need done on performFinish
and clean up the UI at the same time if I need to. My question is, is
this worth pushing, and considering the breadth of problems, is it
better if I just try to clean up the entire class and send them a new
one for their consideration rather than try to isolate specific
complaints and have to bicker over all of them?
Also:
I believe I know why their UI is so limited. They're trying
specifically to limit the possibilities to that which is supported by
JEE. For example, having all sorts of random utility projects / jars
being deployed to whatever folder you want clearly isn't EE supported,
but I believe it's more humane. WTP wants to reduce this choice to only
a "lib folder" or "root" choice, (or if you place the file directly in
the project, then it lands "wherever you put it").
If I were to recode it and keep all the functionality while actually
making it work, which jars in the project SHOULD show up? Currently it's
only root / lib folder jars. All others are ignored. Should they be
ignored on this page or not? Would a text box work better than a
checkbox? Obviously it'd be more configurable, but perhaps their usecase
of limiting complexity is good?
Thoughts / comments please. thanks.
16 years
