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
16 years, 10 months
Libmanagement issues
by Dmitry Geraskov
Hi, guys,
I find the solution which Dali uses for libmanagement on project
creation step.
They have composite which allows to user to add libraries when he create
project.
The libraries could be managed by eclipse's preferences, or could be
downloaded from the internet.
This is standard feature for faceted projects.
(see
org.eclipse.jst.common.project.facet.core.libprov.LibraryInstallDelegate,
org.eclipse.jst.common.project.facet.ui.libprov.LibraryProviderFrameworkUi)
---
If we want some *specific* libraries to be added (or we want to help to
user) we could do it like dtp helps with jdbc drivers when you creates
new ConnectionProfile.
Is this we are looking for libmanagement?
--
Best regards,
Dmitry Geraskov
dgeraskov(a)exadel.com
Senior Developer
Exadel Inc
17 years
Eclipse 64 and Visual JSF
by Peter Rader
Hi Folks,
the Visual Editor shows:
Could not open the Visual Page Editor: Bundle org.mozilla.xulrunner.win32.win32.x86_64 is not found.
Any suggestions?
regards
peter
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
17 years
How old is ESB project?
by Rob Stryker
I'd like to make changes to an ESB project's structure and I want to see
if everyone here is on the same page.
The reason I'm asking is because conference calls with WTP have brought
up interesting points. The most important one, I feel, is how the
component.xml file looks in these projects. For example, here's a
mapping from a web project:
<wb-resource deploy-path="/WEB-INF/classes" source-path="/src"/>
Clearly this says we're mapping files in /src to /WEB-INF/classes. This
isn't great because it means the module factory, rather than the virtual
component framework, is in charge of mapping the src to the output
folder, and it's very error prone. Obviously it'd make much more sense
if the mapping looked more like this:
<wb-resource deploy-path="/WEB-INF/classes" source-path="/build/classes"/>
This would clearly let the virtual component framework map directly the
output folder to where ti belongs rather than make the deployable figure
it out and map backwards.
Here's an example snippet from an ESB project component xml.
<wb-resource deploy-path="/esbcontent" source-path="/src" />
The first thing to notice here is that this is blatently wrong, as it's
telling the VCF to deploy files in /src to /esbcontent.
If your esb source folder has a file SomeFile.java, it would now be
published as ESB.esb/esbcontent/SomeFile.java, which is obviously not
what we want.
But what I would like to see this changed to is
<wb-resource deploy-path="/" source-path="/build/classes"/>
I want to see if anyone feels one way or the other about this. It would
make our module factories cleaner and less error prone. Thoughts?
17 years
Re: [jbosstools-dev] Libmanagement issues
by Max Rydahl Andersen
> I find the solution which Dali uses for libmanagement on project
> creation step.
> They have composite which allows to user to add libraries when he
> create project.
JSF has it to, it is what Snjezana uses for some of the Maven
integration we have.
afaik, she enabled that for Seam already. Something we need to see how
we get it applied to as
much as possible elsewhere too.
Just to be precise, we should *not* be using user defined libraries
(UDL) or come up with out own way of getting stuff online though.
UDL's are not sharable and there exist many (better) defacto ways of
getting libraries (i.e. maven, ivy etc.)
What does make sense is that we enable users to use these defacto
methods to decouple the library management from
the IDE and let it be used outside the IDE too. That is why the Maven
integration is so important.
The only place we plan on having IDE specific lib management is for the
classpath container of the server runtime -
that is where "Server provides the runtime" option comes to play. This
is what we should and do use for non-maven projects
and what we use today.
p.s. what is RedHatDevList ? I've added jbosstools-dev too.
/max
>
>
> The libraries could be managed by eclipse's preferences, or could be
> downloaded from the internet.
>
>
>
>
>
> This is standard feature for faceted projects.
> (see
> org.eclipse.jst.common.project.facet.core.libprov.LibraryInstallDelegate,
> org.eclipse.jst.common.project.facet.ui.libprov.LibraryProviderFrameworkUi)
>
> ---
>
> If we want some *specific* libraries to be added (or we want to help
> to user) we could do it like dtp helps with jdbc drivers when you
> creates new ConnectionProfile.
>
>
>
> Is this we are looking for libmanagement?
17 years
Re: [jbosstools-dev] More i18n questions
by Dmitry Geraskov
Dmitry Geraskov wrote:
> Rob Stryker wrote:
>> Dmitry Geraskov wrote:
>>> Rob Stryker wrote:
>>>>>
>>>>>> You should take this into account when you parse code. User could
>>>>>> close comment by unicode representation.
>>>>>> Eclipse colouring doesn't take it into account.
>>>>
>>>> "Should" and "could" are two very different things. lol
>>> Hm... I know... may be *can* instead of *could* is better, but it is
>>> not your comment about.
>>> I didn't understand it.
>>>
>>
>> Sorry. What I meant was, we "can" take a user closing his comment by
>> unicode into account, but I do not think we *should*. It sounds like
>> a lot of work to do just to help someone who decided to close their
>> comment with unicode.
>>
> Agree, while you should not worry about hackers and angry testers :)
I was an angry tester today (no so crazy like in the discussion, but...
;) ) and I found some not obvious validator problems in seam wizards.
Them for example incorrectly validate method name (see New seam action
wizard).
Enter 'method1(){ String h="Hello, from Dima";} method2 ' and validator
will not show an error.
--
Best regards,
Dmitry Geraskov
dgeraskov(a)exadel.com
Senior Developer
Exadel Inc
17 years
Jboss 5.1.0 port 1099 not started
by Ojwang Wilson
All,
Need help in determining why Jboss 5.1.0 GA without errors, but port
1099 is not started on a system running either Fedora core 10 or fedore
core 11. I did a netstat -a and netstat -l before starting jboss and
after starting jboss and the port is not listed.
Regards
Wilson
17 years
Re: Using the JIRA Mylyn connector in Eclipse with the JBoss JIRA repository
by Galder Zamarreno
I've tried using Mylyn/Jira but after successfully putting the login
details and URL, whenever I want to query something, it doesn't go past
the "Updating repository configuration" stage, anyone any idea?
On 07/06/2009 07:48 PM, Alejandro Guizar wrote:
> Works for me as well, with https://jira.jboss.org/jira as the server.
>
> Versions
> Eclipse Platform 3.4.2 M20090211-1700
> Mylyn Task List 3.1.1.v20090411-0400-e3x
> Mylyn Connector: JIRA 3.1.1.v20090411-0400-e3x
>
> HTH,
>
> Alejandro
>
> El lun, 06-07-2009 a las 13:32 -0400, Andrew Lee Rubinger escribió:
>> I use it; works as expected for the most part. Just point a new task
>> repository to:
>>
>> https://jira.jboss.org/jira
>>
>> You'll need to get the JIRA Connector from the Mylyn Extras repo. @see
>> http://confluence.atlassian.com/display/JIRAEXT/Mylyn
>>
>> S,
>> ALR
>>
>> On 07/06/2009 01:21 PM, Brian Fitzpatrick wrote:
>>> Hi all...
>>>
>>> Has anyone attempted to use the JIRA Mylyn connector in Eclipse with the JBoss JIRA repository? It appears (based on some Google searching) that it should work, but am wondering if it's simply the way I have it configured or the current JIRA issues that are causing the problem.
>>>
>>> If anyone could point me at a quick configuration doc somewhere or provide the repository URL for the configuration that would be awesome.
>>>
>>> Thanks in advance
>>> --Fitz
>>>
>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years, 1 month
Cleaning up manifest.mf's
by Max Rydahl Andersen
I have done the first round of
https://jira.jboss.org/jira/browse/JBIDE-3883:
1) Added Bundle-RequiredExecutionEnvironment: J2SE-1.5 to manifest.mf of
plugins that did not have it
2) Use Execution Environment in classpath instead of specific named JDK
This revealed a few things though which we need to fix:
a) usage of com.sun.* classes should removed (hibernate ui/diagram have
this)
b) we should remove .settings whereever possible since with1 and 2 from
above it should no longer be necessary to set project specific compiler
options; and having them overriden per project just creates confusion.
Removing .settings will be my next cleanup - let me know if you know of
a good reason for keeping any .settings files around ?
/max
17 years, 1 month
