[JBoss JIRA] (JBIDE-22283) reveng *.java emitter does not escape java keyword 'return' as variable name
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22283?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-22283 at 7/20/16 4:04 PM:
---------------------------------------------------------------
No the issue is that the "property" name needs to be "return" this is indeed a valid name.
But the local variable name needs to be called something else (but this is autogenerated and no mechanism exists to configure it).
The property accessors code would look like:
public void setReturn(Return return_) {
this.autoGeneratedVariableCouldNotCareLessWhatItIsCalled = return_;
}
public Return getReturn() {
return autoGeneratedVariableCouldNotCareLessWhatItIsCalled;
}
Note the problem is not that the property should be renamed to "return_" but that the unimportant auto-generated local variables get an invalid name. Since it is valid for a method signature getReturn() and setReturn(Return) and valid for an Object type to be called "Return".
Does this explain better the problem is not one that can be configured around.
Acceptable fixes would be:
* Allow the local variable name to be configured, independently of the property name.
OR
* Simply apply heuristics if the resulting auto-generated variable names turn out to be valid java keywords or reserved words. Note you need a process to apply a modification to the variable name and retest it. You also need to keep a Set<String> of all the currently allocated local variable names and as one of the tests, check you did not already use that reserved name as a local variable for some other things. You should iterate the heuristics.
return // would fail
return_ // would be ok (if iteration is 0)
return_1 // would be ok (if iteration is 1)
return_2 // would be ok (if iteration is 2)
// keep iterating to find a suitable name for maybe 100 times, then give up with error.
etc... the above is an idea of how you would keep trying to generate a local variable name that could be used that matches all the criteria.
was (Author: dlmiles):
No the issue is that the "property" name needs to be "return" this is indeed a valid name.
But the local variable name needs to be called something else (but this is autogenerated and no mechanism exists to configure it).
The property accessors code would look like:
public void setReturn(Return return_) {
this.autoGeneratedVariableCouldNotCareLessWhatItIsCalled = return_;
}
public Return getReturn() {
return autoGeneratedVariableCouldNotCareLessWhatItIsCalled;
}
Note the problem is not that the property should be renamed to "return_" but that the unimportant auto-generated local variables get an invalid name. Since it is valid for a method signature getReturn() and setReturn(Return) and valid for an Object type to be called "Return".
Does this explain better the problem is not one that can be configured around.
Acceptable fixes would be:
* Allow the local variable name to be configured, independently of the property name.
OR
* Simply apply heuristics if the resulting auto-generated variable names turn out to be valid java keywords or reserved words. Note you need a process to apply a modification to the variable name and retest it. You also need to keep a Set<String> of all the currently allocated local variable names and as one of the tests, check you did not already use that reserved name as a local variable for some other things. You should iterate the heuristics.
return // would fail
return_ // would be ok (if iteration is 0)
return_1 // would be ok (if iteration is 1)
return_2 // would be ok (if iteration is 2)
// keep iterating to find a suitable name for maybe 100 times, then give up with error.
etc... the above is an idea of how you would keep trying to generate a local variable name that could be used that matches all the criteria.
> reveng *.java emitter does not escape java keyword 'return' as variable name
> ----------------------------------------------------------------------------
>
> Key: JBIDE-22283
> URL: https://issues.jboss.org/browse/JBIDE-22283
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.3.x
> Environment: Eclipse Mars
> Reporter: Darryl Miles
> Assignee: Koen Aers
> Fix For: 4.4.1.AM2
>
>
> reveng *.java emitter does not escape java keyword 'return' as variable name
> <table name="oc_return_history">
> <foreign-key constraint-name="FK_oc_return_history__return_id" foreign-table="oc_return">
> <column-ref local-column="return_id" foreign-column="return_id"/>
> <!-- this breaks the generator trying to name local variable as a java keyword -->
> <many-to-one property="return"/>
> </foreign-key>
> </table>
> The expected output would be:
> private Return _return;
> but actual output is:
> private Return return;
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22283) reveng *.java emitter does not escape java keyword 'return' as variable name
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22283?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-22283 at 7/20/16 4:03 PM:
---------------------------------------------------------------
No the issue is that the "property" name needs to be "return" this is indeed a valid name.
But the local variable name needs to be called something else (but this is autogenerated and no mechanism exists to configure it).
The property accessors code would look like:
public void setReturn(Return return_) {
this.autoGeneratedVariableCouldNotCareLessWhatItIsCalled = return_;
}
public Return getReturn() {
return autoGeneratedVariableCouldNotCareLessWhatItIsCalled;
}
Note the problem is not that the property should be renamed to "return_" but that the unimportant auto-generated local variables get an invalid name. Since it is valid for a method signature getReturn() and setReturn(Return) and valid for an Object type to be called "Return".
Does this explain better the problem is not one that can be configured around.
Acceptable fixes would be:
* Allow the local variable name to be configured, independently of the property name.
OR
* Simply apply heuristics if the resulting auto-generated variable names turn out to be valid java keywords or reserved words. Note you need a process to apply a modification to the variable name and retest it. You also need to keep a Set<String> of all the currently allocated local variable names and as one of the tests, check you did not already use that reserved name as a local variable for some other things. You should iterate the heuristics.
return // would fail
return_ // would be ok (if iteration is 0)
return_1 // would be ok (if iteration is 1)
return_2 // would be ok (if iteration is 2)
// keep iterating to find a suitable name for maybe 100 times, then give up with error.
etc... the above is an idea of how you would keep trying to generate a local variable name that could be used that matches all the criteria.
was (Author: dlmiles):
No the issue is that the "property" name needs to be "return" this is indeed a valid name.
But the local variable name needs to be called something else (but this is autogenerated and no mechanism exists to configure it).
The property accessors code would look like:
public void setReturn(Return return_) {
this.autoGeneratedVariableCouldNotCareLessWhatItIsCalled = return_;
}
public Return getReturn() {
return autoGeneratedVariableCouldNotCareLessWhatItIsCalled;
}
Note the problem is not that the property should be renamed to "return_" but that the unimportant auto-generated local variables get an invalid name. Since it is valid for a method signature getReturn() and setReturn(Return).
Does this explain better the problem is not one that can be configured around.
Acceptable fixes would be:
* Allow the local variable name to be configured, independently of the property name.
OR
* Simply apply heuristics if the resulting auto-generated variable names turn out to be valid java keywords or reserved words. Note you need a process to apply a modification to the variable name and retest it. You also need to keep a Set<String> of all the currently allocated local variable names and as one of the tests, check you did not already use that reserved name as a local variable for some other things. You should iterate the heuristics.
return // would fail
return_ // would be ok (if iteration is 0)
return_1 // would be ok (if iteration is 1)
return_2 // would be ok (if iteration is 2)
// keep iterating to find a suitable name for maybe 100 times, then give up with error.
etc... the above is an idea of how you would keep trying to generate a local variable name that could be used that matches all the criteria.
> reveng *.java emitter does not escape java keyword 'return' as variable name
> ----------------------------------------------------------------------------
>
> Key: JBIDE-22283
> URL: https://issues.jboss.org/browse/JBIDE-22283
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.3.x
> Environment: Eclipse Mars
> Reporter: Darryl Miles
> Assignee: Koen Aers
> Fix For: 4.4.1.AM2
>
>
> reveng *.java emitter does not escape java keyword 'return' as variable name
> <table name="oc_return_history">
> <foreign-key constraint-name="FK_oc_return_history__return_id" foreign-table="oc_return">
> <column-ref local-column="return_id" foreign-column="return_id"/>
> <!-- this breaks the generator trying to name local variable as a java keyword -->
> <many-to-one property="return"/>
> </foreign-key>
> </table>
> The expected output would be:
> private Return _return;
> but actual output is:
> private Return return;
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22283) reveng *.java emitter does not escape java keyword 'return' as variable name
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22283?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-22283 at 7/20/16 4:02 PM:
---------------------------------------------------------------
No the issue is that the "property" name needs to be "return" this is indeed a valid name.
But the local variable name needs to be called something else (but this is autogenerated and no mechanism exists to configure it).
The property accessors code would look like:
public void setReturn(Return return_) {
this.autoGeneratedVariableCouldNotCareLessWhatItIsCalled = return_;
}
public Return getReturn() {
return autoGeneratedVariableCouldNotCareLessWhatItIsCalled;
}
Note the problem is not that the property should be renamed to "return_" but that the unimportant auto-generated local variables get an invalid name. Since it is valid for a method signature getReturn() and setReturn(Return).
Does this explain better the problem is not one that can be configured around.
Acceptable fixes would be:
* Allow the local variable name to be configured, independently of the property name.
OR
* Simply apply heuristics if the resulting auto-generated variable names turn out to be valid java keywords or reserved words. Note you need a process to apply a modification to the variable name and retest it. You also need to keep a Set<String> of all the currently allocated local variable names and as one of the tests, check you did not already use that reserved name as a local variable for some other things. You should iterate the heuristics.
return // would fail
return_ // would be ok (if iteration is 0)
return_1 // would be ok (if iteration is 1)
return_2 // would be ok (if iteration is 2)
// keep iterating to find a suitable name for maybe 100 times, then give up with error.
etc... the above is an idea of how you would keep trying to generate a local variable name that could be used that matches all the criteria.
was (Author: dlmiles):
No the issue is that the "property" name needs to be "return" this is indeed a valid name.
But the local variable name needs to be called something else (but this is autogenerated and not mechanism exists to configure it).
The property accessors code would look like:
public void setReturn(Return return_) {
this.autoGeneratedVariableCouldNotCareLessWhatItIsCalled = return_;
}
public Return getReturn() {
return autoGeneratedVariableCouldNotCareLessWhatItIsCalled;
}
Note the problem is not that the property should be renamed to "return_" but that the unimportant auto-generated local variables get an invalid name. Since it is valid for a method signature getReturn() and setReturn(Return).
Does this explain better the problem is not one that can be configured around.
> reveng *.java emitter does not escape java keyword 'return' as variable name
> ----------------------------------------------------------------------------
>
> Key: JBIDE-22283
> URL: https://issues.jboss.org/browse/JBIDE-22283
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.3.x
> Environment: Eclipse Mars
> Reporter: Darryl Miles
> Assignee: Koen Aers
> Fix For: 4.4.1.AM2
>
>
> reveng *.java emitter does not escape java keyword 'return' as variable name
> <table name="oc_return_history">
> <foreign-key constraint-name="FK_oc_return_history__return_id" foreign-table="oc_return">
> <column-ref local-column="return_id" foreign-column="return_id"/>
> <!-- this breaks the generator trying to name local variable as a java keyword -->
> <many-to-one property="return"/>
> </foreign-key>
> </table>
> The expected output would be:
> private Return _return;
> but actual output is:
> private Return return;
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22283) reveng *.java emitter does not escape java keyword 'return' as variable name
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22283?page=com.atlassian.jira.plugi... ]
Darryl Miles commented on JBIDE-22283:
--------------------------------------
No the issue is that the "property" name needs to be "return" this is indeed a valid name.
But the local variable name needs to be called something else (but this is autogenerated and not mechanism exists to configure it).
The property accessors code would look like:
public void setReturn(Return return_) {
this.autoGeneratedVariableCouldNotCareLessWhatItIsCalled = return_;
}
public Return getReturn() {
return autoGeneratedVariableCouldNotCareLessWhatItIsCalled;
}
Note the problem is not that the property should be renamed to "return_" but that the unimportant auto-generated local variables get an invalid name. Since it is valid for a method signature getReturn() and setReturn(Return).
Does this explain better the problem is not one that can be configured around.
> reveng *.java emitter does not escape java keyword 'return' as variable name
> ----------------------------------------------------------------------------
>
> Key: JBIDE-22283
> URL: https://issues.jboss.org/browse/JBIDE-22283
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.3.x
> Environment: Eclipse Mars
> Reporter: Darryl Miles
> Assignee: Koen Aers
> Fix For: 4.4.1.AM2
>
>
> reveng *.java emitter does not escape java keyword 'return' as variable name
> <table name="oc_return_history">
> <foreign-key constraint-name="FK_oc_return_history__return_id" foreign-table="oc_return">
> <column-ref local-column="return_id" foreign-column="return_id"/>
> <!-- this breaks the generator trying to name local variable as a java keyword -->
> <many-to-one property="return"/>
> </foreign-key>
> </table>
> The expected output would be:
> private Return _return;
> but actual output is:
> private Return return;
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBIDE-22757) jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22757?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-22757:
------------------------------------
Using BUILD_ID is no longer "fine" since for 7 years it's been a yyyy-mm-dd_HH-MM-SS timestamp and now it's the same value as BUILD_NUMBER. So you can split hairs and say the problem is the scripts or the problem is the API in Jenkins has changed; either way, it's a problem that NEEDS fixing.
Without the timestamps, we need another metric to decide when jbosstools-cleanup.sh should purge old folders. I suppose we could check for creation dates, rather than using the folder name.
Meanwhile, to purge incorrectly named build folders (eg., 1000-B1000 instead of 2016-07-20_12-34-56-B1000) & invalid 'latest' symlinks, I've used:
{code}cd ~/JBDS-ssh/10.0/snapshots/builds
for d in $(find jbosstools-* devstudio* -maxdepth 1 -mindepth 1 -regextype posix-extended -regex '.*/[0-9]+-B[0-9]+' -type d); do echo $d; { rm -fr ${d} & } ; done
for d in $(find . -maxdepth 2 -mindepth 2 -name latest); do e=$(ls -la ${d} | grep -v "2016-"); if [[ $e ]]; then echo $e; f=$(echo $e | sed "s#.\+\(\./.\+/latest\).\+#\1#"); echo $f; rm -f $f;fi; done
{code}
Then again for JBT:
{code}
cd ~/TOOLS-ssh/neon/snapshots/builds
for d in $(find jbosstools-* devstudio* -maxdepth 1 -mindepth 1 -regextype posix-extended -regex '.*/[0-9]+-B[0-9]+' -type d); do echo $d; { rm -fr ${d} & } ; done
for d in $(find . -maxdepth 2 -mindepth 2 -name latest); do e=$(ls -la ${d} | grep -v "2016-"); if [[ $e ]]; then echo $e; f=$(echo $e | sed "s#.\+\(\./.\+/latest\).\+#\1#"); echo $f; rm -f $f;fi; done
{code}
> jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)
> -----------------------------------------------------------------
>
> Key: JBIDE-22757
> URL: https://issues.jboss.org/browse/JBIDE-22757
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.4.1.AM2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Priority: Blocker
> Fix For: 4.4.1.AM2
>
> Attachments: buildID-broken.png
>
>
> Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER.
> [1] https://issues.jenkins-ci.org/browse/JENKINS-26520
> [2] https://issues.jenkins-ci.org/browse/JENKINS-26626
> So instead of timestamped build folders, we're seeing things like this:
> !buildID-broken.png|thumbnail!
> Workaround until fixed in Jenkins:
> {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code}
> Or, try using BUILD_TIMESTAMP instead?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBTIS-654) JBDSIS stand-alone installer
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-654?page=com.atlassian.jira.plugin.... ]
Paul Leacu commented on JBTIS-654:
----------------------------------
I finally had a chance to get back to this. The following PR does the following:
https://github.com/jbdevstudio/jbdevstudio-product/pull/389
- Establishes the ability to extend the devstudio installer with an arbitrary list of runtimes:
- the user selects these runtimes via a new izPack panel
(I didn't want to overload or confuse the purpose of the existing panels)
- if no runtimes are specified the panel is hidden
- the runtimes must be in zip format and are inflated into the devstudio "runtimes" directory
- the devstudio runtime detection feature will automatically initialize these runtime servers
- the added runtimes are defined in json format
- minimal impact to the existing devstudio installer
- added the ability to default select the runtimes
- Here's what a user would see - using the JBoss Fuse Server as an example:
[^inst1a.png]
[^inst2.png]
[^inst3.png]
[^inst4.png]
Since the Integration Stack will create the Fuse-specific installer, we can default the selection
of the Fuse Tooling feature and JBoss Fuse server. The only checkbox the user is required to select
is the EULA. The user gets devstudio, Fuse Tooling and a Fuse Runtime in one (big) installer.
You can try the installer here - it currently fails when initializing the JBoss Fuse server (post runtime detection on startup). This is because the Neon Fuse Tooling bits aren't ready yet.
http://download.jboss.org/jbosstools/neon/staging/updates/integration-sta...
[~dgolovin] - could you take a look at the PR. It's actually pretty compact and very similar to the p2 feature additions you added.
> JBDSIS stand-alone installer
> ----------------------------
>
> Key: JBTIS-654
> URL: https://issues.jboss.org/browse/JBTIS-654
> Project: JBoss Tools Integration Stack
> Issue Type: Feature Request
> Components: distribution
> Affects Versions: 9.0.0.GA
> Reporter: Paul Leacu
> Assignee: Paul Leacu
> Fix For: 9.0.1.GA
>
> Attachments: Capture.JPG, inst1.png, inst1.png, inst1a.png, inst2.png, inst3.png, inst4.png
>
>
> Establish a stand-alone installer for JBDSIS that will contain JBDS and will enable easier installation of JBDSIS components - specifically Fuse Tooling. This Jira is specifically related to the JBDSIS installer. Other usability issues will be handled in other Jira.
> Installation scenario:
> {code}
> 1. If you don't already have one installed, you will need to download and install Oracle or Open JDK 8. (make sure you have Java 1.8 installed)
> 2. Download the JBDSIS installer jar. i.e. wget https://devstudio.redhat.com/9.0/snapshots/updates/integration-stack/9.0....
> 3. Double-click the installer file to run it, or open a terminal and type `java -jar /path/to/installer-*.jar`
> 4. Select 'JBoss Fuse Development' from the 'Select Additional Features to Install' installer window.
> 5. Accept/ respond 'Yes' and restart
> 6. Select Window > Perspective > Open Perspective > Fuse Integration
> {code}
> A prototype installer has already been created - see:
> https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBTIS-654) JBDSIS stand-alone installer
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-654?page=com.atlassian.jira.plugin.... ]
Paul Leacu updated JBTIS-654:
-----------------------------
Attachment: inst1a.png
> JBDSIS stand-alone installer
> ----------------------------
>
> Key: JBTIS-654
> URL: https://issues.jboss.org/browse/JBTIS-654
> Project: JBoss Tools Integration Stack
> Issue Type: Feature Request
> Components: distribution
> Affects Versions: 9.0.0.GA
> Reporter: Paul Leacu
> Assignee: Paul Leacu
> Fix For: 9.0.1.GA
>
> Attachments: Capture.JPG, inst1.png, inst1.png, inst1a.png, inst2.png, inst3.png, inst4.png
>
>
> Establish a stand-alone installer for JBDSIS that will contain JBDS and will enable easier installation of JBDSIS components - specifically Fuse Tooling. This Jira is specifically related to the JBDSIS installer. Other usability issues will be handled in other Jira.
> Installation scenario:
> {code}
> 1. If you don't already have one installed, you will need to download and install Oracle or Open JDK 8. (make sure you have Java 1.8 installed)
> 2. Download the JBDSIS installer jar. i.e. wget https://devstudio.redhat.com/9.0/snapshots/updates/integration-stack/9.0....
> 3. Double-click the installer file to run it, or open a terminal and type `java -jar /path/to/installer-*.jar`
> 4. Select 'JBoss Fuse Development' from the 'Select Additional Features to Install' installer window.
> 5. Accept/ respond 'Yes' and restart
> 6. Select Window > Perspective > Open Perspective > Fuse Integration
> {code}
> A prototype installer has already been created - see:
> https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBTIS-654) JBDSIS stand-alone installer
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-654?page=com.atlassian.jira.plugin.... ]
Paul Leacu updated JBTIS-654:
-----------------------------
Attachment: inst4.png
inst3.png
inst2.png
inst1.png
> JBDSIS stand-alone installer
> ----------------------------
>
> Key: JBTIS-654
> URL: https://issues.jboss.org/browse/JBTIS-654
> Project: JBoss Tools Integration Stack
> Issue Type: Feature Request
> Components: distribution
> Affects Versions: 9.0.0.GA
> Reporter: Paul Leacu
> Assignee: Paul Leacu
> Fix For: 9.0.1.GA
>
> Attachments: Capture.JPG, inst1.png, inst1.png, inst2.png, inst3.png, inst4.png
>
>
> Establish a stand-alone installer for JBDSIS that will contain JBDS and will enable easier installation of JBDSIS components - specifically Fuse Tooling. This Jira is specifically related to the JBDSIS installer. Other usability issues will be handled in other Jira.
> Installation scenario:
> {code}
> 1. If you don't already have one installed, you will need to download and install Oracle or Open JDK 8. (make sure you have Java 1.8 installed)
> 2. Download the JBDSIS installer jar. i.e. wget https://devstudio.redhat.com/9.0/snapshots/updates/integration-stack/9.0....
> 3. Double-click the installer file to run it, or open a terminal and type `java -jar /path/to/installer-*.jar`
> 4. Select 'JBoss Fuse Development' from the 'Select Additional Features to Install' installer window.
> 5. Accept/ respond 'Yes' and restart
> 6. Select Window > Perspective > Open Perspective > Fuse Integration
> {code}
> A prototype installer has already been created - see:
> https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months