I would vote for the creation of these two artifacts:
*
jbosstools-server/wtp/features/org.jboss.tools.wst.server.launchbar.feature,
and
* jbosstools-server/wtp/plugins/org.jboss.tools.wst.server.launchbar
--
If it's accepted to Eclipse WTP, it would be refactored like we've done
for m2e-wtp, Thym, and other projects.
Then we'd clean out the plugin from jbosstools-server, and our feature
could simply be a wrapper to install the org.eclipse.wst version, so
that users would be able to upgrade seamlessly from
o.j.t.wst.server.launchbar to o.e.wst.server.launchbar.
Or we could use a p2.inf instruction to make their feature be the update
to ours, replacing ours entirely.
Either way, at that point we'd also add their feature/plugin to our TP
and therefore be able to include it in ours builds.
But all of those steps are moot until their accept it; in the meantime,
we should build them as org.jboss.tools artifacts.
On 05/26/2015 04:46 PM, Rob Stryker wrote:
Questions on Docker / WTP aside, the topic at hand here is how to get
it
into one of our builds until they either accept it or reject it in SR1?
Max has already commented that org.eclipse.wst.server.launchbar seems an
appropriate name. The next questions are:
1) Where it should live for now?
a) I put it in jbosstools-server/wtp or some similar existing repo
b) I put it in a temporary github repository and we simply pull it in?
2) Does it need a feature?
3) Should the feature have an o.j.t. name? Or an o.e.wst.server name?
The questions here are significant, though. Does it make sense that
jbosstools-server/wtp have deps on CDT and o.e.remote, perhaps in a
temporary fashion? Is it reasonable to have org.eclipse plugins and
features inside repositories that currently hold org.jboss.* bundles? Or
does it make more sense for them to live somewhere else, such as in 1b),
a temporary github external repo?
Max: it seems you don't want to give any guidance until you've seen it
in action, but you also don't seem to have the time to play with it...
so I'm left a bit confused as to what *I* can do to get this to move
forward, aside from nagging you relentlessly until you either set up an
environment to look at it or give me specific instructions as to what I
should be doing.
On 05/20/2015 05:49 PM, Max Rydahl Andersen wrote:
> On 20 May 2015, at 20:15, Rob Stryker wrote:
>
>>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>
>> > Have wtp-dev suggested a name for it ?
>>
>> No, so far there are no comments on the bugzilla. I suggest you
>> comment there if you so choose.
>>
>> > btw. does the launchbar work with local java apps and units too ?
>>
>> I probably need more of an explanation as to what you're asking, but,
>> yes, it works for POJP and other launch configs as well. I've
>> successfully seen MyMainClass in the list and run them.
>
> How does that work ? ..what is selected on the right side for that ?
>
>> But running a simple MyMainClass on some remote server doesn't work,
>> if thats your question. Is that something you'd like to see?
>
> Well, since we are looking at having Docker integrated being able to
> run on java app on a docker container would be a usecase to look at
> if this could fit in here.
>
> /max
>
>> On 05/20/2015 03:37 AM, Max Rydahl Andersen wrote:
>>> Rob,
>>>
>>> Have wtp-dev suggested a name for it ?
>>>
>>> btw. does the launchbar work with local java apps and units too ?
>>>
>>> I just realised we've been focusing purely on remote/server runs - but
>>> local runs should work too.
>>>
>>> /max
>>>
>>>> Since JBT 4.3.0.Final is slated for after Mars SR1, this seems
>>>> reasonable.
>>>>
>>>> You don't technically need to have the same IU names to allow a
>>>> seamless
>>>> upgrade from o.j.t.whatever to o.eclipse.wtp.whatever.
>>>>
>>>> We've seen multiple instances where a JBoss project moved to
Eclipse,
>>>> and we were able to support the IU rename using a p2.inf instruction.
>>>>
>>>> Here's what we did to rename from com.jboss.jbds to
>>>> com.jboss.devstudio:
>>>>
>>>>
https://github.com/jbdevstudio/jbdevstudio-product/blob/jbosstools-4.2.x/...
>>>>
>>>>
>>>> We've done similar with m2e-wtp, too.
>>>>
>>>> But of course it's simpler if we just build the plugin using the
>>>> future
>>>> o.e.wtp name, and a lower version.
>>>>
>>>>
>>>> On 05/19/2015 04:58 PM, Rob Stryker wrote:
>>>>> Hi All:
>>>>>
>>>>> wtp-dev mailing list seems to indicate its a bit too late to get
>>>>> such a
>>>>> contribution into Mars. They did suggest it might be reasonable
>>>>> for SR1.
>>>>>
>>>>> With that in mind, we should discuss how to go about getting this
>>>>> into
>>>>> JBT for our Mars release, while still allowing it to be removed /
>>>>> overridden by the eventual contribution to SR1.
>>>>>
>>>>> As of now, it seems the thing most important to discuss is naming
>>>>> of the
>>>>> plugin, to ensure that the name we use matches with the WTP one. The
>>>>> idea seems to be that if we release this plugin as 0.9.0 in JBT,
>>>>> it can
>>>>> be added to WTP for Mars SR1 with a higher version, thus replacing
>>>>> ours.
>>>>>
>>>>> The issue at wtp can be discussed here:
>>>>>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>>>>
>>>>>
>>>>> @Nick: Any ideas on whether this plan makes sense?
>>>>
>>>> --
>>>> Nick Boldt :: JBoss by Red Hat
>>>> Productization Lead :: JBoss Tools & Dev Studio
>>>>
http://nick.divbyzero.com
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>>
>>> /max
>>>
http://about.me/maxandersen
>
>
> /max
>
http://about.me/maxandersen
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio