Re: API of IvyDE

[Greg Amerson <gr...@liferay.com>]

Ah! I can't believe I didn't notice that before.  Thanks for the note, I've
deleted IvyUtil.java from our plugin now.

G


On Sat, Aug 31, 2013 at 2:47 AM, Nicolas Lalevée <nicolas.lalevee@hibnet.org
> wrote:

>
> Le 29 août 2013 à 11:00, Greg Amerson <gr...@liferay.com> a
> écrit :
>
> > Hello Nicolas,
> >
> > We just released a new version of Liferay IDE, that uses IvyDE to
> configure
> > some Ivy based Liferay projects.  We used the latest nightly build of
> IvyDE
> > as our integration point:
> > https://builds.apache.org/job/IvyDE-updatesite/673/
> >
> > So for Liferay projects that use Ivy, our Eclipse plugin does the
> following:
> >
> >   - Add ivy nature
> >   - Add ivy container with a bunch of Liferay specific settings
> >   - Perform resolve on the Ivy container
> >
> > We were able to use the IvyDE exported APIs, in most cases except for
> when
> > we were creating the Ivy container path.  I did not want to hard-code the
> > construction of the container path, instead I feel using the logic from
> > IvyDE directly is much better for downstream projects like us to make
> sure
> > we are constructing the path correctly.  Here is the method that I wanted
> > to use:
> >
> >
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter.getPath(IvyClasspathContainerConfiguration)
> >
> > But this method is unavailable downstream, so for our latest release we
> > created a new class called IvyUtil where we copied this method into it.
> > See here:
> >
> https://github.com/liferay/liferay-ide/blob/master/tools/plugins/com.liferay.ide.sdk.ui/src/com/liferay/ide/sdk/ui/IvyUtil.java
> >
> > Would your team consider creating an API for this usage?
>
> Actually you can call
> org.apache.ivyde.eclipse.cp.IvyClasspathContainerConfiguration.getPath().
>
> Thank you very much for your feedback. Good to know the API is working for
> you.
>
> Nicolas
>
> >
> > Thanks,
> > Greg
> >
> >
> > On Tue, Jul 30, 2013 at 1:56 AM, Nicolas Lalevée <
> nicolas.lalevee@hibnet.org
> >> wrote:
> >
> >> As discussed recently with Greg, IvyDE needs a proper API so that other
> >> plugin can rely on. In house we do a such "external" plugin to IvyDE:
> >> EasyAnt4e, the eclipse plugin for the integration of EasyAnt into
> Eclipse.
> >> I think it is a good use case and I tried to make a proper API usable by
> >> EasyAnt4e. I think I have been able to make something nice. See my last
> >> commit r1508149. And hopefully nothing too internal is exposed.
> >>
> >> There is a corner case though, and I don't know what to do. The
> IvyConsole
> >> (from IvyDE) is extended by EasyAntConsoleImpl (from EasyAnt4e). I am
> not a
> >> big fan of exposing the IvyConsole. It is too tied to the way IvyDE and
> Ivy
> >> itself print the logs. I have not tested, but I guess that in the
> current
> >> state, depending of which console starts first, logs will go in one but
> not
> >> in the other. It might be very confusing for the end user. And
> preferences
> >> regarding the colors and the log level are also being shared. Probably
> >> another mess.
> >> Did I missed something ? Couldn't the EasyAntConsole implements its own
> >> log stream handling ?
> >>
> >> Note: it is a common practice to have "internal" in the name of the
> >> packages which are not exposed. I haven't renamed every package, since
> it
> >> will move a lot of resources. So you should rely on the MANIFEST.MF to
> see
> >> what is actually exposed. But as soon as we are happy with the state of
> the
> >> code, we could rename them.
> >>
> >> Nicolas
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >> For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >>
> >
> >
> > --
> > Greg Amerson
> > Liferay Developer Tools
> > Liferay, Inc. www.liferay.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com

Re: API of IvyDE

[Nicolas Lalevée <ni...@hibnet.org>]

I introduced that method in that last big refactoring the API, since you indicated that it would be helpful to you :)

Nicolas

Le 2 sept. 2013 à 17:12, Greg Amerson <gr...@liferay.com> a écrit :

