[
https://issues.jboss.org/browse/JBIDE-13599?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen commented on JBIDE-13599:
---------------------------------------------
Here is a pullrequest (
https://github.com/jbosstools/jbosstools-central/pull/75) which
incorporates majority of the concerns raised in here.
basic usage/sytax is the same as described by Snjezana.
But to answer the concerns which seemed to have drowned:
1) There is no longer any need to have this be a maven only test thus made it so can test
with built-in properties PLUS I just set the system properties from within the test since
the values does not need to point to anything for the tests.
2) "I can also see that DMR would throw an exception if something wrong is resolved -
is that the behavior we need" - I think it makes sense, but we need to add code to
handle this error case so the user can know what is going on. (simple to do I think, just
a todo)
3) "DMR actually does seem to handle multiple values",
yes - ${foo,bar} now works.
4) "the default replacement seem to treat file seperators and path seperators as a
special case and return different results based on OS values"
This just means that {:} and {/} can be used to specify portal file locations (i.e.
{/}file{/}path becomes /file/path on Linux, \file\path on Windows.
Not something we need for this but I kept it in for consistency.
4) "But why we want to add a direct dependency on this library for this simple
functionality I do not grok." - no dependency on this anymore.
5) "We should just copy the code and adjust it for what we need (looks like no
changes needed except a few for the above issues) - note, this is tough LGPL so need to
adjust for that." -- this is now done, put in internal package since its not to be a
public API for now and put in .xpl package and with no dependencies to EPL to oblige to
LGPL/EPL.
If you could give this a try it would be great - I'll try add the error handling; but
if you have time to do it that would be great too :)
externalize Central site URL into a commandline property so that
testing or mirroring is easier
-----------------------------------------------------------------------------------------------
Key: JBIDE-13599
URL:
https://issues.jboss.org/browse/JBIDE-13599
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: central
Affects Versions: 4.1.0.Alpha1
Reporter: Nick Boldt
Assignee: Snjezana Peco
Fix For: 4.1.0.Alpha2
As discussed in
https://issues.jboss.org/browse/JBDS-2469?focusedCommentId=12755106&p...
testing Central is tricky if it's not properly bootstrapped, and bootstrapping is hard
when we're on an early Alpha and don't want bits to be public before they've
passed QE.
A better approach than having the update site URL used in Central's discovery
plugin.xml hardcoded into that file would be to have it read from a Preference in Eclipse
or JBDS. This would allow it to be overwritten/overridden should a user want to test
installation from a different URL than the default value.
This might even make it possible to have the same discovery plugin used for JBT and JBDS
(assuming the list of connectors were the same, and certification was to appear for both
instances) simply by having the preference changed to a different default URL when
installing JBT or JBDS BYOE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira