Re: [jbosstools-dev] jira rights
by Dmitry Geraskov
Hi, Rodney,
I found the proof of the issue.
See https://jira.jboss.org/jira/browse/JBIDE-3712.
I updated there a few times file patch.rar.
So, helpdesk have to give back our rights! ;)
Rodney Russ wrote:
> Hmmmm, when I look at the Jira:
>
> https://jira.jboss.org/jira/browse/JBIDE-4527
>
> and click on the Manage Attachments link, I don't see any way to delete an attachment either. I'm not sure what the "delete" interface looked like. Should this be forwarded to the helpdesk?
>
> -Rodney
>
> ----- "Dmitry Geraskov" <dgeraskov(a)exadel.com> wrote:
>
>
>> https://jira.jboss.org/jira/secure/ManageAttachments.jspa?id=12388792
>>
>> I want to delete older id_detail.png.
>>
>>
>> Max Rydahl Andersen wrote:
>>
>>> delete old attachment of what ? Got a jira issue so I can look ? :)
>>>
>>> /max
>>>
>>> Dmitry Geraskov wrote:
>>>
>>>> There is a problem. I can't delete old attachment.
>>>>
>>>> Max Rydahl Andersen wrote:
>>>>
>>>>> Okey - so there are no problems ?
>>>>>
>>>>> Dmitry Geraskov wrote:
>>>>>
>>>>>> Not in svn, but in jira. I was mistaken.
>>>>>>
>>>>>> Max Rydahl Andersen wrote:
>>>>>>
>>>>>>> delete what file ? Nothing were attached - and even if it were I
>>>>>>>
>>>>>>> would still need to know its location to answer ;)
>>>>>>>
>>>>>>> /max
>>>>>>>
>>>>>>> Dmitry Geraskov wrote:
>>>>>>>
>>>>>>>> I can't delete attached file in svn.
>>>>>>>> As I remember I had the rights before.
>>>>>>>>
>> --
>> Best regards,
>>
>> Dmitry Geraskov
>> dgeraskov(a)exadel.com
>> Senior Developer
>> Exadel Inc
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
--
Best regards,
Dmitry Geraskov
dgeraskov(a)exadel.com
Senior Developer
Exadel Inc
14 years, 7 months
Current WTP-style project offerings
by Rob Stryker
Here's a good summary of what's made already for the WTP projects. I
believe the ESB project already makes use of it. The BPEL project does
*not* and since I am not familiar with the BPEL project code, or all
that goes into creating a new project wizard for WTP projects (never did
work on that part), I'd need someone else (Denny?) to set up the UI and
associated pages and installation delegates to properly change the BPEL
project's format. I can assist on which references would be needed in
the installation delegate, but I'm not familiar with the rest of it.
I sincerely doubt I've replicated all possible types of reference
containers already. So far I have two, output containers for a project,
and class folders on your build path which also contain a custom WTP
attribute flag. These were both primary use cases in WTP. I would love
for people to test to see what other differences there are or which
reference types could be missing (any functionality possible in WTP and
not in our ESB project for example).
I do know that one thing I do not have support for yet is the use case
that's currently custom to Web project's interactions when bundled
inside an EAR, which is to push up the Web project's libraries to live
inside the parent module rather than inside the web project. I haven't
added this functionality yet because I've not heard whether similar
functionality is required for ESB projects or other module-types which
can serve as parents to nested wars (or others). If this turns out to
be an important use case I can try to address it, but for now if ESB
doesn't require this functionality than it's not necessary I don't believe.
http://www.jboss.org/community/wiki/JBossToolsWTPProjectStructures
14 years, 9 months
New WTP Drivers
by Rob Stryker
WTP released 3.1.1 a short while ago. Should we switch to this?
I vote yes.
14 years, 10 months
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
14 years, 10 months
64 bit XULRunner
by Michael Laccetti
I'm running the 64-bit Eclipse on Windows 7 and am interested in getting the 64-bit XULRunner up and running so that the HTML editor has the preview mode enabled. How can I help to get this done?
Michael
14 years, 10 months
Is org.jboss.tools.hibernate.hblibs plug-in still relevant?
by Denis Golovin
It looks like there are no references to
org.jboss.tools.hibernate.hblibs plug-in.
It takes 22 megabyte of disk space.
Do we have to keep it for some reason?
I tried to remove it, but I cannot because several files are locked by
Vitaly. Is that on purpose or?
If you still need it could it just be moved to workspace? Or just remove
it if you do not need it.
Thanks
Denis
14 years, 10 months
[Fwd: Strategy regarding Module Factories, Virtual Components, and future project structure]
by Max Rydahl Andersen
Here is a mail outlining the module factory changes we are looking at in
JBoss Tools (written by rob):
So after connecting with Max at JBossWorld and demonstrating some of the
code and APIs that are available to us, we've got a strategy for what
our projects should look like, and how this should *not* hurt our
long-term strategy of keeping the projects easy to use, configurable in
one place, and overall clean and solid for everyone.
We *will* be making as many of our projects as possible be "Webtools"
projects. The key thing that makes this possible without complicating
everything is the new reference resolver API which I'm trying to get
into WTP, but which we have a version of right now.
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=282269)
The interesting thing is the component.xml, which links project types
together, has a "dependency" tag, which means you can say the ear should
have the war inside it. This is well and good, but the dependency tag
has *two* dependency TYPES. The first is "uses", and that's where it
would end up something like some.ear/inner.war/all/the/files. However
the second type is "consumes" and what consumes does is basically
pretend anything inside this second project (or component, which is not
limited to projects) would be injected directly into the ear as if it
was part of that project. Basically, what this does is just ignore the
inner component's name, and what you'd get is something like
some.ear/all/the/files.
Now, why this is absolutely awesome is that with the API addition that's
coming, we can create references based on whatever we want, whenever we
want. There have been many many longstanding bugs in WTP from people who
want to embed a java project, but do *not* want that java project to be
forced to become a WTP project. Using the new add-reference wizard, we
have the ability to make *anything* consumable; anything that we want.
Plain java projects, anything.
I don't have all the code committed yet, but today I played around a
*lot* with the possibilities and with a few classes, I managed to add
this to an ESB project's component.xml using the standard wizard which
will be in WTP:
<dependent-module deploy-path="/"
handle="module:/org.jboss.ide.eclipse.as.wtp.core.vcf.outputFolder/ESBPro">
<dependency-type>consumes</dependency-type>
</dependent-module>
The key part to look at is the handle, which I get to resolve. I take
that handle and add turn that into a Virtual Component of my own, one
which returns *only* the resolved and mapped resources inside the ESBPro
project. I could also make one to return an IVirtualComponent based on a
plain old java project if we wanted... or a classpath container, or
*all* exported classpath containers, or whatever I want. This clearly
opens many doors for the user, and it means that this new flexible
structure should definitely be our direction.
Most of the code is already committed but if you use it today or
tomorrow you'll notice it doesn't "finish" by actually publishing the
source.
That's because I spent a lot of the time working on the infrastructure
and still need to make a few utility classes to help with the last part.
But the way is made clear and this is pretty solidly awesome. I'm not
sure if I'm being linguistically adept enough right now, so if there are
any questions feel free to ask.
14 years, 10 months
Extensibility of the JBT Project Examples code
by Brian Fitzpatrick
Hi all...
I've been looking at reusing the Project Examples wizard that's available as part of JBT/JBDS and am wondering how we might be able to extend it to allow users to actually modify a sample project and use it as a template rather than just as-is.
Though this would require some additional extension points and coding, I'm wondering if we could associate extra wizard pages with a particular example to allow customization.
For example, I want to be able to take the webservice_proxy_basic example and offer the user the opportunity to change the WSDL that would be proxied and possibly at least template any required input/output transformation actions.
This diverges from the current paradigm though of taking a zip file that has an entire project in it and simply importing it into the workspace, then tweaking for any issues that arise that are related to environment-specific configuration.
Though I understand why we've gone with the import method, I'd rather try to provide the user with something that offers a bit more flexibility.
I suspect that my approach would require a separate wizard and extension framework for project templates with associated wizard pages. But this would require the coding for each project we wished to create in this way and not allow reuse of the existing quickstarts or the zipped up projects of the Project Examples approach.
Can anyone else see the utility of a new approach here or am I just trying to reinvent the wheel?
--Fitz
_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat
14 years, 10 months
"Hibernate Configuration 3.0 XML Editor"
by Vitali Yemialyanchyk
Hi,
I want to start discussion of "Hibernate Configuration 3.0 XML Editor".
This rather strange editor is situated in
trunk\hibernatetools\plugins\org.jboss.tools.hibernate.xml
trunk\hibernatetools\plugins\org.jboss.tools.hibernate.xml.ui
I call it strange cause it in hibernatetools in svn repository, but really
this is Jboss Tools thing and it was nether in Hibernate Tools.
Some users has questions about this and create such bugs in jira:
https://jira.jboss.org/jira/browse/JBIDE-4802
For them and for me (if I think about myself as Hibernate Tools user, not a
developer) it is difficult to explain, why I should take a lot of things
from JBoss Tools if I just want to use separate Hibernate Tools. As a
developer I see advantages of common things.
To make it more useful I create JIRA issue far time ago:
https://jira.jboss.org/jira/browse/JBIDE-2607
there are no changes since that time.
I want to enhance this editor to make it more useful and I want to integrate
it into Hibernate Tools.
For this it is necessary to separate org.jboss.tools.hibernate.xml and
org.jboss.tools.hibernate.xml.ui, make it detached from XModel.
So I want to hear some arguments pro/contra this solution and/or may be some
advises howto possible make this changes in better manner.
Vitali
14 years, 10 months