> Ah! I can't believe I didn't notice that before.  Thanks for the note, I've
> deleted IvyUtil.java from our plugin now.
> 
> G
> 
> 
> On Sat, Aug 31, 2013 at 2:47 AM, Nicolas Lalevée <nicolas.lalevee@hibnet.org
>> wrote:
> 
>> 
>> Le 29 août 2013 à 11:00, Greg Amerson <gr...@liferay.com> a
>> écrit :
>> 
>>> Hello Nicolas,
>>> 
>>> We just released a new version of Liferay IDE, that uses IvyDE to
>> configure
>>> some Ivy based Liferay projects.  We used the latest nightly build of
>> IvyDE
>>> as our integration point:
>>> https://builds.apache.org/job/IvyDE-updatesite/673/
>>> 
>>> So for Liferay projects that use Ivy, our Eclipse plugin does the
>> following:
>>> 
>>>  - Add ivy nature
>>>  - Add ivy container with a bunch of Liferay specific settings
>>>  - Perform resolve on the Ivy container
>>> 
>>> We were able to use the IvyDE exported APIs, in most cases except for
>> when
>>> we were creating the Ivy container path.  I did not want to hard-code the
>>> construction of the container path, instead I feel using the logic from
>>> IvyDE directly is much better for downstream projects like us to make
>> sure
>>> we are constructing the path correctly.  Here is the method that I wanted
>>> to use:
>>> 
>>> 
>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter.getPath(IvyClasspathContainerConfiguration)
>>> 
>>> But this method is unavailable downstream, so for our latest release we
>>> created a new class called IvyUtil where we copied this method into it.
>>> See here:
>>> 
>> https://github.com/liferay/liferay-ide/blob/master/tools/plugins/com.liferay.ide.sdk.ui/src/com/liferay/ide/sdk/ui/IvyUtil.java
>>> 
>>> Would your team consider creating an API for this usage?
>> 
>> Actually you can call
>> org.apache.ivyde.eclipse.cp.IvyClasspathContainerConfiguration.getPath().
>> 
>> Thank you very much for your feedback. Good to know the API is working for
>> you.
>> 
>> Nicolas
>> 
>>> 
>>> Thanks,
>>> Greg
>>> 
>>> 
>>> On Tue, Jul 30, 2013 at 1:56 AM, Nicolas Lalevée <
>> nicolas.lalevee@hibnet.org
>>>> wrote:
>>> 
>>>> As discussed recently with Greg, IvyDE needs a proper API so that other
>>>> plugin can rely on. In house we do a such "external" plugin to IvyDE:
>>>> EasyAnt4e, the eclipse plugin for the integration of EasyAnt into
>> Eclipse.
>>>> I think it is a good use case and I tried to make a proper API usable by
>>>> EasyAnt4e. I think I have been able to make something nice. See my last
>>>> commit r1508149. And hopefully nothing too internal is exposed.
>>>> 
>>>> There is a corner case though, and I don't know what to do. The
>> IvyConsole
>>>> (from IvyDE) is extended by EasyAntConsoleImpl (from EasyAnt4e). I am
>> not a
>>>> big fan of exposing the IvyConsole. It is too tied to the way IvyDE and
>> Ivy
>>>> itself print the logs. I have not tested, but I guess that in the
>> current
>>>> state, depending of which console starts first, logs will go in one but
>> not
>>>> in the other. It might be very confusing for the end user. And
>> preferences
>>>> regarding the colors and the log level are also being shared. Probably
>>>> another mess.
>>>> Did I missed something ? Couldn't the EasyAntConsole implements its own
>>>> log stream handling ?
>>>> 
>>>> Note: it is a common practice to have "internal" in the name of the
>>>> packages which are not exposed. I haven't renamed every package, since
>> it
>>>> will move a lot of resources. So you should rely on the MANIFEST.MF to
>> see
>>>> what is actually exposed. But as soon as we are happy with the state of
>> the
>>>> code, we could rename them.
>>>> 
>>>> Nicolas
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Greg Amerson
>>> Liferay Developer Tools
>>> Liferay, Inc. www.liferay.com
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>> 
>> 
> 
> 
> -- 
> Greg Amerson
> Liferay Developer Tools
> Liferay, Inc. www.liferay.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org