Question on xsd catalog entries
by Rob Stryker
Hi All:
So I recently (few months back?) moved all xsd files out into a
standalone plugin for contributing catalog entries. This has overall
proven ok, but there's an issue and I'm not sure how to fix it.
A typical xsd entry in my catalog.xml file looks like this:
<public publicId="urn:jboss:deployment-structure:1.2"
uri="xsd/jboss-deployment-structure-1_2.xsd"/>
The problem is when, in eclipse, you try to make a new xml file, and use
this catalog entry, the generated xml file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<p:jboss-deployment-structure
xmlns:p="urn:jboss:deployment-structure:1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:jboss:deployment-structure:1.2
file:///home/rob/code/jbtools/github/jbosstools-server/as/plugins/org.jboss.tools.as.catalog/schema/xsd/jboss-deployment-structure-1_2.xsd
"></p:jboss-deployment-structure>
The part here that's clearly wrong is:
xsi:schemaLocation="urn:jboss:deployment-structure:1.2
file:///home/rob/code/jbtools/github/jbosstools-server/as/plugins/org.jboss.tools.as.catalog/schema/xsd/jboss-deployment-structure-1_2.xsd
"
This is bad because these files can't really be saved in a shared
repository if it includes full paths to the schema file.
Does anyone know how I should modify my catalog entries so that the
generated xml does not include absolute filesystem urls?
This was realized by Martin in a comment on JBIDE-16358
Any help is greatly appreciated.
- Rob Stryker
9 years, 10 months
Re: [jbosstools-dev] Daily usage
by Alexey Kazakov
Yes, we count events for each workspace separately. But IMO that's is OK.
It maybe not very convenient for testing purposes but not a big deal for
collecting real stats.
I included jbosstools-dev(a)lists.jboss.org to CC.
On 06/12/2014 02:24 AM, Radim Hopp wrote:
> Hi!
> I finally found what I was missing here... That this is workspace specific. I
> often use different workspaces so it was hard for me to spot the reporting GET
> request in error log (because it wasn't there :-D).
>
> I know that typically user works with one (or some small ammount) workspace,
> but he surely has to change that workspace from time to time ("broken"
> workspace is not a nice thing :-D), which results into some data not being
> sent.
>
> I don't know how hard/possible would be to change this... Either to eclipse
> instance specific (but this would suffer from almost (changing eclipse instance)
> the same disatvantage as workspace-specific solution), or to OS user specific.
>
> Maybe I'm beating a dead horse and work required to change this would be too
> high price according to what we can get from it (few data not reported)
> Is it worth it, or should I just go with it? :-D
> Radim
>
> On Wednesday, May 28, 2014 09:37:49 you wrote:
>> Hi Radim,
>>
>> We check if there are some daily events which are ready to be sent at
>> every event type registration (it's recommended to register an event
>> type at plug-in startup) and also every 24 hours in case of long running
>> Eclipse sessions.
>> So it means that if Eclipse is closed earlier then the counted daily
>> events will be sent at the next startup.
>>
>> On 05/28/2014 04:19 AM, Radim Hopp wrote:
>>> Hi Alexey,
>>> I've been looking on new features of usage reporting and one think isn't
>>> completely clear to me. It's those events which are logged once per day.
>>> If i understood it correctly, they are scheduled 24 hours after workbench
>>> startup. What happens if workbench is closed earlier? Does it still send
>>> the data in some shutdown job?
>>> Thanks for explanation.
>>> Radim
9 years, 10 months
Proposed change to target-platforms: Move to Luna RC4 (== future Luna release)
by Mickael Istria
Here is a proposal for a change to the JBoss Tools 4.40.0.Beta4-SNAPSHOT and Central target-platforms:
*https://github.com/jbosstools/jbosstools-target-platforms/pull/75
*https://github.com/jbosstools/jbosstools-discovery/pull/174
It consists in the following changes:
* JBIDE-17603 Move to Luna RC4. Unless a very very very bad issue is noticed in Luna RC4, this Luna RC4 build is what will be promoted as Luna R/SR0.
Please review the above PR(s), as it will be applied in the next days.You can use the following to build & test the TP locally against your component(s).
Build target-platform:
$ cd jbosstools-target-platforms
$ git fetch mickaelistria JBIDE-17603
$ git checkout FETCH_HEAD
$ cd jbosstools/multiple
$ mvn clean install
Then, try with just built target-platform:
$ cd /path/to/your/component
$ mvn clean verify -Dtpc.version=4.40.0.Beta3 -Pmultiple.target
Feedback/comments/details are welcome on https://issues.jboss.org/browse/JBIDE-17603
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9 years, 10 months
When contributing to jbosstools-aerogear
by Gorkem Ercan
Hi All,
As you may already know, we are in the process of moving most of our
Hybrid Mobile tooling development to Thym project[1] in Eclipse foundation.
Initially we will move all but the CordovaSim to Eclipse foundation.
This translates to cordova sub directory on the jbosstools-aerogear
repository.
I have already extracted and send the initial contribution for IP review
to Eclipse [2] ,[3]. On the jbosstool-saerogear repo the contribution is
marked with initial_eclipse_contribution tag. Now that we have started our
initial contribution process, this means that changes made to the
contributed code (basically the cordova directory) needs to follow
eclipse rules [4]. I think the first practical impact of this is every
contributor needs to sign the Eclipse CLA at [4]. If you have not
already and planning to contribute to cordova tooling please do so now.
If you already have CLA, it is business as usual for you until we move
the daily development to its new repo at [5]. I hope this works out for
all.
Thanks,
--
Gorkem
[1] https://www.eclipse.org/thym
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=437287
[3] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8366
[4] https://www.eclipse.org/contribute/
[5] https://github.com/eclipse/thym
9 years, 10 months
A few Central PR awaiting reviews
by Mickael Istria
Hi all,
I'm currently working on fixing/improving several details related to the
new Central page and Early Access.
There are already a few PRs pending on this topic, and since most
changes almost always affect the 3 or 4 same files, I'd be glad if
someone could review and merge them ASAP on order to avoid some pain
when trying to merge everything together later. The longer this commit
are pending for merge, the bigger risk of divergence becomes with
current development. Let's avoid this extra-effort.
Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
9 years, 10 months
Github commits w/o link to JIRA
by Alexey Kazakov
Hi,
This is just a reminder for all developers, please don't forget to start
commit messages with the link to the corresponding JIRA.
It makes life of the rest of the team much easer when we need to track
or investigate changes in someones (or even in your own) code.
For example I see only a few commits with proper messages in
https://github.com/jbosstools/jbosstools-forge/commits/master and
https://github.com/jbosstools/jbosstools-hibernate/commits/master
The practice when there is a mix of small (sometimes atomic) changes
related to different tasks (= JIRA) is not helping either :(
Ideally it should be one commit for one repo/branch for one JIRA (when
possible). And the message of the commit starts with a short link to the
JIRA: JBIDE-XYZ
Thanks.
9 years, 10 months
Fwd: JBDS Usage Stats
by Michelle Murray
I'm updating the docs for Beta2.
I've tried looking through the recent jiras to identify what stats are now being collected for JBDS/JBT installs.
I particularly want to know what's in for JBDS 8.0.0 Beta2.
Please check the screenshot and let me know if I'm missing anything or have anything wrong.
The last table row is the one that I've added for JBDS 8.0.0.
Thanks,
Michelle
9 years, 10 months
How to Triage Issues?
by Rob Stryker
Hi All:
Do we have a document available with the proper way to triage issues? I
seriously have no idea anymore, and every time I try to change an old
issue, I end up getting an email telling me that it's not triaged now.
I used to assign myself, even if I didn't intend to work on it, to
indicate that it "was read". I was told this was incorrect, and that
there should be no assignee if nobody is actively working on it.
I also used to mark it as targeted to later, but I was told this was
vague and should not be used as a dumping ground for all issues that
aren't on the plan.
But if I leave the fix version blank (to indicate it is not on my plan),
I get an email telling me the issue is untriaged.
I also tried commenting on issues, to indicate that I've seen them, but
didn't change the fix version or assignee since I did not have a firm
target for it.... but this gets the same emails.
Should I go in right now and bulk-change all my unassigned untargeted
issues to myself with a fix version, even if I have no idea if that fix
version is accurate? Or should I mark all I don't have a firm target for
to "Later" ?
What's the process here?
9 years, 10 months
