[JBoss JIRA] (JBIDE-19780) Confusing <id> placeholder in Batch Diagram editor
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19780?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-19780:
----------------------------------------
I pushed the current PR to master. But I agree with [~scabanovich]. It would be a better solution if a new element is created with some generated ID instead of an empty one.
> Confusing <id> placeholder in Batch Diagram editor
> --------------------------------------------------
>
> Key: JBIDE-19780
> URL: https://issues.jboss.org/browse/JBIDE-19780
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: batch
> Affects Versions: 4.3.0.Beta1
> Reporter: Tomáš Milata
> Assignee: Tomáš Milata
> Priority: Minor
> Labels: usability
> Fix For: 4.3.0.Beta1
>
>
> Currently, when no id of an element is entered, the "<id>" label is displayed in the node.
> This caused issues during usability testing. User for some reason thought the "<>" characters have some meaning and edited the value to "<myId>" and then was confused why he sees "<" and ">" sequences in the XML.
> Note that sapphire does not have placeholders, so this is just a workaround (when id is null, the <id> text is shown).
> This approach is has also disadvantage that if user double click the <id> of empty id, presses an arrow and then enter, the whole <id> value originally meant as a placeholder is now the literal value of the property.
> I suggest keeping the place for label just empty. User can be still notified by a validation marker and the label inline editor is still accessible by double click.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-13835) Improve publish script (split? Move to maven?)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13835 at 5/12/15 7:04 PM:
-------------------------------------------------------------
> Define: "recreating it in another language"
# We already have bash code that generates an md5sum. You want java code within a mojo to achieve the same thing. Therefore, you are asking to recreate existing workflow functionality in a new language.
My point here is that IF we're going to simply rewrite something, we might as well *improve it too* by moving from MD5 to SHA1.
was (Author: nickboldt):
> Define: "recreating it in another language"
# We already have bash code that generates an md5sum. You want java code within a mojo to achieve the same thing. Therefore, you are asking to recreate existing workflow functionality in a new language.
> Improve publish script (split? Move to maven?)
> ----------------------------------------------
>
> Key: JBIDE-13835
> URL: https://issues.jboss.org/browse/JBIDE-13835
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.3.x
>
>
> Publish script deals with a lot of different and not-always-related things. It makes it difficult to maintain it. We should think about some improvements such as
> * different conventions from different stream
> * components vs aggregate
> * devstudio vs jbosstools.
> Or,
> * Make publishing part of a "mvn deploy" step.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-13835) Improve publish script (split? Move to maven?)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13835:
------------------------------------
> Define: "recreating it in another language"
# We already have bash code that generates an md5sum. You want java code within a mojo to achieve the same thing. Therefore, you are asking to recreate existing workflow functionality in a new language.
> Improve publish script (split? Move to maven?)
> ----------------------------------------------
>
> Key: JBIDE-13835
> URL: https://issues.jboss.org/browse/JBIDE-13835
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.3.x
>
>
> Publish script deals with a lot of different and not-always-related things. It makes it difficult to maintain it. We should think about some improvements such as
> * different conventions from different stream
> * components vs aggregate
> * devstudio vs jbosstools.
> Or,
> * Make publishing part of a "mvn deploy" step.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-13835) Improve publish script (split? Move to maven?)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13835?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13835:
------------------------------------
"We are already moving source zips around for every build "
No, we're not. We don't produce source zips for the components. Surely you've noticed we only produce update sites w/ source BUNDLES in them, but no source-dump zips?
--
"If someone does a push force in between. It will mean the source gathering will fail most likely though."
Actually, I think even when you force push the old SHAs persist in a detached state -- I've been able to access old commits via the github website even after force pushing to replace them in a topic branch. So the tip of the branch moves to a new SHA, but that old one will still be resolvable and therefore the source fetch should still work. But... I thought force pushes to origin were not allowed, so this shouldn't even matter as it'll never happen.
+0.75 for PR 185. Comments on the PR: can we have less boilerplate and more inheritance w/ variable overrides? Also you forgot about the central and earlyaccess sites, published by the child-sites job [1].
[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
> Improve publish script (split? Move to maven?)
> ----------------------------------------------
>
> Key: JBIDE-13835
> URL: https://issues.jboss.org/browse/JBIDE-13835
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.3.x
>
>
> Publish script deals with a lot of different and not-always-related things. It makes it difficult to maintain it. We should think about some improvements such as
> * different conventions from different stream
> * components vs aggregate
> * devstudio vs jbosstools.
> Or,
> * Make publishing part of a "mvn deploy" step.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19776) Create and use Mars M7 target-platform
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19776?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-19776:
------------------------------------
Max,
* omitting tm.terminal (plugin) will break Server builds
* tm.terminal.feature is the replacement for the ecf.te feature which you explicitly told me to include above. Rob also told me to include this because it includes all the local, ssh, telnet, etc. connectors
* tm.terminal.feature includes connector.local, which requires some CDT stuff from within Mars M7, including *platform-specific fragments*
But you appear to be saying:
* omit tm.terminal; doesn't matter if Server builds break
So, assuming you agree that there's an end-user or technical reason stated above, I can include ONLY the tm.terminal plugin for now.
Then, you can debate w/ Rob if it makes sense to have JBT Server Tooling also include the new tm.terminal.feature, which includes connector.local, which depends on CDT *platform-specific* fragments being installed too.
Note that we currently have NO platform-dependent fragments in the target platform. Adding them will make the TP only buildable on a single platform (like 64-bit Linux). Instead -- if we need this connector.local thing -- we may need to repackage the CDT stuff into an update site (as we've done for Xulrunner) and link to it when building update sites, rather than including it in a TP.
Does that make the problem more concise? I hope so, since I've asked if you want to include something that drags in CDT plugins three times now without a concise answer. :(
I am asking about it here, not in JBIDE-17686, because whatever we decide affects the contents of the target platform as well as what gets installed along with Server Tools.
> Create and use Mars M7 target-platform
> --------------------------------------
>
> Key: JBIDE-19776
> URL: https://issues.jboss.org/browse/JBIDE-19776
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Priority: Blocker
> Fix For: 4.3.0.Beta1
>
> Attachments: jbdevstudio.p2diff.txt, jbdevstudio.p2diff.v3.txt, jbosstools.p2diff.txt, jbosstools.p2diff.v3.txt
>
>
> Mars M7 was released and contains interesting changes.
> We need to start using it ASAP to leverage new functionalities and adapt to the most important changes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19757) Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19757?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-19757:
------------------------------------
More explicit than this?
https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/j...
True, having two URLs point to the same content could befuddle p2, but the wtp server adapter discovery site is only loaded once. I can't imagine you'd get much performance gain from having it point to a site which is already cached because you're a JBoss Tools user.
If you can prove there's performance gain by using a composite instead of a symlink, then I will agree with you that your approach is better than mine.
I believe 1 file saying the same thing as 2 is better from a maintenance & simplicity perspective. And this year's goal w/ the release process refactoring was to make things EASIER to maintain by simplifying, right?
> Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-19757
> URL: https://issues.jboss.org/browse/JBIDE-19757
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, server
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.3.0.Beta1
>
>
> With https://bugs.eclipse.org/bugs/show_bug.cgi?id=434185 , WTP Server Discovery mechanism was granted a new strategy which allows to rely on regular p2 metadata instead of a site.xml.
> Support for this was already merged in server ( https://github.com/jbosstools/jbosstools-server/commit/2d3cc63a9b67753ad9... )
> In order to save an artifact to manage (the webtools p2 repository), we could use this mechanism and consider contributing directly the main JBT URL to webtools discovery.
> However, server discovery also keeps older strategies and since we produce invalid site.xml files, this is currently failing
> {code}
> !ENTRY org.eclipse.equinox.p2.updatesite 2 0 2015-05-04 09:40:58.088
> !MESSAGE Error parsing feature stream. The unique identifier or the version is null or empty for the State: "Category": unique identifier="minimal-json" version="null".
> {code}
> because we are lines specifying bundle but no version in the site.xml.
> [~nickboldt] What are those site.xml useful for? Could we get rid of them?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19757) Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19757?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19757:
---------------------------------------------
I'll keep claiming and I believe [~mickael_istria] stated the same in the past that a composite is much more explicit than using symbolic links.
With same url pointing to exact same site p2 will think its different sites and I wonder how that will affect caching/loading of these sites.
> Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-19757
> URL: https://issues.jboss.org/browse/JBIDE-19757
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, server
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.3.0.Beta1
>
>
> With https://bugs.eclipse.org/bugs/show_bug.cgi?id=434185 , WTP Server Discovery mechanism was granted a new strategy which allows to rely on regular p2 metadata instead of a site.xml.
> Support for this was already merged in server ( https://github.com/jbosstools/jbosstools-server/commit/2d3cc63a9b67753ad9... )
> In order to save an artifact to manage (the webtools p2 repository), we could use this mechanism and consider contributing directly the main JBT URL to webtools discovery.
> However, server discovery also keeps older strategies and since we produce invalid site.xml files, this is currently failing
> {code}
> !ENTRY org.eclipse.equinox.p2.updatesite 2 0 2015-05-04 09:40:58.088
> !MESSAGE Error parsing feature stream. The unique identifier or the version is null or empty for the State: "Category": unique identifier="minimal-json" version="null".
> {code}
> because we are lines specifying bundle but no version in the site.xml.
> [~nickboldt] What are those site.xml useful for? Could we get rid of them?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19776) Create and use Mars M7 target-platform
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19776?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-19776:
---------------------------------------------
No, I said it looked like these plugins were *not* in M7 and [~rob.stryker] didn't seem to have even looked at it yet so if that was true it did not make sense to add them blindly.
And my reply was to your comment saying talking about https://github.com/nickboldt/jbosstools-target-platforms/commit/5300fdbb6....
Anyway, I don't think there is any reason we talk about this when this is server related stuff [~rob.stryker] should fix/be working on.
We should neither add or remove plugins just to fix a build failure - it should be added or removed if it is the right thing to do for end-user or technical reasons.
In past we added terminal to server to make it actually usable. The task in JBIDE-17686 is about doing that.
> Create and use Mars M7 target-platform
> --------------------------------------
>
> Key: JBIDE-19776
> URL: https://issues.jboss.org/browse/JBIDE-19776
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform
> Reporter: Nick Boldt
> Assignee: Mickael Istria
> Priority: Blocker
> Fix For: 4.3.0.Beta1
>
> Attachments: jbdevstudio.p2diff.txt, jbdevstudio.p2diff.v3.txt, jbosstools.p2diff.txt, jbosstools.p2diff.v3.txt
>
>
> Mars M7 was released and contains interesting changes.
> We need to start using it ASAP to leverage new functionalities and adapt to the most important changes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19728) Easy Import - The first and second screens in the dialog should be merged into one
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19728?page=com.atlassian.jira.plugi... ]
Len DiMaggio updated JBIDE-19728:
---------------------------------
Attachment: May11_nightly2.png
May11_nightly.png
It's much improved in the May 11 nightly - thanks!
> Easy Import - The first and second screens in the dialog should be merged into one
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-19728
> URL: https://issues.jboss.org/browse/JBIDE-19728
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: easymport
> Affects Versions: 4.3.0.Alpha2
> Reporter: Len DiMaggio
> Assignee: Mickael Istria
> Fix For: 4.3.0.Beta1
>
> Attachments: import_1.png, import_2.png, May11_nightly.png, May11_nightly2.png
>
>
> See the attached screenshots - in the first dialog screen (1/6), the user is presented with a largely blank display. After he/she selects "next" the dialog (2/6) shows the projects that are eligible to be imported.
> Why not simply skip the first screen and start with the second?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months