You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Greg Amerson <gr...@liferay.com> on 2013/07/02 12:16:24 UTC
IvyDE adopter use-cases
Hello IvyDE developers,
My name is Greg Amerson and I am the project lead for Liferay IDE, which is
a set of Eclipse plugins for Liferay development. In an upcoming version
of Liferay Portal, we have integrated the use of Ivy dependency management
for plugin projects, e.g. liferay plugins (fancy j2ee web projects) that
are built using JSF portlets now use Ivy to manage jsf dependencies.
Therefore in Liferay IDE when our users create Liferay plugin projects, we
want users to be able to take advantage of the good support in IvyDE for
dependency management, namely the Ivy classpath container. So for new
Liferay projects that are created by our "New Liferay Project wizard" in
our plugins, I want to go ahead and automatically configure that project to
have all the IvyDE goodness, (nature, container, pre-resolve the container,
deployment assembly configuration). In order to test things out I forked
the latest trunk on git hub and imported it into my Eclipse SDK dev
environment. I then went and built a POC for integration of Liferay plugin
projects enhanced with IvyDE settings. During this process I noticed that
for our use-cases it seems it will require a few change to IvyDE to support
what we want to do:
1. MANIFEST.MF on the eclipse plugin bundle to export all packages (so
they can be called from 3rd-party plugins like ours)
2. Improved support in ResolvedPath.java class to support relative paths
that use the "../" parent path.
You can see that I have forked the IvyDE repo over on my github account and
made a few commits:
https://github.com/gamerson/ivyde/commits/liferay-ide
Several of those commits are just my hacks in order to build the POC in my
dev environment, e.g. setting up a tycho build instead of ant-based build.
The only two interesting commits are the following:
Modified the Manifest to export all *eclipse* packages
https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
Modified ResolvedPath to add support for "../.." style paths:
https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
I'd like to discuss with IvyDE maintainers on how I can get these two
changes merged into trunk. I can create JIRA tickets and submit proper
pull requests, or however, you would prefer me to try to contribute.
Hope to hear from you all soon and thanks again for the great IvyDE!
--
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
Re: Configuring the Ivy classpath container (was: IvyDE adopter use-cases)
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Since we already have $ivyproject_loc, having $ivyproject_name which is quite similar is not much of a worry to me.
Nicolas
Le 3 juil. 2013 à 11:51, Greg Amerson <gr...@liferay.com> a écrit :
> Oops! I just noticed that the ivy container path already contains the
> project name, via the first argument, ?project="" so I guess I encode the
> project name in my own variable it isn't going to be making the situation
> worse.
>
>
> On Wed, Jul 3, 2013 at 5:43 PM, Greg Amerson <gr...@liferay.com>wrote:
>
>> Hey Nicolas,
>>
>> I noticed that, unfortunately all liferay plugin projects are not
>> physically nested under the workspace location but rather they have custom
>> locations. So even though they are IProjects their locations are never
>> children of workspace root. So unfortunately doesn't work. However, if
>> there was another hack in there, one for the current IProject name, that
>> would be nice :)
>>
>> ${sdk_dir:${ivyproject_name}}
>>
>> even though that isn't a valid use of eclipse dynamic variables, if the
>> ResolvedPath would do another search and replace using the
>> IProject.getName(), that would work for me. Then I can use the current
>> project name as an argument into my own "sdk_dir" variable that I can
>> contribute via my own Eclipse plugin.
>>
>> What do you think? Can you add one more hacky variable to ResolvedPath?
>>
>>
>> On Wed, Jul 3, 2013 at 5:31 PM, Nicolas Lalevée <
>> nicolas.lalevee@hibnet.org> wrote:
>>
>>>
>>> Le 3 juil. 2013 à 11:21, Greg Amerson <gr...@liferay.com> a
>>> écrit :
>>>
>>>> Hey Nicolas,
>>>>
>>>> Thanks for the update regarding containers. Regarding the ResolvedPath,
>>>> for me to get my relative paths to work I guess I have two options:
>>>>
>>>> 1 - You would accept a patch from me to ResolvedPath to get "../../"
>>> style
>>>> URI's to work
>>>> 2 - I can implement a new dynamic variable something like
>>>> "${liferay_sdk_dir:ivy-project-name}/ivy-settings.xml" The only bad
>>> thing
>>>> about this is that I have to encode the project name into the classpath
>>>> container, so if the user changes the project name, the container will
>>> fail
>>>> to load. Of course I could add a rename refactoring participant, but I
>>>> guess it would still be broken if user manually changes the project
>>> name (
>>>> editing .project file ).
>>>>
>>>> Personally I would prefer option #1 :) but if that isn't doable, I can
>>> go
>>>> with #2.
>>>
>>> Have you tried ${ivyproject_loc} ? It is a kind of variable (quite hacky
>>> since it is not a real Eclipse variable) which got replaced by
>>> ${workspace_loc:projectName}. See the first lines of
>>> org.apache.ivyde.eclipse.ResolvedPath#resolvePath()
>>>
>>> Nicolas
>>>
>>>
>>>>
>>>> Greg
>>>>
>>>>
>>>> On Wed, Jul 3, 2013 at 5:07 PM, Nicolas Lalevée
>>>> <ni...@hibnet.org>wrote:
>>>>
>>>>>
>>>>> Le 3 juil. 2013 à 10:42, Carsten.Pfeiffer@gebit.de a écrit :
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> the configuration of the Ivy classpath container is indeed the only
>>>>>> problematic thing here.
>>>>>> You would have to ask the Ivy developers (I'm just a mere user)
>>> whether
>>>>>> these options
>>>>>> are considered stable. It's also a bit ugly to handcraft the string
>>> with
>>>>>> these options.
>>>>>
>>>>> They definitevly can be considered stable API. And they are already
>>> been
>>>>> kept backward compatible. Because these IDs are serialized in the
>>>>> .classpath, so they are spread all over in the IvyDE user's
>>> environments.
>>>>> If we break anything there, we would break user's existing classpaths.
>>>>>
>>>>>
>>>>>> Also maintenance of the ivy classpath container settings is a little
>>>>>> uncomfortable. Adjusting
>>>>>> the container settings for a few projects is not a problem, but if you
>>>>>> have hundreds of them,
>>>>>> you have to search&replace the query-style options with regular
>>>>>> expressions in all .classpath files
>>>>>> and then hope that all the resulting options are still valid.
>>>>>
>>>>> I think it won't hurt if we expose IvyClasspathContainerConfiguration
>>>>>
>>>>>
>>>>>> Maybe it would be easier to have some kind of ivy.xml.properties file
>>> or
>>>>>> something similar that can be
>>>>>> specified as the only option for an ivy classpath container. The
>>>>>> properties file would contain the options
>>>>>> that are currently specified in the .classpath file itself. This would
>>>>>> even allow sharing of the properties
>>>>>> among multiple projects.
>>>>>
>>>>> Indeed, if you look in your .classpath, you'll see an xml encoded
>>>>> query-string encoded path. I have tried several time to make the
>>> classpath
>>>>> entry path more human friendly, but each time things got unstable.
>>>>> The JDT is building the classpath independently of the "building" of
>>> the
>>>>> workspace files. So when Eclipse is starting up, the IvyDE classpath
>>>>> container is asked to be configured, whereas the files may not be yet
>>>>> accessible.
>>>>> Here is an exemple of related issue:
>>>>> https://issues.apache.org/jira/browse/IVYDE-302
>>>>> For this issue this is not dramatic, because it is about the resolve
>>> which
>>>>> is asynchronous and can be relaunch later. But configuring the
>>> classpath
>>>>> container need to be done as required by the JDT, otherwise it won't
>>> show
>>>>> properly.
>>>>>
>>>>>
>>>>> Nicolas
>>>>>
>>>>>>
>>>>>> Cheers
>>>>>> Carsten
>>>>>>
>>>>>>
>>>>>>
>>>>>> Von: Greg Amerson <gr...@liferay.com>
>>>>>> An: Ant Developers List <de...@ant.apache.org>
>>>>>> Datum: 03.07.2013 10:20
>>>>>> Betreff: Re: Re: Re: IvyDE adopter use-cases
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hey Carsten,
>>>>>>
>>>>>> On Wed, Jul 3, 2013 at 3:53 PM, <Ca...@gebit.de> wrote:
>>>>>>
>>>>>>> Hi Greg,
>>>>>>>
>>>>>>> nature and container IDs should be as stable as an API, so it should
>>> not
>>>>>>> be a problem to rely on them.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Sure I can use them just as IDs. If they changed it would be hard to
>>> use
>>>>>> them for existing projects :).
>>>>>>
>>>>>> What about the variables query-style options that are used in the
>>>>>> container
>>>>>> path ? Can those be considered API as well? So I could avoid using
>>> the
>>>>>> Configuration object as API?
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> There's also a command org.apache.ivyde.commands.resolve, which can
>>> be
>>>>>>> parameterized with the
>>>>>>> project you to be resolved. Not sure if you can resolve a single
>>> ivy.xml
>>>>>>> (in case a project has multiple).
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Resolving a single project is just fine, that is exactly the use-case
>>> I'm
>>>>>> using, when creating a new project.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I don't know your exact problem with ResolvedPath, but you can also
>>>>>>> specify your ivysettings.xml
>>>>>>> relative to a system property, environment variable, a project
>>> location,
>>>>>>> workspace, ...
>>>>>>>
>>>>>>
>>>>>>
>>>>>> So in my case I need to use a path that is relative to the project
>>>>>> location, but its relative as in two parent directories higher. So I
>>>>> need
>>>>>> something like this ${project_loc}/../../ivy-settings.xml But this
>>>>>> doesn't
>>>>>> seem to work right now. I'm looking into implementing my own
>>> ${sdk_dir}
>>>>>> that would map to the correct parent directory and maybe the relative
>>>>> path
>>>>>> support wouldn't be required in ResolvedPath. I'll let you know.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers
>>>>>>> Carsten
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Von: Greg Amerson <gr...@liferay.com>
>>>>>>> An: Ant Developers List <de...@ant.apache.org>
>>>>>>> Datum: 03.07.2013 05:04
>>>>>>> Betreff: Re: Re: IvyDE adopter use-cases
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hey Carsten,
>>>>>>>
>>>>>>> Thanks for those pointers, that is good to consider, especially for
>>> the
>>>>>>> nature and the container. The resolveall is a bit much but would
>>> rather
>>>>>>> just resolve that single ivy.xml file. I'm sure there is a way to
>>> pass
>>>>>>> that to an existing handler so it only resolves one.
>>>>>>>
>>>>>>> But in general, me hard coding natureIds and container IDs is as
>>> brittle
>>>>>>> as
>>>>>>> calling an API, so I would prefer a real API that I could call. But
>>>>>> until
>>>>>>> that is settled what the API should look like, this method would
>>> work.
>>>>>>>
>>>>>>> That only leaves the ResolvedPath changes. I can try to submit a
>>> patch
>>>>>>> and
>>>>>>> test project to import ResolvedPath support for parent directory
>>>>>> relative
>>>>>>> paths.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
>>>>>>>
>>>>>>>> Hi Greg,
>>>>>>>>
>>>>>>>> most of what you do with the IvyDE API can be done without the IvyDE
>>>>>>> API.
>>>>>>>>
>>>>>>>> 1. You can easily add the nature by using IProject.setDescription()
>>>>>> and
>>>>>>>> providing the Ivy nature ID as a string.
>>>>>>>> 2. You can add the Ivy classpath container to a project's classpath
>>>>>> with
>>>>>>>> JavaCore.newContainerEntry(
>>>>>>>> "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
>>>>>>>> and adding that via IProject.setRawClasspath(). Adding your
>>>>>> specific
>>>>>>>> options of the container is a little
>>>>>>>> problematic though, I agree. You would have to add all those in
>>>>>> the
>>>>>>>> right syntax to the container string.
>>>>>>>> 3. You can invoke the resolving e.g. by calling ICommandService.
>>>>>>>> getCommand("org.apache.ivyde.commands.resolveall")
>>>>>>>> and invoking the execute() method on the command's handler.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Carsten
>>>>>>>>
>>>>>>>>
>>>>>>>> Von: Greg Amerson <gr...@liferay.com>
>>>>>>>> An: Ant Developers List <de...@ant.apache.org>
>>>>>>>> Datum: 02.07.2013 16:24
>>>>>>>> Betreff: Re: IvyDE adopter use-cases
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hey Nicolas,
>>>>>>>>
>>>>>>>> Answers inline:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
>>>>>>>> <ni...@hibnet.org>wrote:
>>>>>>>>
>>>>>>>>> Hi Greg,
>>>>>>>>>
>>>>>>>>> Le 2 juil. 2013 à 12:16, Greg Amerson <gregory.amerson@liferay.com
>>>>
>>>>>> a
>>>>>>>>> écrit :
>>>>>>>>>
>>>>>>>>>> Hello IvyDE developers,
>>>>>>>>>>
>>>>>>>>>> My name is Greg Amerson and I am the project lead for Liferay IDE,
>>>>>>>> which
>>>>>>>>> is
>>>>>>>>>> a set of Eclipse plugins for Liferay development. In an upcoming
>>>>>>>> version
>>>>>>>>>> of Liferay Portal, we have integrated the use of Ivy dependency
>>>>>>>>> management
>>>>>>>>>> for plugin projects, e.g. liferay plugins (fancy j2ee web
>>>>>> projects)
>>>>>>>> that
>>>>>>>>>> are built using JSF portlets now use Ivy to manage jsf
>>>>>> dependencies.
>>>>>>>>>>
>>>>>>>>>> Therefore in Liferay IDE when our users create Liferay plugin
>>>>>>>> projects,
>>>>>>>>> we
>>>>>>>>>> want users to be able to take advantage of the good support in
>>>>>> IvyDE
>>>>>>>> for
>>>>>>>>>> dependency management, namely the Ivy classpath container. So for
>>>>>>> new
>>>>>>>>>> Liferay projects that are created by our "New Liferay Project
>>>>>>> wizard"
>>>>>>>> in
>>>>>>>>>> our plugins, I want to go ahead and automatically configure that
>>>>>>>> project
>>>>>>>>> to
>>>>>>>>>> have all the IvyDE goodness, (nature, container, pre-resolve the
>>>>>>>>> container,
>>>>>>>>>> deployment assembly configuration). In order to test things out I
>>>>>>>> forked
>>>>>>>>>> the latest trunk on git hub and imported it into my Eclipse SDK
>>>>>> dev
>>>>>>>>>> environment. I then went and built a POC for integration of
>>>>>> Liferay
>>>>>>>>> plugin
>>>>>>>>>> projects enhanced with IvyDE settings. During this process I
>>>>>>> noticed
>>>>>>>>> that
>>>>>>>>>> for our use-cases it seems it will require a few change to IvyDE
>>>>>> to
>>>>>>>>> support
>>>>>>>>>> what we want to do:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 1. MANIFEST.MF on the eclipse plugin bundle to export all
>>>>>> packages
>>>>>>>> (so
>>>>>>>>>> they can be called from 3rd-party plugins like ours)
>>>>>>>>>
>>>>>>>>> The API of IvyDE was never properly maintained. Adding new features
>>>>>> or
>>>>>>>>> fixing bugs often involved changing/adding/removing some classes or
>>>>>>>>> methods. I fear that if you rely blindly on the IvyDE "API", we may
>>>>>>>> break
>>>>>>>>> your plugin in the long run.
>>>>>>>>> Maybe with your input we can start building a real API. Only the
>>>>>>> useful
>>>>>>>>> package would be exposed. Only the useful classes. And then we will
>>>>>>> make
>>>>>>>>> sure that IvyDE won't break the API of these classes.
>>>>>>>>> We could start with the list of classes of IvyDE you are actually
>>>>>>> using.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That makes total sense. However, I feel that you should follow the
>>>>>> same
>>>>>>>> pattern as Eclipse team itself. Put an API division between API and
>>>>>>>> "internal" classes by putting "internal" in package path, but still
>>>>>> you
>>>>>>>> can
>>>>>>>> export everything. Because in many cases you can't fully know how
>>>>>>>> adopters
>>>>>>>> will use the plugin and you wouldn't want to prohibit the use of it
>>>>>> out
>>>>>>> of
>>>>>>>> the box just because the packages were exported people end up having
>>>>>> to
>>>>>>>> fork the project just to use it for a specific release. If all
>>>>>> packages
>>>>>>>> were exported but some marked internal then those programmers will
>>>>>> have
>>>>>>>> already been warned by eclipse and if they choose to ignore it, it
>>> is
>>>>>> on
>>>>>>>> them if the API breaks in the future. This way we can have best of
>>>>>> both
>>>>>>>> worlds. :)
>>>>>>>>
>>>>>>>>
>>>>>>>> But regardless, currently in my first integration attempt I'm using
>>>>>> the
>>>>>>>> following classes:
>>>>>>>>
>>>>>>>> org.apache.ivyde.eclipse.IvyNature
>>>>>>>> org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
>>>>>>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
>>>>>>>>
>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
>>>>>>>>
>>>>>>
>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
>>>>>>>> org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
>>>>>>>> org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
>>>>>>>>
>>>>>>>> Here is the code where you can see I'm calling the ivy classes:
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Right now that code is all messy and just a POC. But you can see
>>> that
>>>>>>> I'm
>>>>>>>> doing 3 things:
>>>>>>>> -adding ivy nature
>>>>>>>> -adding ivy classpath container
>>>>>>>> -running "resolve" on classpath container
>>>>>>>>
>>>>>>>>
>>>>>>>>>> 2. Improved support in ResolvedPath.java class to support
>>>>>> relative
>>>>>>>>> paths
>>>>>>>>>> that use the "../" parent path.
>>>>>>>>>
>>>>>>>>> The problem with relative paths is that they got messed up while
>>>>>> being
>>>>>>>>> used within the java launcher. Maybe you can share your use case so
>>>>>> we
>>>>>>>> can
>>>>>>>>> figure out a proper way to solve it ? For instance it would be nice
>>>>>> if
>>>>>>>> you
>>>>>>>>> could provide a patch which is adding a test project [1].
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sure thing, I can add a test project. In my scenario with Liferay
>>>>>> IDE,
>>>>>>>> all
>>>>>>>> of our Ivy Projects will live in a parent folder structure that will
>>>>>>>> contain some shared Ivy configuration settings and also a shared ivy
>>>>>>>> cache. So when I configure the Ivy container, I need to use
>>> relative
>>>>>>>> paths
>>>>>>>> for the IvySettings file and the IvyUserDir like this:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> something like this for settings file
>>>>>>>> file:../../ivy-settings.xml
>>>>>>>>
>>>>>>>> and this for user dir
>>>>>>>> ../../.ivy
>>>>>>>>
>>>>>>>> So with my modification to ResolvedPath below it fixes it for that
>>>>>>> issue,
>>>>>>>> although that code would need to be cleaned up before I submited the
>>>>>>> patch
>>>>>>>> :)
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>> https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> You can see that I have forked the IvyDE repo over on my github
>>>>>>>> account
>>>>>>>>> and
>>>>>>>>>> made a few commits:
>>>>>>>>>> https://github.com/gamerson/ivyde/commits/liferay-ide
>>>>>>>>>>
>>>>>>>>>> Several of those commits are just my hacks in order to build the
>>>>>> POC
>>>>>>>> in
>>>>>>>>> my
>>>>>>>>>> dev environment, e.g. setting up a tycho build instead of
>>>>>> ant-based
>>>>>>>>> build.
>>>>>>>>>> The only two interesting commits are the following:
>>>>>>>>>>
>>>>>>>>>> Modified the Manifest to export all *eclipse* packages
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Modified ResolvedPath to add support for "../.." style paths:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'd like to discuss with IvyDE maintainers on how I can get these
>>>>>>> two
>>>>>>>>>> changes merged into trunk. I can create JIRA tickets and submit
>>>>>>>> proper
>>>>>>>>>> pull requests, or however, you would prefer me to try to
>>>>>> contribute.
>>>>>>>>>
>>>>>>>>> The way to contribute code is to go through Jira. So it somehow
>>>>>>> clearly
>>>>>>>>> state that you do want to contribute your patch to the ASF, and we
>>>>>> are
>>>>>>>> not
>>>>>>>>> picking code from you with an unclear license. (You could probably
>>>>>> do
>>>>>>> a
>>>>>>>>> pull request, but I don't know where it would actually go…)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sure thing, I'll open JIRA ticket with the API export and the
>>>>>>> ResolvedPath
>>>>>>>> as those are the two blockers right now.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hope to hear from you all soon and thanks again for the great
>>>>>> IvyDE!
>>>>>>>>>
>>>>>>>>> Thank you for coming here discussing here ! :)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Absolutely! and thanks for responding so quickly.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>> [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Greg Amerson
>>>>>>> Liferay Developer Tools
>>>>>>> Liferay, Inc. www.liferay.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>
>>>
>>
>>
>> --
>> Greg Amerson
>> Liferay Developer Tools
>> Liferay, Inc. www.liferay.com
>>
>
>
>
> --
> 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
Re: Configuring the Ivy classpath container (was: IvyDE adopter use-cases)
Posted by Greg Amerson <gr...@liferay.com>.
Oops! I just noticed that the ivy container path already contains the
project name, via the first argument, ?project="" so I guess I encode the
project name in my own variable it isn't going to be making the situation
worse.
On Wed, Jul 3, 2013 at 5:43 PM, Greg Amerson <gr...@liferay.com>wrote:
> Hey Nicolas,
>
> I noticed that, unfortunately all liferay plugin projects are not
> physically nested under the workspace location but rather they have custom
> locations. So even though they are IProjects their locations are never
> children of workspace root. So unfortunately doesn't work. However, if
> there was another hack in there, one for the current IProject name, that
> would be nice :)
>
> ${sdk_dir:${ivyproject_name}}
>
> even though that isn't a valid use of eclipse dynamic variables, if the
> ResolvedPath would do another search and replace using the
> IProject.getName(), that would work for me. Then I can use the current
> project name as an argument into my own "sdk_dir" variable that I can
> contribute via my own Eclipse plugin.
>
> What do you think? Can you add one more hacky variable to ResolvedPath?
>
>
> On Wed, Jul 3, 2013 at 5:31 PM, Nicolas Lalevée <
> nicolas.lalevee@hibnet.org> wrote:
>
>>
>> Le 3 juil. 2013 à 11:21, Greg Amerson <gr...@liferay.com> a
>> écrit :
>>
>> > Hey Nicolas,
>> >
>> > Thanks for the update regarding containers. Regarding the ResolvedPath,
>> > for me to get my relative paths to work I guess I have two options:
>> >
>> > 1 - You would accept a patch from me to ResolvedPath to get "../../"
>> style
>> > URI's to work
>> > 2 - I can implement a new dynamic variable something like
>> > "${liferay_sdk_dir:ivy-project-name}/ivy-settings.xml" The only bad
>> thing
>> > about this is that I have to encode the project name into the classpath
>> > container, so if the user changes the project name, the container will
>> fail
>> > to load. Of course I could add a rename refactoring participant, but I
>> > guess it would still be broken if user manually changes the project
>> name (
>> > editing .project file ).
>> >
>> > Personally I would prefer option #1 :) but if that isn't doable, I can
>> go
>> > with #2.
>>
>> Have you tried ${ivyproject_loc} ? It is a kind of variable (quite hacky
>> since it is not a real Eclipse variable) which got replaced by
>> ${workspace_loc:projectName}. See the first lines of
>> org.apache.ivyde.eclipse.ResolvedPath#resolvePath()
>>
>> Nicolas
>>
>>
>> >
>> > Greg
>> >
>> >
>> > On Wed, Jul 3, 2013 at 5:07 PM, Nicolas Lalevée
>> > <ni...@hibnet.org>wrote:
>> >
>> >>
>> >> Le 3 juil. 2013 à 10:42, Carsten.Pfeiffer@gebit.de a écrit :
>> >>
>> >>> Hi Greg,
>> >>>
>> >>> the configuration of the Ivy classpath container is indeed the only
>> >>> problematic thing here.
>> >>> You would have to ask the Ivy developers (I'm just a mere user)
>> whether
>> >>> these options
>> >>> are considered stable. It's also a bit ugly to handcraft the string
>> with
>> >>> these options.
>> >>
>> >> They definitevly can be considered stable API. And they are already
>> been
>> >> kept backward compatible. Because these IDs are serialized in the
>> >> .classpath, so they are spread all over in the IvyDE user's
>> environments.
>> >> If we break anything there, we would break user's existing classpaths.
>> >>
>> >>
>> >>> Also maintenance of the ivy classpath container settings is a little
>> >>> uncomfortable. Adjusting
>> >>> the container settings for a few projects is not a problem, but if you
>> >>> have hundreds of them,
>> >>> you have to search&replace the query-style options with regular
>> >>> expressions in all .classpath files
>> >>> and then hope that all the resulting options are still valid.
>> >>
>> >> I think it won't hurt if we expose IvyClasspathContainerConfiguration
>> >>
>> >>
>> >>> Maybe it would be easier to have some kind of ivy.xml.properties file
>> or
>> >>> something similar that can be
>> >>> specified as the only option for an ivy classpath container. The
>> >>> properties file would contain the options
>> >>> that are currently specified in the .classpath file itself. This would
>> >>> even allow sharing of the properties
>> >>> among multiple projects.
>> >>
>> >> Indeed, if you look in your .classpath, you'll see an xml encoded
>> >> query-string encoded path. I have tried several time to make the
>> classpath
>> >> entry path more human friendly, but each time things got unstable.
>> >> The JDT is building the classpath independently of the "building" of
>> the
>> >> workspace files. So when Eclipse is starting up, the IvyDE classpath
>> >> container is asked to be configured, whereas the files may not be yet
>> >> accessible.
>> >> Here is an exemple of related issue:
>> >> https://issues.apache.org/jira/browse/IVYDE-302
>> >> For this issue this is not dramatic, because it is about the resolve
>> which
>> >> is asynchronous and can be relaunch later. But configuring the
>> classpath
>> >> container need to be done as required by the JDT, otherwise it won't
>> show
>> >> properly.
>> >>
>> >>
>> >> Nicolas
>> >>
>> >>>
>> >>> Cheers
>> >>> Carsten
>> >>>
>> >>>
>> >>>
>> >>> Von: Greg Amerson <gr...@liferay.com>
>> >>> An: Ant Developers List <de...@ant.apache.org>
>> >>> Datum: 03.07.2013 10:20
>> >>> Betreff: Re: Re: Re: IvyDE adopter use-cases
>> >>>
>> >>>
>> >>>
>> >>> Hey Carsten,
>> >>>
>> >>> On Wed, Jul 3, 2013 at 3:53 PM, <Ca...@gebit.de> wrote:
>> >>>
>> >>>> Hi Greg,
>> >>>>
>> >>>> nature and container IDs should be as stable as an API, so it should
>> not
>> >>>> be a problem to rely on them.
>> >>>>
>> >>>
>> >>>
>> >>> Sure I can use them just as IDs. If they changed it would be hard to
>> use
>> >>> them for existing projects :).
>> >>>
>> >>> What about the variables query-style options that are used in the
>> >>> container
>> >>> path ? Can those be considered API as well? So I could avoid using
>> the
>> >>> Configuration object as API?
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> There's also a command org.apache.ivyde.commands.resolve, which can
>> be
>> >>>> parameterized with the
>> >>>> project you to be resolved. Not sure if you can resolve a single
>> ivy.xml
>> >>>> (in case a project has multiple).
>> >>>>
>> >>>
>> >>>
>> >>> Resolving a single project is just fine, that is exactly the use-case
>> I'm
>> >>> using, when creating a new project.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> I don't know your exact problem with ResolvedPath, but you can also
>> >>>> specify your ivysettings.xml
>> >>>> relative to a system property, environment variable, a project
>> location,
>> >>>> workspace, ...
>> >>>>
>> >>>
>> >>>
>> >>> So in my case I need to use a path that is relative to the project
>> >>> location, but its relative as in two parent directories higher. So I
>> >> need
>> >>> something like this ${project_loc}/../../ivy-settings.xml But this
>> >>> doesn't
>> >>> seem to work right now. I'm looking into implementing my own
>> ${sdk_dir}
>> >>> that would map to the correct parent directory and maybe the relative
>> >> path
>> >>> support wouldn't be required in ResolvedPath. I'll let you know.
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> Cheers
>> >>>> Carsten
>> >>>>
>> >>>>
>> >>>>
>> >>>> Von: Greg Amerson <gr...@liferay.com>
>> >>>> An: Ant Developers List <de...@ant.apache.org>
>> >>>> Datum: 03.07.2013 05:04
>> >>>> Betreff: Re: Re: IvyDE adopter use-cases
>> >>>>
>> >>>>
>> >>>>
>> >>>> Hey Carsten,
>> >>>>
>> >>>> Thanks for those pointers, that is good to consider, especially for
>> the
>> >>>> nature and the container. The resolveall is a bit much but would
>> rather
>> >>>> just resolve that single ivy.xml file. I'm sure there is a way to
>> pass
>> >>>> that to an existing handler so it only resolves one.
>> >>>>
>> >>>> But in general, me hard coding natureIds and container IDs is as
>> brittle
>> >>>> as
>> >>>> calling an API, so I would prefer a real API that I could call. But
>> >>> until
>> >>>> that is settled what the API should look like, this method would
>> work.
>> >>>>
>> >>>> That only leaves the ResolvedPath changes. I can try to submit a
>> patch
>> >>>> and
>> >>>> test project to import ResolvedPath support for parent directory
>> >>> relative
>> >>>> paths.
>> >>>>
>> >>>>
>> >>>> On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
>> >>>>
>> >>>>> Hi Greg,
>> >>>>>
>> >>>>> most of what you do with the IvyDE API can be done without the IvyDE
>> >>>> API.
>> >>>>>
>> >>>>> 1. You can easily add the nature by using IProject.setDescription()
>> >>> and
>> >>>>> providing the Ivy nature ID as a string.
>> >>>>> 2. You can add the Ivy classpath container to a project's classpath
>> >>> with
>> >>>>> JavaCore.newContainerEntry(
>> >>>>> "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
>> >>>>> and adding that via IProject.setRawClasspath(). Adding your
>> >>> specific
>> >>>>> options of the container is a little
>> >>>>> problematic though, I agree. You would have to add all those in
>> >>> the
>> >>>>> right syntax to the container string.
>> >>>>> 3. You can invoke the resolving e.g. by calling ICommandService.
>> >>>>> getCommand("org.apache.ivyde.commands.resolveall")
>> >>>>> and invoking the execute() method on the command's handler.
>> >>>>>
>> >>>>> Cheers
>> >>>>> Carsten
>> >>>>>
>> >>>>>
>> >>>>> Von: Greg Amerson <gr...@liferay.com>
>> >>>>> An: Ant Developers List <de...@ant.apache.org>
>> >>>>> Datum: 02.07.2013 16:24
>> >>>>> Betreff: Re: IvyDE adopter use-cases
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Hey Nicolas,
>> >>>>>
>> >>>>> Answers inline:
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
>> >>>>> <ni...@hibnet.org>wrote:
>> >>>>>
>> >>>>>> Hi Greg,
>> >>>>>>
>> >>>>>> Le 2 juil. 2013 à 12:16, Greg Amerson <gregory.amerson@liferay.com
>> >
>> >>> a
>> >>>>>> écrit :
>> >>>>>>
>> >>>>>>> Hello IvyDE developers,
>> >>>>>>>
>> >>>>>>> My name is Greg Amerson and I am the project lead for Liferay IDE,
>> >>>>> which
>> >>>>>> is
>> >>>>>>> a set of Eclipse plugins for Liferay development. In an upcoming
>> >>>>> version
>> >>>>>>> of Liferay Portal, we have integrated the use of Ivy dependency
>> >>>>>> management
>> >>>>>>> for plugin projects, e.g. liferay plugins (fancy j2ee web
>> >>> projects)
>> >>>>> that
>> >>>>>>> are built using JSF portlets now use Ivy to manage jsf
>> >>> dependencies.
>> >>>>>>>
>> >>>>>>> Therefore in Liferay IDE when our users create Liferay plugin
>> >>>>> projects,
>> >>>>>> we
>> >>>>>>> want users to be able to take advantage of the good support in
>> >>> IvyDE
>> >>>>> for
>> >>>>>>> dependency management, namely the Ivy classpath container. So for
>> >>>> new
>> >>>>>>> Liferay projects that are created by our "New Liferay Project
>> >>>> wizard"
>> >>>>> in
>> >>>>>>> our plugins, I want to go ahead and automatically configure that
>> >>>>> project
>> >>>>>> to
>> >>>>>>> have all the IvyDE goodness, (nature, container, pre-resolve the
>> >>>>>> container,
>> >>>>>>> deployment assembly configuration). In order to test things out I
>> >>>>> forked
>> >>>>>>> the latest trunk on git hub and imported it into my Eclipse SDK
>> >>> dev
>> >>>>>>> environment. I then went and built a POC for integration of
>> >>> Liferay
>> >>>>>> plugin
>> >>>>>>> projects enhanced with IvyDE settings. During this process I
>> >>>> noticed
>> >>>>>> that
>> >>>>>>> for our use-cases it seems it will require a few change to IvyDE
>> >>> to
>> >>>>>> support
>> >>>>>>> what we want to do:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 1. MANIFEST.MF on the eclipse plugin bundle to export all
>> >>> packages
>> >>>>> (so
>> >>>>>>> they can be called from 3rd-party plugins like ours)
>> >>>>>>
>> >>>>>> The API of IvyDE was never properly maintained. Adding new features
>> >>> or
>> >>>>>> fixing bugs often involved changing/adding/removing some classes or
>> >>>>>> methods. I fear that if you rely blindly on the IvyDE "API", we may
>> >>>>> break
>> >>>>>> your plugin in the long run.
>> >>>>>> Maybe with your input we can start building a real API. Only the
>> >>>> useful
>> >>>>>> package would be exposed. Only the useful classes. And then we will
>> >>>> make
>> >>>>>> sure that IvyDE won't break the API of these classes.
>> >>>>>> We could start with the list of classes of IvyDE you are actually
>> >>>> using.
>> >>>>>>
>> >>>>>
>> >>>>> That makes total sense. However, I feel that you should follow the
>> >>> same
>> >>>>> pattern as Eclipse team itself. Put an API division between API and
>> >>>>> "internal" classes by putting "internal" in package path, but still
>> >>> you
>> >>>>> can
>> >>>>> export everything. Because in many cases you can't fully know how
>> >>>>> adopters
>> >>>>> will use the plugin and you wouldn't want to prohibit the use of it
>> >>> out
>> >>>> of
>> >>>>> the box just because the packages were exported people end up having
>> >>> to
>> >>>>> fork the project just to use it for a specific release. If all
>> >>> packages
>> >>>>> were exported but some marked internal then those programmers will
>> >>> have
>> >>>>> already been warned by eclipse and if they choose to ignore it, it
>> is
>> >>> on
>> >>>>> them if the API breaks in the future. This way we can have best of
>> >>> both
>> >>>>> worlds. :)
>> >>>>>
>> >>>>>
>> >>>>> But regardless, currently in my first integration attempt I'm using
>> >>> the
>> >>>>> following classes:
>> >>>>>
>> >>>>> org.apache.ivyde.eclipse.IvyNature
>> >>>>> org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
>> >>>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
>> >>>>>
>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
>> >>>>>
>> >>>
>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
>> >>>>> org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
>> >>>>> org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
>> >>>>>
>> >>>>> Here is the code where you can see I'm calling the ivy classes:
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
>> >>>
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> Right now that code is all messy and just a POC. But you can see
>> that
>> >>>> I'm
>> >>>>> doing 3 things:
>> >>>>> -adding ivy nature
>> >>>>> -adding ivy classpath container
>> >>>>> -running "resolve" on classpath container
>> >>>>>
>> >>>>>
>> >>>>>>> 2. Improved support in ResolvedPath.java class to support
>> >>> relative
>> >>>>>> paths
>> >>>>>>> that use the "../" parent path.
>> >>>>>>
>> >>>>>> The problem with relative paths is that they got messed up while
>> >>> being
>> >>>>>> used within the java launcher. Maybe you can share your use case so
>> >>> we
>> >>>>> can
>> >>>>>> figure out a proper way to solve it ? For instance it would be nice
>> >>> if
>> >>>>> you
>> >>>>>> could provide a patch which is adding a test project [1].
>> >>>>>>
>> >>>>>
>> >>>>> Sure thing, I can add a test project. In my scenario with Liferay
>> >>> IDE,
>> >>>>> all
>> >>>>> of our Ivy Projects will live in a parent folder structure that will
>> >>>>> contain some shared Ivy configuration settings and also a shared ivy
>> >>>>> cache. So when I configure the Ivy container, I need to use
>> relative
>> >>>>> paths
>> >>>>> for the IvySettings file and the IvyUserDir like this:
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
>> >>>
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> something like this for settings file
>> >>>>> file:../../ivy-settings.xml
>> >>>>>
>> >>>>> and this for user dir
>> >>>>> ../../.ivy
>> >>>>>
>> >>>>> So with my modification to ResolvedPath below it fixes it for that
>> >>>> issue,
>> >>>>> although that code would need to be cleaned up before I submited the
>> >>>> patch
>> >>>>> :)
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>> >>>
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> You can see that I have forked the IvyDE repo over on my github
>> >>>>> account
>> >>>>>> and
>> >>>>>>> made a few commits:
>> >>>>>>> https://github.com/gamerson/ivyde/commits/liferay-ide
>> >>>>>>>
>> >>>>>>> Several of those commits are just my hacks in order to build the
>> >>> POC
>> >>>>> in
>> >>>>>> my
>> >>>>>>> dev environment, e.g. setting up a tycho build instead of
>> >>> ant-based
>> >>>>>> build.
>> >>>>>>> The only two interesting commits are the following:
>> >>>>>>>
>> >>>>>>> Modified the Manifest to export all *eclipse* packages
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
>> >>>
>> >>>>
>> >>>>>
>> >>>>>>>
>> >>>>>>> Modified ResolvedPath to add support for "../.." style paths:
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
>> >>>
>> >>>>
>> >>>>>
>> >>>>>>>
>> >>>>>>> I'd like to discuss with IvyDE maintainers on how I can get these
>> >>>> two
>> >>>>>>> changes merged into trunk. I can create JIRA tickets and submit
>> >>>>> proper
>> >>>>>>> pull requests, or however, you would prefer me to try to
>> >>> contribute.
>> >>>>>>
>> >>>>>> The way to contribute code is to go through Jira. So it somehow
>> >>>> clearly
>> >>>>>> state that you do want to contribute your patch to the ASF, and we
>> >>> are
>> >>>>> not
>> >>>>>> picking code from you with an unclear license. (You could probably
>> >>> do
>> >>>> a
>> >>>>>> pull request, but I don't know where it would actually go…)
>> >>>>>>
>> >>>>>
>> >>>>> Sure thing, I'll open JIRA ticket with the API export and the
>> >>>> ResolvedPath
>> >>>>> as those are the two blockers right now.
>> >>>>>
>> >>>>>
>> >>>>>>
>> >>>>>>> Hope to hear from you all soon and thanks again for the great
>> >>> IvyDE!
>> >>>>>>
>> >>>>>> Thank you for coming here discussing here ! :)
>> >>>>>>
>> >>>>>
>> >>>>> Absolutely! and thanks for responding so quickly.
>> >>>>>
>> >>>>>
>> >>>>>>
>> >>>>>> Nicolas
>> >>>>>>
>> >>>>>> [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>> ---------------------------------------------------------------------
>> >>>>>> 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
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Greg Amerson
>> >>>> Liferay Developer Tools
>> >>>> Liferay, Inc. www.liferay.com
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> 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
>>
>>
>
>
> --
> Greg Amerson
> Liferay Developer Tools
> Liferay, Inc. www.liferay.com
>
--
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
Re: Configuring the Ivy classpath container (was: IvyDE adopter use-cases)
Posted by Greg Amerson <gr...@liferay.com>.
Hey Nicolas,
I noticed that, unfortunately all liferay plugin projects are not
physically nested under the workspace location but rather they have custom
locations. So even though they are IProjects their locations are never
children of workspace root. So unfortunately doesn't work. However, if
there was another hack in there, one for the current IProject name, that
would be nice :)
${sdk_dir:${ivyproject_name}}
even though that isn't a valid use of eclipse dynamic variables, if the
ResolvedPath would do another search and replace using the
IProject.getName(), that would work for me. Then I can use the current
project name as an argument into my own "sdk_dir" variable that I can
contribute via my own Eclipse plugin.
What do you think? Can you add one more hacky variable to ResolvedPath?
On Wed, Jul 3, 2013 at 5:31 PM, Nicolas Lalevée
<ni...@hibnet.org>wrote:
>
> Le 3 juil. 2013 à 11:21, Greg Amerson <gr...@liferay.com> a
> écrit :
>
> > Hey Nicolas,
> >
> > Thanks for the update regarding containers. Regarding the ResolvedPath,
> > for me to get my relative paths to work I guess I have two options:
> >
> > 1 - You would accept a patch from me to ResolvedPath to get "../../"
> style
> > URI's to work
> > 2 - I can implement a new dynamic variable something like
> > "${liferay_sdk_dir:ivy-project-name}/ivy-settings.xml" The only bad
> thing
> > about this is that I have to encode the project name into the classpath
> > container, so if the user changes the project name, the container will
> fail
> > to load. Of course I could add a rename refactoring participant, but I
> > guess it would still be broken if user manually changes the project name
> (
> > editing .project file ).
> >
> > Personally I would prefer option #1 :) but if that isn't doable, I can go
> > with #2.
>
> Have you tried ${ivyproject_loc} ? It is a kind of variable (quite hacky
> since it is not a real Eclipse variable) which got replaced by
> ${workspace_loc:projectName}. See the first lines of
> org.apache.ivyde.eclipse.ResolvedPath#resolvePath()
>
> Nicolas
>
>
> >
> > Greg
> >
> >
> > On Wed, Jul 3, 2013 at 5:07 PM, Nicolas Lalevée
> > <ni...@hibnet.org>wrote:
> >
> >>
> >> Le 3 juil. 2013 à 10:42, Carsten.Pfeiffer@gebit.de a écrit :
> >>
> >>> Hi Greg,
> >>>
> >>> the configuration of the Ivy classpath container is indeed the only
> >>> problematic thing here.
> >>> You would have to ask the Ivy developers (I'm just a mere user) whether
> >>> these options
> >>> are considered stable. It's also a bit ugly to handcraft the string
> with
> >>> these options.
> >>
> >> They definitevly can be considered stable API. And they are already been
> >> kept backward compatible. Because these IDs are serialized in the
> >> .classpath, so they are spread all over in the IvyDE user's
> environments.
> >> If we break anything there, we would break user's existing classpaths.
> >>
> >>
> >>> Also maintenance of the ivy classpath container settings is a little
> >>> uncomfortable. Adjusting
> >>> the container settings for a few projects is not a problem, but if you
> >>> have hundreds of them,
> >>> you have to search&replace the query-style options with regular
> >>> expressions in all .classpath files
> >>> and then hope that all the resulting options are still valid.
> >>
> >> I think it won't hurt if we expose IvyClasspathContainerConfiguration
> >>
> >>
> >>> Maybe it would be easier to have some kind of ivy.xml.properties file
> or
> >>> something similar that can be
> >>> specified as the only option for an ivy classpath container. The
> >>> properties file would contain the options
> >>> that are currently specified in the .classpath file itself. This would
> >>> even allow sharing of the properties
> >>> among multiple projects.
> >>
> >> Indeed, if you look in your .classpath, you'll see an xml encoded
> >> query-string encoded path. I have tried several time to make the
> classpath
> >> entry path more human friendly, but each time things got unstable.
> >> The JDT is building the classpath independently of the "building" of the
> >> workspace files. So when Eclipse is starting up, the IvyDE classpath
> >> container is asked to be configured, whereas the files may not be yet
> >> accessible.
> >> Here is an exemple of related issue:
> >> https://issues.apache.org/jira/browse/IVYDE-302
> >> For this issue this is not dramatic, because it is about the resolve
> which
> >> is asynchronous and can be relaunch later. But configuring the classpath
> >> container need to be done as required by the JDT, otherwise it won't
> show
> >> properly.
> >>
> >>
> >> Nicolas
> >>
> >>>
> >>> Cheers
> >>> Carsten
> >>>
> >>>
> >>>
> >>> Von: Greg Amerson <gr...@liferay.com>
> >>> An: Ant Developers List <de...@ant.apache.org>
> >>> Datum: 03.07.2013 10:20
> >>> Betreff: Re: Re: Re: IvyDE adopter use-cases
> >>>
> >>>
> >>>
> >>> Hey Carsten,
> >>>
> >>> On Wed, Jul 3, 2013 at 3:53 PM, <Ca...@gebit.de> wrote:
> >>>
> >>>> Hi Greg,
> >>>>
> >>>> nature and container IDs should be as stable as an API, so it should
> not
> >>>> be a problem to rely on them.
> >>>>
> >>>
> >>>
> >>> Sure I can use them just as IDs. If they changed it would be hard to
> use
> >>> them for existing projects :).
> >>>
> >>> What about the variables query-style options that are used in the
> >>> container
> >>> path ? Can those be considered API as well? So I could avoid using
> the
> >>> Configuration object as API?
> >>>
> >>>
> >>>
> >>>>
> >>>> There's also a command org.apache.ivyde.commands.resolve, which can be
> >>>> parameterized with the
> >>>> project you to be resolved. Not sure if you can resolve a single
> ivy.xml
> >>>> (in case a project has multiple).
> >>>>
> >>>
> >>>
> >>> Resolving a single project is just fine, that is exactly the use-case
> I'm
> >>> using, when creating a new project.
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> I don't know your exact problem with ResolvedPath, but you can also
> >>>> specify your ivysettings.xml
> >>>> relative to a system property, environment variable, a project
> location,
> >>>> workspace, ...
> >>>>
> >>>
> >>>
> >>> So in my case I need to use a path that is relative to the project
> >>> location, but its relative as in two parent directories higher. So I
> >> need
> >>> something like this ${project_loc}/../../ivy-settings.xml But this
> >>> doesn't
> >>> seem to work right now. I'm looking into implementing my own
> ${sdk_dir}
> >>> that would map to the correct parent directory and maybe the relative
> >> path
> >>> support wouldn't be required in ResolvedPath. I'll let you know.
> >>>
> >>>
> >>>
> >>>>
> >>>> Cheers
> >>>> Carsten
> >>>>
> >>>>
> >>>>
> >>>> Von: Greg Amerson <gr...@liferay.com>
> >>>> An: Ant Developers List <de...@ant.apache.org>
> >>>> Datum: 03.07.2013 05:04
> >>>> Betreff: Re: Re: IvyDE adopter use-cases
> >>>>
> >>>>
> >>>>
> >>>> Hey Carsten,
> >>>>
> >>>> Thanks for those pointers, that is good to consider, especially for
> the
> >>>> nature and the container. The resolveall is a bit much but would
> rather
> >>>> just resolve that single ivy.xml file. I'm sure there is a way to
> pass
> >>>> that to an existing handler so it only resolves one.
> >>>>
> >>>> But in general, me hard coding natureIds and container IDs is as
> brittle
> >>>> as
> >>>> calling an API, so I would prefer a real API that I could call. But
> >>> until
> >>>> that is settled what the API should look like, this method would work.
> >>>>
> >>>> That only leaves the ResolvedPath changes. I can try to submit a
> patch
> >>>> and
> >>>> test project to import ResolvedPath support for parent directory
> >>> relative
> >>>> paths.
> >>>>
> >>>>
> >>>> On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
> >>>>
> >>>>> Hi Greg,
> >>>>>
> >>>>> most of what you do with the IvyDE API can be done without the IvyDE
> >>>> API.
> >>>>>
> >>>>> 1. You can easily add the nature by using IProject.setDescription()
> >>> and
> >>>>> providing the Ivy nature ID as a string.
> >>>>> 2. You can add the Ivy classpath container to a project's classpath
> >>> with
> >>>>> JavaCore.newContainerEntry(
> >>>>> "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
> >>>>> and adding that via IProject.setRawClasspath(). Adding your
> >>> specific
> >>>>> options of the container is a little
> >>>>> problematic though, I agree. You would have to add all those in
> >>> the
> >>>>> right syntax to the container string.
> >>>>> 3. You can invoke the resolving e.g. by calling ICommandService.
> >>>>> getCommand("org.apache.ivyde.commands.resolveall")
> >>>>> and invoking the execute() method on the command's handler.
> >>>>>
> >>>>> Cheers
> >>>>> Carsten
> >>>>>
> >>>>>
> >>>>> Von: Greg Amerson <gr...@liferay.com>
> >>>>> An: Ant Developers List <de...@ant.apache.org>
> >>>>> Datum: 02.07.2013 16:24
> >>>>> Betreff: Re: IvyDE adopter use-cases
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hey Nicolas,
> >>>>>
> >>>>> Answers inline:
> >>>>>
> >>>>>
> >>>>> On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
> >>>>> <ni...@hibnet.org>wrote:
> >>>>>
> >>>>>> Hi Greg,
> >>>>>>
> >>>>>> Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com>
> >>> a
> >>>>>> écrit :
> >>>>>>
> >>>>>>> Hello IvyDE developers,
> >>>>>>>
> >>>>>>> My name is Greg Amerson and I am the project lead for Liferay IDE,
> >>>>> which
> >>>>>> is
> >>>>>>> a set of Eclipse plugins for Liferay development. In an upcoming
> >>>>> version
> >>>>>>> of Liferay Portal, we have integrated the use of Ivy dependency
> >>>>>> management
> >>>>>>> for plugin projects, e.g. liferay plugins (fancy j2ee web
> >>> projects)
> >>>>> that
> >>>>>>> are built using JSF portlets now use Ivy to manage jsf
> >>> dependencies.
> >>>>>>>
> >>>>>>> Therefore in Liferay IDE when our users create Liferay plugin
> >>>>> projects,
> >>>>>> we
> >>>>>>> want users to be able to take advantage of the good support in
> >>> IvyDE
> >>>>> for
> >>>>>>> dependency management, namely the Ivy classpath container. So for
> >>>> new
> >>>>>>> Liferay projects that are created by our "New Liferay Project
> >>>> wizard"
> >>>>> in
> >>>>>>> our plugins, I want to go ahead and automatically configure that
> >>>>> project
> >>>>>> to
> >>>>>>> have all the IvyDE goodness, (nature, container, pre-resolve the
> >>>>>> container,
> >>>>>>> deployment assembly configuration). In order to test things out I
> >>>>> forked
> >>>>>>> the latest trunk on git hub and imported it into my Eclipse SDK
> >>> dev
> >>>>>>> environment. I then went and built a POC for integration of
> >>> Liferay
> >>>>>> plugin
> >>>>>>> projects enhanced with IvyDE settings. During this process I
> >>>> noticed
> >>>>>> that
> >>>>>>> for our use-cases it seems it will require a few change to IvyDE
> >>> to
> >>>>>> support
> >>>>>>> what we want to do:
> >>>>>>>
> >>>>>>>
> >>>>>>> 1. MANIFEST.MF on the eclipse plugin bundle to export all
> >>> packages
> >>>>> (so
> >>>>>>> they can be called from 3rd-party plugins like ours)
> >>>>>>
> >>>>>> The API of IvyDE was never properly maintained. Adding new features
> >>> or
> >>>>>> fixing bugs often involved changing/adding/removing some classes or
> >>>>>> methods. I fear that if you rely blindly on the IvyDE "API", we may
> >>>>> break
> >>>>>> your plugin in the long run.
> >>>>>> Maybe with your input we can start building a real API. Only the
> >>>> useful
> >>>>>> package would be exposed. Only the useful classes. And then we will
> >>>> make
> >>>>>> sure that IvyDE won't break the API of these classes.
> >>>>>> We could start with the list of classes of IvyDE you are actually
> >>>> using.
> >>>>>>
> >>>>>
> >>>>> That makes total sense. However, I feel that you should follow the
> >>> same
> >>>>> pattern as Eclipse team itself. Put an API division between API and
> >>>>> "internal" classes by putting "internal" in package path, but still
> >>> you
> >>>>> can
> >>>>> export everything. Because in many cases you can't fully know how
> >>>>> adopters
> >>>>> will use the plugin and you wouldn't want to prohibit the use of it
> >>> out
> >>>> of
> >>>>> the box just because the packages were exported people end up having
> >>> to
> >>>>> fork the project just to use it for a specific release. If all
> >>> packages
> >>>>> were exported but some marked internal then those programmers will
> >>> have
> >>>>> already been warned by eclipse and if they choose to ignore it, it is
> >>> on
> >>>>> them if the API breaks in the future. This way we can have best of
> >>> both
> >>>>> worlds. :)
> >>>>>
> >>>>>
> >>>>> But regardless, currently in my first integration attempt I'm using
> >>> the
> >>>>> following classes:
> >>>>>
> >>>>> org.apache.ivyde.eclipse.IvyNature
> >>>>> org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
> >>>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
> >>>>>
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
> >>>>>
> >>>
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
> >>>>> org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
> >>>>> org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
> >>>>>
> >>>>> Here is the code where you can see I'm calling the ivy classes:
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
> >>>
> >>>>
> >>>>>
> >>>>>
> >>>>> Right now that code is all messy and just a POC. But you can see
> that
> >>>> I'm
> >>>>> doing 3 things:
> >>>>> -adding ivy nature
> >>>>> -adding ivy classpath container
> >>>>> -running "resolve" on classpath container
> >>>>>
> >>>>>
> >>>>>>> 2. Improved support in ResolvedPath.java class to support
> >>> relative
> >>>>>> paths
> >>>>>>> that use the "../" parent path.
> >>>>>>
> >>>>>> The problem with relative paths is that they got messed up while
> >>> being
> >>>>>> used within the java launcher. Maybe you can share your use case so
> >>> we
> >>>>> can
> >>>>>> figure out a proper way to solve it ? For instance it would be nice
> >>> if
> >>>>> you
> >>>>>> could provide a patch which is adding a test project [1].
> >>>>>>
> >>>>>
> >>>>> Sure thing, I can add a test project. In my scenario with Liferay
> >>> IDE,
> >>>>> all
> >>>>> of our Ivy Projects will live in a parent folder structure that will
> >>>>> contain some shared Ivy configuration settings and also a shared ivy
> >>>>> cache. So when I configure the Ivy container, I need to use relative
> >>>>> paths
> >>>>> for the IvySettings file and the IvyUserDir like this:
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
> >>>
> >>>>
> >>>>>
> >>>>>
> >>>>> something like this for settings file
> >>>>> file:../../ivy-settings.xml
> >>>>>
> >>>>> and this for user dir
> >>>>> ../../.ivy
> >>>>>
> >>>>> So with my modification to ResolvedPath below it fixes it for that
> >>>> issue,
> >>>>> although that code would need to be cleaned up before I submited the
> >>>> patch
> >>>>> :)
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
> >>>
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>> You can see that I have forked the IvyDE repo over on my github
> >>>>> account
> >>>>>> and
> >>>>>>> made a few commits:
> >>>>>>> https://github.com/gamerson/ivyde/commits/liferay-ide
> >>>>>>>
> >>>>>>> Several of those commits are just my hacks in order to build the
> >>> POC
> >>>>> in
> >>>>>> my
> >>>>>>> dev environment, e.g. setting up a tycho build instead of
> >>> ant-based
> >>>>>> build.
> >>>>>>> The only two interesting commits are the following:
> >>>>>>>
> >>>>>>> Modified the Manifest to export all *eclipse* packages
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
> >>>
> >>>>
> >>>>>
> >>>>>>>
> >>>>>>> Modified ResolvedPath to add support for "../.." style paths:
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
> >>>
> >>>>
> >>>>>
> >>>>>>>
> >>>>>>> I'd like to discuss with IvyDE maintainers on how I can get these
> >>>> two
> >>>>>>> changes merged into trunk. I can create JIRA tickets and submit
> >>>>> proper
> >>>>>>> pull requests, or however, you would prefer me to try to
> >>> contribute.
> >>>>>>
> >>>>>> The way to contribute code is to go through Jira. So it somehow
> >>>> clearly
> >>>>>> state that you do want to contribute your patch to the ASF, and we
> >>> are
> >>>>> not
> >>>>>> picking code from you with an unclear license. (You could probably
> >>> do
> >>>> a
> >>>>>> pull request, but I don't know where it would actually go…)
> >>>>>>
> >>>>>
> >>>>> Sure thing, I'll open JIRA ticket with the API export and the
> >>>> ResolvedPath
> >>>>> as those are the two blockers right now.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>> Hope to hear from you all soon and thanks again for the great
> >>> IvyDE!
> >>>>>>
> >>>>>> Thank you for coming here discussing here ! :)
> >>>>>>
> >>>>>
> >>>>> Absolutely! and thanks for responding so quickly.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Nicolas
> >>>>>>
> >>>>>> [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
> >>>>>>
> >>>>>>
> >>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Greg Amerson
> >>>> Liferay Developer Tools
> >>>> Liferay, Inc. www.liferay.com
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> 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
>
>
--
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
Re: Configuring the Ivy classpath container (was: IvyDE adopter use-cases)
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 3 juil. 2013 à 11:21, Greg Amerson <gr...@liferay.com> a écrit :
> Hey Nicolas,
>
> Thanks for the update regarding containers. Regarding the ResolvedPath,
> for me to get my relative paths to work I guess I have two options:
>
> 1 - You would accept a patch from me to ResolvedPath to get "../../" style
> URI's to work
> 2 - I can implement a new dynamic variable something like
> "${liferay_sdk_dir:ivy-project-name}/ivy-settings.xml" The only bad thing
> about this is that I have to encode the project name into the classpath
> container, so if the user changes the project name, the container will fail
> to load. Of course I could add a rename refactoring participant, but I
> guess it would still be broken if user manually changes the project name (
> editing .project file ).
>
> Personally I would prefer option #1 :) but if that isn't doable, I can go
> with #2.
Have you tried ${ivyproject_loc} ? It is a kind of variable (quite hacky since it is not a real Eclipse variable) which got replaced by ${workspace_loc:projectName}. See the first lines of org.apache.ivyde.eclipse.ResolvedPath#resolvePath()
Nicolas
>
> Greg
>
>
> On Wed, Jul 3, 2013 at 5:07 PM, Nicolas Lalevée
> <ni...@hibnet.org>wrote:
>
>>
>> Le 3 juil. 2013 à 10:42, Carsten.Pfeiffer@gebit.de a écrit :
>>
>>> Hi Greg,
>>>
>>> the configuration of the Ivy classpath container is indeed the only
>>> problematic thing here.
>>> You would have to ask the Ivy developers (I'm just a mere user) whether
>>> these options
>>> are considered stable. It's also a bit ugly to handcraft the string with
>>> these options.
>>
>> They definitevly can be considered stable API. And they are already been
>> kept backward compatible. Because these IDs are serialized in the
>> .classpath, so they are spread all over in the IvyDE user's environments.
>> If we break anything there, we would break user's existing classpaths.
>>
>>
>>> Also maintenance of the ivy classpath container settings is a little
>>> uncomfortable. Adjusting
>>> the container settings for a few projects is not a problem, but if you
>>> have hundreds of them,
>>> you have to search&replace the query-style options with regular
>>> expressions in all .classpath files
>>> and then hope that all the resulting options are still valid.
>>
>> I think it won't hurt if we expose IvyClasspathContainerConfiguration
>>
>>
>>> Maybe it would be easier to have some kind of ivy.xml.properties file or
>>> something similar that can be
>>> specified as the only option for an ivy classpath container. The
>>> properties file would contain the options
>>> that are currently specified in the .classpath file itself. This would
>>> even allow sharing of the properties
>>> among multiple projects.
>>
>> Indeed, if you look in your .classpath, you'll see an xml encoded
>> query-string encoded path. I have tried several time to make the classpath
>> entry path more human friendly, but each time things got unstable.
>> The JDT is building the classpath independently of the "building" of the
>> workspace files. So when Eclipse is starting up, the IvyDE classpath
>> container is asked to be configured, whereas the files may not be yet
>> accessible.
>> Here is an exemple of related issue:
>> https://issues.apache.org/jira/browse/IVYDE-302
>> For this issue this is not dramatic, because it is about the resolve which
>> is asynchronous and can be relaunch later. But configuring the classpath
>> container need to be done as required by the JDT, otherwise it won't show
>> properly.
>>
>>
>> Nicolas
>>
>>>
>>> Cheers
>>> Carsten
>>>
>>>
>>>
>>> Von: Greg Amerson <gr...@liferay.com>
>>> An: Ant Developers List <de...@ant.apache.org>
>>> Datum: 03.07.2013 10:20
>>> Betreff: Re: Re: Re: IvyDE adopter use-cases
>>>
>>>
>>>
>>> Hey Carsten,
>>>
>>> On Wed, Jul 3, 2013 at 3:53 PM, <Ca...@gebit.de> wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> nature and container IDs should be as stable as an API, so it should not
>>>> be a problem to rely on them.
>>>>
>>>
>>>
>>> Sure I can use them just as IDs. If they changed it would be hard to use
>>> them for existing projects :).
>>>
>>> What about the variables query-style options that are used in the
>>> container
>>> path ? Can those be considered API as well? So I could avoid using the
>>> Configuration object as API?
>>>
>>>
>>>
>>>>
>>>> There's also a command org.apache.ivyde.commands.resolve, which can be
>>>> parameterized with the
>>>> project you to be resolved. Not sure if you can resolve a single ivy.xml
>>>> (in case a project has multiple).
>>>>
>>>
>>>
>>> Resolving a single project is just fine, that is exactly the use-case I'm
>>> using, when creating a new project.
>>>
>>>
>>>
>>>
>>>>
>>>> I don't know your exact problem with ResolvedPath, but you can also
>>>> specify your ivysettings.xml
>>>> relative to a system property, environment variable, a project location,
>>>> workspace, ...
>>>>
>>>
>>>
>>> So in my case I need to use a path that is relative to the project
>>> location, but its relative as in two parent directories higher. So I
>> need
>>> something like this ${project_loc}/../../ivy-settings.xml But this
>>> doesn't
>>> seem to work right now. I'm looking into implementing my own ${sdk_dir}
>>> that would map to the correct parent directory and maybe the relative
>> path
>>> support wouldn't be required in ResolvedPath. I'll let you know.
>>>
>>>
>>>
>>>>
>>>> Cheers
>>>> Carsten
>>>>
>>>>
>>>>
>>>> Von: Greg Amerson <gr...@liferay.com>
>>>> An: Ant Developers List <de...@ant.apache.org>
>>>> Datum: 03.07.2013 05:04
>>>> Betreff: Re: Re: IvyDE adopter use-cases
>>>>
>>>>
>>>>
>>>> Hey Carsten,
>>>>
>>>> Thanks for those pointers, that is good to consider, especially for the
>>>> nature and the container. The resolveall is a bit much but would rather
>>>> just resolve that single ivy.xml file. I'm sure there is a way to pass
>>>> that to an existing handler so it only resolves one.
>>>>
>>>> But in general, me hard coding natureIds and container IDs is as brittle
>>>> as
>>>> calling an API, so I would prefer a real API that I could call. But
>>> until
>>>> that is settled what the API should look like, this method would work.
>>>>
>>>> That only leaves the ResolvedPath changes. I can try to submit a patch
>>>> and
>>>> test project to import ResolvedPath support for parent directory
>>> relative
>>>> paths.
>>>>
>>>>
>>>> On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
>>>>
>>>>> Hi Greg,
>>>>>
>>>>> most of what you do with the IvyDE API can be done without the IvyDE
>>>> API.
>>>>>
>>>>> 1. You can easily add the nature by using IProject.setDescription()
>>> and
>>>>> providing the Ivy nature ID as a string.
>>>>> 2. You can add the Ivy classpath container to a project's classpath
>>> with
>>>>> JavaCore.newContainerEntry(
>>>>> "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
>>>>> and adding that via IProject.setRawClasspath(). Adding your
>>> specific
>>>>> options of the container is a little
>>>>> problematic though, I agree. You would have to add all those in
>>> the
>>>>> right syntax to the container string.
>>>>> 3. You can invoke the resolving e.g. by calling ICommandService.
>>>>> getCommand("org.apache.ivyde.commands.resolveall")
>>>>> and invoking the execute() method on the command's handler.
>>>>>
>>>>> Cheers
>>>>> Carsten
>>>>>
>>>>>
>>>>> Von: Greg Amerson <gr...@liferay.com>
>>>>> An: Ant Developers List <de...@ant.apache.org>
>>>>> Datum: 02.07.2013 16:24
>>>>> Betreff: Re: IvyDE adopter use-cases
>>>>>
>>>>>
>>>>>
>>>>> Hey Nicolas,
>>>>>
>>>>> Answers inline:
>>>>>
>>>>>
>>>>> On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
>>>>> <ni...@hibnet.org>wrote:
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com>
>>> a
>>>>>> écrit :
>>>>>>
>>>>>>> Hello IvyDE developers,
>>>>>>>
>>>>>>> My name is Greg Amerson and I am the project lead for Liferay IDE,
>>>>> which
>>>>>> is
>>>>>>> a set of Eclipse plugins for Liferay development. In an upcoming
>>>>> version
>>>>>>> of Liferay Portal, we have integrated the use of Ivy dependency
>>>>>> management
>>>>>>> for plugin projects, e.g. liferay plugins (fancy j2ee web
>>> projects)
>>>>> that
>>>>>>> are built using JSF portlets now use Ivy to manage jsf
>>> dependencies.
>>>>>>>
>>>>>>> Therefore in Liferay IDE when our users create Liferay plugin
>>>>> projects,
>>>>>> we
>>>>>>> want users to be able to take advantage of the good support in
>>> IvyDE
>>>>> for
>>>>>>> dependency management, namely the Ivy classpath container. So for
>>>> new
>>>>>>> Liferay projects that are created by our "New Liferay Project
>>>> wizard"
>>>>> in
>>>>>>> our plugins, I want to go ahead and automatically configure that
>>>>> project
>>>>>> to
>>>>>>> have all the IvyDE goodness, (nature, container, pre-resolve the
>>>>>> container,
>>>>>>> deployment assembly configuration). In order to test things out I
>>>>> forked
>>>>>>> the latest trunk on git hub and imported it into my Eclipse SDK
>>> dev
>>>>>>> environment. I then went and built a POC for integration of
>>> Liferay
>>>>>> plugin
>>>>>>> projects enhanced with IvyDE settings. During this process I
>>>> noticed
>>>>>> that
>>>>>>> for our use-cases it seems it will require a few change to IvyDE
>>> to
>>>>>> support
>>>>>>> what we want to do:
>>>>>>>
>>>>>>>
>>>>>>> 1. MANIFEST.MF on the eclipse plugin bundle to export all
>>> packages
>>>>> (so
>>>>>>> they can be called from 3rd-party plugins like ours)
>>>>>>
>>>>>> The API of IvyDE was never properly maintained. Adding new features
>>> or
>>>>>> fixing bugs often involved changing/adding/removing some classes or
>>>>>> methods. I fear that if you rely blindly on the IvyDE "API", we may
>>>>> break
>>>>>> your plugin in the long run.
>>>>>> Maybe with your input we can start building a real API. Only the
>>>> useful
>>>>>> package would be exposed. Only the useful classes. And then we will
>>>> make
>>>>>> sure that IvyDE won't break the API of these classes.
>>>>>> We could start with the list of classes of IvyDE you are actually
>>>> using.
>>>>>>
>>>>>
>>>>> That makes total sense. However, I feel that you should follow the
>>> same
>>>>> pattern as Eclipse team itself. Put an API division between API and
>>>>> "internal" classes by putting "internal" in package path, but still
>>> you
>>>>> can
>>>>> export everything. Because in many cases you can't fully know how
>>>>> adopters
>>>>> will use the plugin and you wouldn't want to prohibit the use of it
>>> out
>>>> of
>>>>> the box just because the packages were exported people end up having
>>> to
>>>>> fork the project just to use it for a specific release. If all
>>> packages
>>>>> were exported but some marked internal then those programmers will
>>> have
>>>>> already been warned by eclipse and if they choose to ignore it, it is
>>> on
>>>>> them if the API breaks in the future. This way we can have best of
>>> both
>>>>> worlds. :)
>>>>>
>>>>>
>>>>> But regardless, currently in my first integration attempt I'm using
>>> the
>>>>> following classes:
>>>>>
>>>>> org.apache.ivyde.eclipse.IvyNature
>>>>> org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
>>>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
>>>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
>>>>>
>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
>>>>> org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
>>>>> org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
>>>>>
>>>>> Here is the code where you can see I'm calling the ivy classes:
>>>>>
>>>>>
>>>>
>>>>
>>>
>> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
>>>
>>>>
>>>>>
>>>>>
>>>>> Right now that code is all messy and just a POC. But you can see that
>>>> I'm
>>>>> doing 3 things:
>>>>> -adding ivy nature
>>>>> -adding ivy classpath container
>>>>> -running "resolve" on classpath container
>>>>>
>>>>>
>>>>>>> 2. Improved support in ResolvedPath.java class to support
>>> relative
>>>>>> paths
>>>>>>> that use the "../" parent path.
>>>>>>
>>>>>> The problem with relative paths is that they got messed up while
>>> being
>>>>>> used within the java launcher. Maybe you can share your use case so
>>> we
>>>>> can
>>>>>> figure out a proper way to solve it ? For instance it would be nice
>>> if
>>>>> you
>>>>>> could provide a patch which is adding a test project [1].
>>>>>>
>>>>>
>>>>> Sure thing, I can add a test project. In my scenario with Liferay
>>> IDE,
>>>>> all
>>>>> of our Ivy Projects will live in a parent folder structure that will
>>>>> contain some shared Ivy configuration settings and also a shared ivy
>>>>> cache. So when I configure the Ivy container, I need to use relative
>>>>> paths
>>>>> for the IvySettings file and the IvyUserDir like this:
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
>>>
>>>>
>>>>>
>>>>>
>>>>> something like this for settings file
>>>>> file:../../ivy-settings.xml
>>>>>
>>>>> and this for user dir
>>>>> ../../.ivy
>>>>>
>>>>> So with my modification to ResolvedPath below it fixes it for that
>>>> issue,
>>>>> although that code would need to be cleaned up before I submited the
>>>> patch
>>>>> :)
>>>>>
>>>>>
>>>>
>>>>
>>>
>> https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> You can see that I have forked the IvyDE repo over on my github
>>>>> account
>>>>>> and
>>>>>>> made a few commits:
>>>>>>> https://github.com/gamerson/ivyde/commits/liferay-ide
>>>>>>>
>>>>>>> Several of those commits are just my hacks in order to build the
>>> POC
>>>>> in
>>>>>> my
>>>>>>> dev environment, e.g. setting up a tycho build instead of
>>> ant-based
>>>>>> build.
>>>>>>> The only two interesting commits are the following:
>>>>>>>
>>>>>>> Modified the Manifest to export all *eclipse* packages
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
>>>
>>>>
>>>>>
>>>>>>>
>>>>>>> Modified ResolvedPath to add support for "../.." style paths:
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
>>>
>>>>
>>>>>
>>>>>>>
>>>>>>> I'd like to discuss with IvyDE maintainers on how I can get these
>>>> two
>>>>>>> changes merged into trunk. I can create JIRA tickets and submit
>>>>> proper
>>>>>>> pull requests, or however, you would prefer me to try to
>>> contribute.
>>>>>>
>>>>>> The way to contribute code is to go through Jira. So it somehow
>>>> clearly
>>>>>> state that you do want to contribute your patch to the ASF, and we
>>> are
>>>>> not
>>>>>> picking code from you with an unclear license. (You could probably
>>> do
>>>> a
>>>>>> pull request, but I don't know where it would actually go…)
>>>>>>
>>>>>
>>>>> Sure thing, I'll open JIRA ticket with the API export and the
>>>> ResolvedPath
>>>>> as those are the two blockers right now.
>>>>>
>>>>>
>>>>>>
>>>>>>> Hope to hear from you all soon and thanks again for the great
>>> IvyDE!
>>>>>>
>>>>>> Thank you for coming here discussing here ! :)
>>>>>>
>>>>>
>>>>> Absolutely! and thanks for responding so quickly.
>>>>>
>>>>>
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>> [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
>>>>>>
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Greg Amerson
>>>> Liferay Developer Tools
>>>> Liferay, Inc. www.liferay.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
Re: Configuring the Ivy classpath container (was: IvyDE adopter use-cases)
Posted by Greg Amerson <gr...@liferay.com>.
Hey Nicolas,
Thanks for the update regarding containers. Regarding the ResolvedPath,
for me to get my relative paths to work I guess I have two options:
1 - You would accept a patch from me to ResolvedPath to get "../../" style
URI's to work
2 - I can implement a new dynamic variable something like
"${liferay_sdk_dir:ivy-project-name}/ivy-settings.xml" The only bad thing
about this is that I have to encode the project name into the classpath
container, so if the user changes the project name, the container will fail
to load. Of course I could add a rename refactoring participant, but I
guess it would still be broken if user manually changes the project name (
editing .project file ).
Personally I would prefer option #1 :) but if that isn't doable, I can go
with #2.
Greg
On Wed, Jul 3, 2013 at 5:07 PM, Nicolas Lalevée
<ni...@hibnet.org>wrote:
>
> Le 3 juil. 2013 à 10:42, Carsten.Pfeiffer@gebit.de a écrit :
>
> > Hi Greg,
> >
> > the configuration of the Ivy classpath container is indeed the only
> > problematic thing here.
> > You would have to ask the Ivy developers (I'm just a mere user) whether
> > these options
> > are considered stable. It's also a bit ugly to handcraft the string with
> > these options.
>
> They definitevly can be considered stable API. And they are already been
> kept backward compatible. Because these IDs are serialized in the
> .classpath, so they are spread all over in the IvyDE user's environments.
> If we break anything there, we would break user's existing classpaths.
>
>
> > Also maintenance of the ivy classpath container settings is a little
> > uncomfortable. Adjusting
> > the container settings for a few projects is not a problem, but if you
> > have hundreds of them,
> > you have to search&replace the query-style options with regular
> > expressions in all .classpath files
> > and then hope that all the resulting options are still valid.
>
> I think it won't hurt if we expose IvyClasspathContainerConfiguration
>
>
> > Maybe it would be easier to have some kind of ivy.xml.properties file or
> > something similar that can be
> > specified as the only option for an ivy classpath container. The
> > properties file would contain the options
> > that are currently specified in the .classpath file itself. This would
> > even allow sharing of the properties
> > among multiple projects.
>
> Indeed, if you look in your .classpath, you'll see an xml encoded
> query-string encoded path. I have tried several time to make the classpath
> entry path more human friendly, but each time things got unstable.
> The JDT is building the classpath independently of the "building" of the
> workspace files. So when Eclipse is starting up, the IvyDE classpath
> container is asked to be configured, whereas the files may not be yet
> accessible.
> Here is an exemple of related issue:
> https://issues.apache.org/jira/browse/IVYDE-302
> For this issue this is not dramatic, because it is about the resolve which
> is asynchronous and can be relaunch later. But configuring the classpath
> container need to be done as required by the JDT, otherwise it won't show
> properly.
>
>
> Nicolas
>
> >
> > Cheers
> > Carsten
> >
> >
> >
> > Von: Greg Amerson <gr...@liferay.com>
> > An: Ant Developers List <de...@ant.apache.org>
> > Datum: 03.07.2013 10:20
> > Betreff: Re: Re: Re: IvyDE adopter use-cases
> >
> >
> >
> > Hey Carsten,
> >
> > On Wed, Jul 3, 2013 at 3:53 PM, <Ca...@gebit.de> wrote:
> >
> >> Hi Greg,
> >>
> >> nature and container IDs should be as stable as an API, so it should not
> >> be a problem to rely on them.
> >>
> >
> >
> > Sure I can use them just as IDs. If they changed it would be hard to use
> > them for existing projects :).
> >
> > What about the variables query-style options that are used in the
> > container
> > path ? Can those be considered API as well? So I could avoid using the
> > Configuration object as API?
> >
> >
> >
> >>
> >> There's also a command org.apache.ivyde.commands.resolve, which can be
> >> parameterized with the
> >> project you to be resolved. Not sure if you can resolve a single ivy.xml
> >> (in case a project has multiple).
> >>
> >
> >
> > Resolving a single project is just fine, that is exactly the use-case I'm
> > using, when creating a new project.
> >
> >
> >
> >
> >>
> >> I don't know your exact problem with ResolvedPath, but you can also
> >> specify your ivysettings.xml
> >> relative to a system property, environment variable, a project location,
> >> workspace, ...
> >>
> >
> >
> > So in my case I need to use a path that is relative to the project
> > location, but its relative as in two parent directories higher. So I
> need
> > something like this ${project_loc}/../../ivy-settings.xml But this
> > doesn't
> > seem to work right now. I'm looking into implementing my own ${sdk_dir}
> > that would map to the correct parent directory and maybe the relative
> path
> > support wouldn't be required in ResolvedPath. I'll let you know.
> >
> >
> >
> >>
> >> Cheers
> >> Carsten
> >>
> >>
> >>
> >> Von: Greg Amerson <gr...@liferay.com>
> >> An: Ant Developers List <de...@ant.apache.org>
> >> Datum: 03.07.2013 05:04
> >> Betreff: Re: Re: IvyDE adopter use-cases
> >>
> >>
> >>
> >> Hey Carsten,
> >>
> >> Thanks for those pointers, that is good to consider, especially for the
> >> nature and the container. The resolveall is a bit much but would rather
> >> just resolve that single ivy.xml file. I'm sure there is a way to pass
> >> that to an existing handler so it only resolves one.
> >>
> >> But in general, me hard coding natureIds and container IDs is as brittle
> >> as
> >> calling an API, so I would prefer a real API that I could call. But
> > until
> >> that is settled what the API should look like, this method would work.
> >>
> >> That only leaves the ResolvedPath changes. I can try to submit a patch
> >> and
> >> test project to import ResolvedPath support for parent directory
> > relative
> >> paths.
> >>
> >>
> >> On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
> >>
> >>> Hi Greg,
> >>>
> >>> most of what you do with the IvyDE API can be done without the IvyDE
> >> API.
> >>>
> >>> 1. You can easily add the nature by using IProject.setDescription()
> > and
> >>> providing the Ivy nature ID as a string.
> >>> 2. You can add the Ivy classpath container to a project's classpath
> > with
> >>> JavaCore.newContainerEntry(
> >>> "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
> >>> and adding that via IProject.setRawClasspath(). Adding your
> > specific
> >>> options of the container is a little
> >>> problematic though, I agree. You would have to add all those in
> > the
> >>> right syntax to the container string.
> >>> 3. You can invoke the resolving e.g. by calling ICommandService.
> >>> getCommand("org.apache.ivyde.commands.resolveall")
> >>> and invoking the execute() method on the command's handler.
> >>>
> >>> Cheers
> >>> Carsten
> >>>
> >>>
> >>> Von: Greg Amerson <gr...@liferay.com>
> >>> An: Ant Developers List <de...@ant.apache.org>
> >>> Datum: 02.07.2013 16:24
> >>> Betreff: Re: IvyDE adopter use-cases
> >>>
> >>>
> >>>
> >>> Hey Nicolas,
> >>>
> >>> Answers inline:
> >>>
> >>>
> >>> On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
> >>> <ni...@hibnet.org>wrote:
> >>>
> >>>> Hi Greg,
> >>>>
> >>>> Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com>
> > a
> >>>> écrit :
> >>>>
> >>>>> Hello IvyDE developers,
> >>>>>
> >>>>> My name is Greg Amerson and I am the project lead for Liferay IDE,
> >>> which
> >>>> is
> >>>>> a set of Eclipse plugins for Liferay development. In an upcoming
> >>> version
> >>>>> of Liferay Portal, we have integrated the use of Ivy dependency
> >>>> management
> >>>>> for plugin projects, e.g. liferay plugins (fancy j2ee web
> > projects)
> >>> that
> >>>>> are built using JSF portlets now use Ivy to manage jsf
> > dependencies.
> >>>>>
> >>>>> Therefore in Liferay IDE when our users create Liferay plugin
> >>> projects,
> >>>> we
> >>>>> want users to be able to take advantage of the good support in
> > IvyDE
> >>> for
> >>>>> dependency management, namely the Ivy classpath container. So for
> >> new
> >>>>> Liferay projects that are created by our "New Liferay Project
> >> wizard"
> >>> in
> >>>>> our plugins, I want to go ahead and automatically configure that
> >>> project
> >>>> to
> >>>>> have all the IvyDE goodness, (nature, container, pre-resolve the
> >>>> container,
> >>>>> deployment assembly configuration). In order to test things out I
> >>> forked
> >>>>> the latest trunk on git hub and imported it into my Eclipse SDK
> > dev
> >>>>> environment. I then went and built a POC for integration of
> > Liferay
> >>>> plugin
> >>>>> projects enhanced with IvyDE settings. During this process I
> >> noticed
> >>>> that
> >>>>> for our use-cases it seems it will require a few change to IvyDE
> > to
> >>>> support
> >>>>> what we want to do:
> >>>>>
> >>>>>
> >>>>> 1. MANIFEST.MF on the eclipse plugin bundle to export all
> > packages
> >>> (so
> >>>>> they can be called from 3rd-party plugins like ours)
> >>>>
> >>>> The API of IvyDE was never properly maintained. Adding new features
> > or
> >>>> fixing bugs often involved changing/adding/removing some classes or
> >>>> methods. I fear that if you rely blindly on the IvyDE "API", we may
> >>> break
> >>>> your plugin in the long run.
> >>>> Maybe with your input we can start building a real API. Only the
> >> useful
> >>>> package would be exposed. Only the useful classes. And then we will
> >> make
> >>>> sure that IvyDE won't break the API of these classes.
> >>>> We could start with the list of classes of IvyDE you are actually
> >> using.
> >>>>
> >>>
> >>> That makes total sense. However, I feel that you should follow the
> > same
> >>> pattern as Eclipse team itself. Put an API division between API and
> >>> "internal" classes by putting "internal" in package path, but still
> > you
> >>> can
> >>> export everything. Because in many cases you can't fully know how
> >>> adopters
> >>> will use the plugin and you wouldn't want to prohibit the use of it
> > out
> >> of
> >>> the box just because the packages were exported people end up having
> > to
> >>> fork the project just to use it for a specific release. If all
> > packages
> >>> were exported but some marked internal then those programmers will
> > have
> >>> already been warned by eclipse and if they choose to ignore it, it is
> > on
> >>> them if the API breaks in the future. This way we can have best of
> > both
> >>> worlds. :)
> >>>
> >>>
> >>> But regardless, currently in my first integration attempt I'm using
> > the
> >>> following classes:
> >>>
> >>> org.apache.ivyde.eclipse.IvyNature
> >>> org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
> >>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
> >>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
> >>>
> > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
> >>> org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
> >>> org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
> >>>
> >>> Here is the code where you can see I'm calling the ivy classes:
> >>>
> >>>
> >>
> >>
> >
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
> >
> >>
> >>>
> >>>
> >>> Right now that code is all messy and just a POC. But you can see that
> >> I'm
> >>> doing 3 things:
> >>> -adding ivy nature
> >>> -adding ivy classpath container
> >>> -running "resolve" on classpath container
> >>>
> >>>
> >>>>> 2. Improved support in ResolvedPath.java class to support
> > relative
> >>>> paths
> >>>>> that use the "../" parent path.
> >>>>
> >>>> The problem with relative paths is that they got messed up while
> > being
> >>>> used within the java launcher. Maybe you can share your use case so
> > we
> >>> can
> >>>> figure out a proper way to solve it ? For instance it would be nice
> > if
> >>> you
> >>>> could provide a patch which is adding a test project [1].
> >>>>
> >>>
> >>> Sure thing, I can add a test project. In my scenario with Liferay
> > IDE,
> >>> all
> >>> of our Ivy Projects will live in a parent folder structure that will
> >>> contain some shared Ivy configuration settings and also a shared ivy
> >>> cache. So when I configure the Ivy container, I need to use relative
> >>> paths
> >>> for the IvySettings file and the IvyUserDir like this:
> >>>
> >>>
> >>>
> >>
> >>
> >
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
> >
> >>
> >>>
> >>>
> >>> something like this for settings file
> >>> file:../../ivy-settings.xml
> >>>
> >>> and this for user dir
> >>> ../../.ivy
> >>>
> >>> So with my modification to ResolvedPath below it fixes it for that
> >> issue,
> >>> although that code would need to be cleaned up before I submited the
> >> patch
> >>> :)
> >>>
> >>>
> >>
> >>
> >
> https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
> >
> >>
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>>> You can see that I have forked the IvyDE repo over on my github
> >>> account
> >>>> and
> >>>>> made a few commits:
> >>>>> https://github.com/gamerson/ivyde/commits/liferay-ide
> >>>>>
> >>>>> Several of those commits are just my hacks in order to build the
> > POC
> >>> in
> >>>> my
> >>>>> dev environment, e.g. setting up a tycho build instead of
> > ant-based
> >>>> build.
> >>>>> The only two interesting commits are the following:
> >>>>>
> >>>>> Modified the Manifest to export all *eclipse* packages
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
> >
> >>
> >>>
> >>>>>
> >>>>> Modified ResolvedPath to add support for "../.." style paths:
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
> >
> >>
> >>>
> >>>>>
> >>>>> I'd like to discuss with IvyDE maintainers on how I can get these
> >> two
> >>>>> changes merged into trunk. I can create JIRA tickets and submit
> >>> proper
> >>>>> pull requests, or however, you would prefer me to try to
> > contribute.
> >>>>
> >>>> The way to contribute code is to go through Jira. So it somehow
> >> clearly
> >>>> state that you do want to contribute your patch to the ASF, and we
> > are
> >>> not
> >>>> picking code from you with an unclear license. (You could probably
> > do
> >> a
> >>>> pull request, but I don't know where it would actually go…)
> >>>>
> >>>
> >>> Sure thing, I'll open JIRA ticket with the API export and the
> >> ResolvedPath
> >>> as those are the two blockers right now.
> >>>
> >>>
> >>>>
> >>>>> Hope to hear from you all soon and thanks again for the great
> > IvyDE!
> >>>>
> >>>> Thank you for coming here discussing here ! :)
> >>>>
> >>>
> >>> Absolutely! and thanks for responding so quickly.
> >>>
> >>>
> >>>>
> >>>> Nicolas
> >>>>
> >>>> [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
> >>>>
> >>>>
> >>>>
> > ---------------------------------------------------------------------
> >>>> 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
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Greg Amerson
> >> Liferay Developer Tools
> >> Liferay, Inc. www.liferay.com
> >>
> >>
> >>
> >
> >
> > --
> > 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: Configuring the Ivy classpath container (was: IvyDE adopter use-cases)
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 3 juil. 2013 à 10:42, Carsten.Pfeiffer@gebit.de a écrit :
> Hi Greg,
>
> the configuration of the Ivy classpath container is indeed the only
> problematic thing here.
> You would have to ask the Ivy developers (I'm just a mere user) whether
> these options
> are considered stable. It's also a bit ugly to handcraft the string with
> these options.
They definitevly can be considered stable API. And they are already been kept backward compatible. Because these IDs are serialized in the .classpath, so they are spread all over in the IvyDE user's environments. If we break anything there, we would break user's existing classpaths.
> Also maintenance of the ivy classpath container settings is a little
> uncomfortable. Adjusting
> the container settings for a few projects is not a problem, but if you
> have hundreds of them,
> you have to search&replace the query-style options with regular
> expressions in all .classpath files
> and then hope that all the resulting options are still valid.
I think it won't hurt if we expose IvyClasspathContainerConfiguration
> Maybe it would be easier to have some kind of ivy.xml.properties file or
> something similar that can be
> specified as the only option for an ivy classpath container. The
> properties file would contain the options
> that are currently specified in the .classpath file itself. This would
> even allow sharing of the properties
> among multiple projects.
Indeed, if you look in your .classpath, you'll see an xml encoded query-string encoded path. I have tried several time to make the classpath entry path more human friendly, but each time things got unstable.
The JDT is building the classpath independently of the "building" of the workspace files. So when Eclipse is starting up, the IvyDE classpath container is asked to be configured, whereas the files may not be yet accessible.
Here is an exemple of related issue: https://issues.apache.org/jira/browse/IVYDE-302
For this issue this is not dramatic, because it is about the resolve which is asynchronous and can be relaunch later. But configuring the classpath container need to be done as required by the JDT, otherwise it won't show properly.
Nicolas
>
> Cheers
> Carsten
>
>
>
> Von: Greg Amerson <gr...@liferay.com>
> An: Ant Developers List <de...@ant.apache.org>
> Datum: 03.07.2013 10:20
> Betreff: Re: Re: Re: IvyDE adopter use-cases
>
>
>
> Hey Carsten,
>
> On Wed, Jul 3, 2013 at 3:53 PM, <Ca...@gebit.de> wrote:
>
>> Hi Greg,
>>
>> nature and container IDs should be as stable as an API, so it should not
>> be a problem to rely on them.
>>
>
>
> Sure I can use them just as IDs. If they changed it would be hard to use
> them for existing projects :).
>
> What about the variables query-style options that are used in the
> container
> path ? Can those be considered API as well? So I could avoid using the
> Configuration object as API?
>
>
>
>>
>> There's also a command org.apache.ivyde.commands.resolve, which can be
>> parameterized with the
>> project you to be resolved. Not sure if you can resolve a single ivy.xml
>> (in case a project has multiple).
>>
>
>
> Resolving a single project is just fine, that is exactly the use-case I'm
> using, when creating a new project.
>
>
>
>
>>
>> I don't know your exact problem with ResolvedPath, but you can also
>> specify your ivysettings.xml
>> relative to a system property, environment variable, a project location,
>> workspace, ...
>>
>
>
> So in my case I need to use a path that is relative to the project
> location, but its relative as in two parent directories higher. So I need
> something like this ${project_loc}/../../ivy-settings.xml But this
> doesn't
> seem to work right now. I'm looking into implementing my own ${sdk_dir}
> that would map to the correct parent directory and maybe the relative path
> support wouldn't be required in ResolvedPath. I'll let you know.
>
>
>
>>
>> Cheers
>> Carsten
>>
>>
>>
>> Von: Greg Amerson <gr...@liferay.com>
>> An: Ant Developers List <de...@ant.apache.org>
>> Datum: 03.07.2013 05:04
>> Betreff: Re: Re: IvyDE adopter use-cases
>>
>>
>>
>> Hey Carsten,
>>
>> Thanks for those pointers, that is good to consider, especially for the
>> nature and the container. The resolveall is a bit much but would rather
>> just resolve that single ivy.xml file. I'm sure there is a way to pass
>> that to an existing handler so it only resolves one.
>>
>> But in general, me hard coding natureIds and container IDs is as brittle
>> as
>> calling an API, so I would prefer a real API that I could call. But
> until
>> that is settled what the API should look like, this method would work.
>>
>> That only leaves the ResolvedPath changes. I can try to submit a patch
>> and
>> test project to import ResolvedPath support for parent directory
> relative
>> paths.
>>
>>
>> On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
>>
>>> Hi Greg,
>>>
>>> most of what you do with the IvyDE API can be done without the IvyDE
>> API.
>>>
>>> 1. You can easily add the nature by using IProject.setDescription()
> and
>>> providing the Ivy nature ID as a string.
>>> 2. You can add the Ivy classpath container to a project's classpath
> with
>>> JavaCore.newContainerEntry(
>>> "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
>>> and adding that via IProject.setRawClasspath(). Adding your
> specific
>>> options of the container is a little
>>> problematic though, I agree. You would have to add all those in
> the
>>> right syntax to the container string.
>>> 3. You can invoke the resolving e.g. by calling ICommandService.
>>> getCommand("org.apache.ivyde.commands.resolveall")
>>> and invoking the execute() method on the command's handler.
>>>
>>> Cheers
>>> Carsten
>>>
>>>
>>> Von: Greg Amerson <gr...@liferay.com>
>>> An: Ant Developers List <de...@ant.apache.org>
>>> Datum: 02.07.2013 16:24
>>> Betreff: Re: IvyDE adopter use-cases
>>>
>>>
>>>
>>> Hey Nicolas,
>>>
>>> Answers inline:
>>>
>>>
>>> On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
>>> <ni...@hibnet.org>wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com>
> a
>>>> écrit :
>>>>
>>>>> Hello IvyDE developers,
>>>>>
>>>>> My name is Greg Amerson and I am the project lead for Liferay IDE,
>>> which
>>>> is
>>>>> a set of Eclipse plugins for Liferay development. In an upcoming
>>> version
>>>>> of Liferay Portal, we have integrated the use of Ivy dependency
>>>> management
>>>>> for plugin projects, e.g. liferay plugins (fancy j2ee web
> projects)
>>> that
>>>>> are built using JSF portlets now use Ivy to manage jsf
> dependencies.
>>>>>
>>>>> Therefore in Liferay IDE when our users create Liferay plugin
>>> projects,
>>>> we
>>>>> want users to be able to take advantage of the good support in
> IvyDE
>>> for
>>>>> dependency management, namely the Ivy classpath container. So for
>> new
>>>>> Liferay projects that are created by our "New Liferay Project
>> wizard"
>>> in
>>>>> our plugins, I want to go ahead and automatically configure that
>>> project
>>>> to
>>>>> have all the IvyDE goodness, (nature, container, pre-resolve the
>>>> container,
>>>>> deployment assembly configuration). In order to test things out I
>>> forked
>>>>> the latest trunk on git hub and imported it into my Eclipse SDK
> dev
>>>>> environment. I then went and built a POC for integration of
> Liferay
>>>> plugin
>>>>> projects enhanced with IvyDE settings. During this process I
>> noticed
>>>> that
>>>>> for our use-cases it seems it will require a few change to IvyDE
> to
>>>> support
>>>>> what we want to do:
>>>>>
>>>>>
>>>>> 1. MANIFEST.MF on the eclipse plugin bundle to export all
> packages
>>> (so
>>>>> they can be called from 3rd-party plugins like ours)
>>>>
>>>> The API of IvyDE was never properly maintained. Adding new features
> or
>>>> fixing bugs often involved changing/adding/removing some classes or
>>>> methods. I fear that if you rely blindly on the IvyDE "API", we may
>>> break
>>>> your plugin in the long run.
>>>> Maybe with your input we can start building a real API. Only the
>> useful
>>>> package would be exposed. Only the useful classes. And then we will
>> make
>>>> sure that IvyDE won't break the API of these classes.
>>>> We could start with the list of classes of IvyDE you are actually
>> using.
>>>>
>>>
>>> That makes total sense. However, I feel that you should follow the
> same
>>> pattern as Eclipse team itself. Put an API division between API and
>>> "internal" classes by putting "internal" in package path, but still
> you
>>> can
>>> export everything. Because in many cases you can't fully know how
>>> adopters
>>> will use the plugin and you wouldn't want to prohibit the use of it
> out
>> of
>>> the box just because the packages were exported people end up having
> to
>>> fork the project just to use it for a specific release. If all
> packages
>>> were exported but some marked internal then those programmers will
> have
>>> already been warned by eclipse and if they choose to ignore it, it is
> on
>>> them if the API breaks in the future. This way we can have best of
> both
>>> worlds. :)
>>>
>>>
>>> But regardless, currently in my first integration attempt I'm using
> the
>>> following classes:
>>>
>>> org.apache.ivyde.eclipse.IvyNature
>>> org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
>>> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
>>>
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
>>> org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
>>> org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
>>>
>>> Here is the code where you can see I'm calling the ivy classes:
>>>
>>>
>>
>>
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
>
>>
>>>
>>>
>>> Right now that code is all messy and just a POC. But you can see that
>> I'm
>>> doing 3 things:
>>> -adding ivy nature
>>> -adding ivy classpath container
>>> -running "resolve" on classpath container
>>>
>>>
>>>>> 2. Improved support in ResolvedPath.java class to support
> relative
>>>> paths
>>>>> that use the "../" parent path.
>>>>
>>>> The problem with relative paths is that they got messed up while
> being
>>>> used within the java launcher. Maybe you can share your use case so
> we
>>> can
>>>> figure out a proper way to solve it ? For instance it would be nice
> if
>>> you
>>>> could provide a patch which is adding a test project [1].
>>>>
>>>
>>> Sure thing, I can add a test project. In my scenario with Liferay
> IDE,
>>> all
>>> of our Ivy Projects will live in a parent folder structure that will
>>> contain some shared Ivy configuration settings and also a shared ivy
>>> cache. So when I configure the Ivy container, I need to use relative
>>> paths
>>> for the IvySettings file and the IvyUserDir like this:
>>>
>>>
>>>
>>
>>
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
>
>>
>>>
>>>
>>> something like this for settings file
>>> file:../../ivy-settings.xml
>>>
>>> and this for user dir
>>> ../../.ivy
>>>
>>> So with my modification to ResolvedPath below it fixes it for that
>> issue,
>>> although that code would need to be cleaned up before I submited the
>> patch
>>> :)
>>>
>>>
>>
>>
> https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>>> You can see that I have forked the IvyDE repo over on my github
>>> account
>>>> and
>>>>> made a few commits:
>>>>> https://github.com/gamerson/ivyde/commits/liferay-ide
>>>>>
>>>>> Several of those commits are just my hacks in order to build the
> POC
>>> in
>>>> my
>>>>> dev environment, e.g. setting up a tycho build instead of
> ant-based
>>>> build.
>>>>> The only two interesting commits are the following:
>>>>>
>>>>> Modified the Manifest to export all *eclipse* packages
>>>>>
>>>>
>>>
>>>
>>
>>
> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
>
>>
>>>
>>>>>
>>>>> Modified ResolvedPath to add support for "../.." style paths:
>>>>>
>>>>
>>>
>>>
>>
>>
> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
>
>>
>>>
>>>>>
>>>>> I'd like to discuss with IvyDE maintainers on how I can get these
>> two
>>>>> changes merged into trunk. I can create JIRA tickets and submit
>>> proper
>>>>> pull requests, or however, you would prefer me to try to
> contribute.
>>>>
>>>> The way to contribute code is to go through Jira. So it somehow
>> clearly
>>>> state that you do want to contribute your patch to the ASF, and we
> are
>>> not
>>>> picking code from you with an unclear license. (You could probably
> do
>> a
>>>> pull request, but I don't know where it would actually go…)
>>>>
>>>
>>> Sure thing, I'll open JIRA ticket with the API export and the
>> ResolvedPath
>>> as those are the two blockers right now.
>>>
>>>
>>>>
>>>>> Hope to hear from you all soon and thanks again for the great
> IvyDE!
>>>>
>>>> Thank you for coming here discussing here ! :)
>>>>
>>>
>>> Absolutely! and thanks for responding so quickly.
>>>
>>>
>>>>
>>>> Nicolas
>>>>
>>>> [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>> --
>> Greg Amerson
>> Liferay Developer Tools
>> Liferay, Inc. www.liferay.com
>>
>>
>>
>
>
> --
> 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
Configuring the Ivy classpath container (was: IvyDE adopter use-cases)
Posted by Ca...@gebit.de.
Hi Greg,
the configuration of the Ivy classpath container is indeed the only
problematic thing here.
You would have to ask the Ivy developers (I'm just a mere user) whether
these options
are considered stable. It's also a bit ugly to handcraft the string with
these options.
Also maintenance of the ivy classpath container settings is a little
uncomfortable. Adjusting
the container settings for a few projects is not a problem, but if you
have hundreds of them,
you have to search&replace the query-style options with regular
expressions in all .classpath files
and then hope that all the resulting options are still valid.
Maybe it would be easier to have some kind of ivy.xml.properties file or
something similar that can be
specified as the only option for an ivy classpath container. The
properties file would contain the options
that are currently specified in the .classpath file itself. This would
even allow sharing of the properties
among multiple projects.
Cheers
Carsten
Von: Greg Amerson <gr...@liferay.com>
An: Ant Developers List <de...@ant.apache.org>
Datum: 03.07.2013 10:20
Betreff: Re: Re: Re: IvyDE adopter use-cases
Hey Carsten,
On Wed, Jul 3, 2013 at 3:53 PM, <Ca...@gebit.de> wrote:
> Hi Greg,
>
> nature and container IDs should be as stable as an API, so it should not
> be a problem to rely on them.
>
Sure I can use them just as IDs. If they changed it would be hard to use
them for existing projects :).
What about the variables query-style options that are used in the
container
path ? Can those be considered API as well? So I could avoid using the
Configuration object as API?
>
> There's also a command org.apache.ivyde.commands.resolve, which can be
> parameterized with the
> project you to be resolved. Not sure if you can resolve a single ivy.xml
> (in case a project has multiple).
>
Resolving a single project is just fine, that is exactly the use-case I'm
using, when creating a new project.
>
> I don't know your exact problem with ResolvedPath, but you can also
> specify your ivysettings.xml
> relative to a system property, environment variable, a project location,
> workspace, ...
>
So in my case I need to use a path that is relative to the project
location, but its relative as in two parent directories higher. So I need
something like this ${project_loc}/../../ivy-settings.xml But this
doesn't
seem to work right now. I'm looking into implementing my own ${sdk_dir}
that would map to the correct parent directory and maybe the relative path
support wouldn't be required in ResolvedPath. I'll let you know.
>
> Cheers
> Carsten
>
>
>
> Von: Greg Amerson <gr...@liferay.com>
> An: Ant Developers List <de...@ant.apache.org>
> Datum: 03.07.2013 05:04
> Betreff: Re: Re: IvyDE adopter use-cases
>
>
>
> Hey Carsten,
>
> Thanks for those pointers, that is good to consider, especially for the
> nature and the container. The resolveall is a bit much but would rather
> just resolve that single ivy.xml file. I'm sure there is a way to pass
> that to an existing handler so it only resolves one.
>
> But in general, me hard coding natureIds and container IDs is as brittle
> as
> calling an API, so I would prefer a real API that I could call. But
until
> that is settled what the API should look like, this method would work.
>
> That only leaves the ResolvedPath changes. I can try to submit a patch
> and
> test project to import ResolvedPath support for parent directory
relative
> paths.
>
>
> On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
>
> > Hi Greg,
> >
> > most of what you do with the IvyDE API can be done without the IvyDE
> API.
> >
> > 1. You can easily add the nature by using IProject.setDescription()
and
> > providing the Ivy nature ID as a string.
> > 2. You can add the Ivy classpath container to a project's classpath
with
> > JavaCore.newContainerEntry(
> > "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
> > and adding that via IProject.setRawClasspath(). Adding your
specific
> > options of the container is a little
> > problematic though, I agree. You would have to add all those in
the
> > right syntax to the container string.
> > 3. You can invoke the resolving e.g. by calling ICommandService.
> > getCommand("org.apache.ivyde.commands.resolveall")
> > and invoking the execute() method on the command's handler.
> >
> > Cheers
> > Carsten
> >
> >
> > Von: Greg Amerson <gr...@liferay.com>
> > An: Ant Developers List <de...@ant.apache.org>
> > Datum: 02.07.2013 16:24
> > Betreff: Re: IvyDE adopter use-cases
> >
> >
> >
> > Hey Nicolas,
> >
> > Answers inline:
> >
> >
> > On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
> > <ni...@hibnet.org>wrote:
> >
> > > Hi Greg,
> > >
> > > Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com>
a
> > > écrit :
> > >
> > > > Hello IvyDE developers,
> > > >
> > > > My name is Greg Amerson and I am the project lead for Liferay IDE,
> > which
> > > is
> > > > a set of Eclipse plugins for Liferay development. In an upcoming
> > version
> > > > of Liferay Portal, we have integrated the use of Ivy dependency
> > > management
> > > > for plugin projects, e.g. liferay plugins (fancy j2ee web
projects)
> > that
> > > > are built using JSF portlets now use Ivy to manage jsf
dependencies.
> > > >
> > > > Therefore in Liferay IDE when our users create Liferay plugin
> > projects,
> > > we
> > > > want users to be able to take advantage of the good support in
IvyDE
> > for
> > > > dependency management, namely the Ivy classpath container. So for
> new
> > > > Liferay projects that are created by our "New Liferay Project
> wizard"
> > in
> > > > our plugins, I want to go ahead and automatically configure that
> > project
> > > to
> > > > have all the IvyDE goodness, (nature, container, pre-resolve the
> > > container,
> > > > deployment assembly configuration). In order to test things out I
> > forked
> > > > the latest trunk on git hub and imported it into my Eclipse SDK
dev
> > > > environment. I then went and built a POC for integration of
Liferay
> > > plugin
> > > > projects enhanced with IvyDE settings. During this process I
> noticed
> > > that
> > > > for our use-cases it seems it will require a few change to IvyDE
to
> > > support
> > > > what we want to do:
> > > >
> > > >
> > > > 1. MANIFEST.MF on the eclipse plugin bundle to export all
packages
> > (so
> > > > they can be called from 3rd-party plugins like ours)
> > >
> > > The API of IvyDE was never properly maintained. Adding new features
or
> > > fixing bugs often involved changing/adding/removing some classes or
> > > methods. I fear that if you rely blindly on the IvyDE "API", we may
> > break
> > > your plugin in the long run.
> > > Maybe with your input we can start building a real API. Only the
> useful
> > > package would be exposed. Only the useful classes. And then we will
> make
> > > sure that IvyDE won't break the API of these classes.
> > > We could start with the list of classes of IvyDE you are actually
> using.
> > >
> >
> > That makes total sense. However, I feel that you should follow the
same
> > pattern as Eclipse team itself. Put an API division between API and
> > "internal" classes by putting "internal" in package path, but still
you
> > can
> > export everything. Because in many cases you can't fully know how
> > adopters
> > will use the plugin and you wouldn't want to prohibit the use of it
out
> of
> > the box just because the packages were exported people end up having
to
> > fork the project just to use it for a specific release. If all
packages
> > were exported but some marked internal then those programmers will
have
> > already been warned by eclipse and if they choose to ignore it, it is
on
> > them if the API breaks in the future. This way we can have best of
both
> > worlds. :)
> >
> >
> > But regardless, currently in my first integration attempt I'm using
the
> > following classes:
> >
> > org.apache.ivyde.eclipse.IvyNature
> > org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
> > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
> > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
> >
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
> > org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
> > org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
> >
> > Here is the code where you can see I'm calling the ivy classes:
> >
> >
>
>
https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
>
> >
> >
> > Right now that code is all messy and just a POC. But you can see that
> I'm
> > doing 3 things:
> > -adding ivy nature
> > -adding ivy classpath container
> > -running "resolve" on classpath container
> >
> >
> > > > 2. Improved support in ResolvedPath.java class to support
relative
> > > paths
> > > > that use the "../" parent path.
> > >
> > > The problem with relative paths is that they got messed up while
being
> > > used within the java launcher. Maybe you can share your use case so
we
> > can
> > > figure out a proper way to solve it ? For instance it would be nice
if
> > you
> > > could provide a patch which is adding a test project [1].
> > >
> >
> > Sure thing, I can add a test project. In my scenario with Liferay
IDE,
> > all
> > of our Ivy Projects will live in a parent folder structure that will
> > contain some shared Ivy configuration settings and also a shared ivy
> > cache. So when I configure the Ivy container, I need to use relative
> > paths
> > for the IvySettings file and the IvyUserDir like this:
> >
> >
> >
>
>
https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
>
> >
> >
> > something like this for settings file
> > file:../../ivy-settings.xml
> >
> > and this for user dir
> > ../../.ivy
> >
> > So with my modification to ResolvedPath below it fixes it for that
> issue,
> > although that code would need to be cleaned up before I submited the
> patch
> > :)
> >
> >
>
>
https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>
> >
> >
> >
> > >
> > >
> > > > You can see that I have forked the IvyDE repo over on my github
> > account
> > > and
> > > > made a few commits:
> > > > https://github.com/gamerson/ivyde/commits/liferay-ide
> > > >
> > > > Several of those commits are just my hacks in order to build the
POC
> > in
> > > my
> > > > dev environment, e.g. setting up a tycho build instead of
ant-based
> > > build.
> > > > The only two interesting commits are the following:
> > > >
> > > > Modified the Manifest to export all *eclipse* packages
> > > >
> > >
> >
> >
>
>
https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
>
> >
> > > >
> > > > Modified ResolvedPath to add support for "../.." style paths:
> > > >
> > >
> >
> >
>
>
https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
>
> >
> > > >
> > > > I'd like to discuss with IvyDE maintainers on how I can get these
> two
> > > > changes merged into trunk. I can create JIRA tickets and submit
> > proper
> > > > pull requests, or however, you would prefer me to try to
contribute.
> > >
> > > The way to contribute code is to go through Jira. So it somehow
> clearly
> > > state that you do want to contribute your patch to the ASF, and we
are
> > not
> > > picking code from you with an unclear license. (You could probably
do
> a
> > > pull request, but I don't know where it would actually go…)
> > >
> >
> > Sure thing, I'll open JIRA ticket with the API export and the
> ResolvedPath
> > as those are the two blockers right now.
> >
> >
> > >
> > > > Hope to hear from you all soon and thanks again for the great
IvyDE!
> > >
> > > Thank you for coming here discussing here ! :)
> > >
> >
> > Absolutely! and thanks for responding so quickly.
> >
> >
> > >
> > > Nicolas
> > >
> > > [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
> > >
> > >
> > >
---------------------------------------------------------------------
> > > 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
> >
> >
> >
>
>
> --
> Greg Amerson
> Liferay Developer Tools
> Liferay, Inc. www.liferay.com
>
>
>
--
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
Re: Re: Re: IvyDE adopter use-cases
Posted by Greg Amerson <gr...@liferay.com>.
Hey Carsten,
On Wed, Jul 3, 2013 at 3:53 PM, <Ca...@gebit.de> wrote:
> Hi Greg,
>
> nature and container IDs should be as stable as an API, so it should not
> be a problem to rely on them.
>
Sure I can use them just as IDs. If they changed it would be hard to use
them for existing projects :).
What about the variables query-style options that are used in the container
path ? Can those be considered API as well? So I could avoid using the
Configuration object as API?
>
> There's also a command org.apache.ivyde.commands.resolve, which can be
> parameterized with the
> project you to be resolved. Not sure if you can resolve a single ivy.xml
> (in case a project has multiple).
>
Resolving a single project is just fine, that is exactly the use-case I'm
using, when creating a new project.
>
> I don't know your exact problem with ResolvedPath, but you can also
> specify your ivysettings.xml
> relative to a system property, environment variable, a project location,
> workspace, ...
>
So in my case I need to use a path that is relative to the project
location, but its relative as in two parent directories higher. So I need
something like this ${project_loc}/../../ivy-settings.xml But this doesn't
seem to work right now. I'm looking into implementing my own ${sdk_dir}
that would map to the correct parent directory and maybe the relative path
support wouldn't be required in ResolvedPath. I'll let you know.
>
> Cheers
> Carsten
>
>
>
> Von: Greg Amerson <gr...@liferay.com>
> An: Ant Developers List <de...@ant.apache.org>
> Datum: 03.07.2013 05:04
> Betreff: Re: Re: IvyDE adopter use-cases
>
>
>
> Hey Carsten,
>
> Thanks for those pointers, that is good to consider, especially for the
> nature and the container. The resolveall is a bit much but would rather
> just resolve that single ivy.xml file. I'm sure there is a way to pass
> that to an existing handler so it only resolves one.
>
> But in general, me hard coding natureIds and container IDs is as brittle
> as
> calling an API, so I would prefer a real API that I could call. But until
> that is settled what the API should look like, this method would work.
>
> That only leaves the ResolvedPath changes. I can try to submit a patch
> and
> test project to import ResolvedPath support for parent directory relative
> paths.
>
>
> On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
>
> > Hi Greg,
> >
> > most of what you do with the IvyDE API can be done without the IvyDE
> API.
> >
> > 1. You can easily add the nature by using IProject.setDescription() and
> > providing the Ivy nature ID as a string.
> > 2. You can add the Ivy classpath container to a project's classpath with
> > JavaCore.newContainerEntry(
> > "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
> > and adding that via IProject.setRawClasspath(). Adding your specific
> > options of the container is a little
> > problematic though, I agree. You would have to add all those in the
> > right syntax to the container string.
> > 3. You can invoke the resolving e.g. by calling ICommandService.
> > getCommand("org.apache.ivyde.commands.resolveall")
> > and invoking the execute() method on the command's handler.
> >
> > Cheers
> > Carsten
> >
> >
> > Von: Greg Amerson <gr...@liferay.com>
> > An: Ant Developers List <de...@ant.apache.org>
> > Datum: 02.07.2013 16:24
> > Betreff: Re: IvyDE adopter use-cases
> >
> >
> >
> > Hey Nicolas,
> >
> > Answers inline:
> >
> >
> > On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
> > <ni...@hibnet.org>wrote:
> >
> > > Hi Greg,
> > >
> > > Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com> a
> > > écrit :
> > >
> > > > Hello IvyDE developers,
> > > >
> > > > My name is Greg Amerson and I am the project lead for Liferay IDE,
> > which
> > > is
> > > > a set of Eclipse plugins for Liferay development. In an upcoming
> > version
> > > > of Liferay Portal, we have integrated the use of Ivy dependency
> > > management
> > > > for plugin projects, e.g. liferay plugins (fancy j2ee web projects)
> > that
> > > > are built using JSF portlets now use Ivy to manage jsf dependencies.
> > > >
> > > > Therefore in Liferay IDE when our users create Liferay plugin
> > projects,
> > > we
> > > > want users to be able to take advantage of the good support in IvyDE
> > for
> > > > dependency management, namely the Ivy classpath container. So for
> new
> > > > Liferay projects that are created by our "New Liferay Project
> wizard"
> > in
> > > > our plugins, I want to go ahead and automatically configure that
> > project
> > > to
> > > > have all the IvyDE goodness, (nature, container, pre-resolve the
> > > container,
> > > > deployment assembly configuration). In order to test things out I
> > forked
> > > > the latest trunk on git hub and imported it into my Eclipse SDK dev
> > > > environment. I then went and built a POC for integration of Liferay
> > > plugin
> > > > projects enhanced with IvyDE settings. During this process I
> noticed
> > > that
> > > > for our use-cases it seems it will require a few change to IvyDE to
> > > support
> > > > what we want to do:
> > > >
> > > >
> > > > 1. MANIFEST.MF on the eclipse plugin bundle to export all packages
> > (so
> > > > they can be called from 3rd-party plugins like ours)
> > >
> > > The API of IvyDE was never properly maintained. Adding new features or
> > > fixing bugs often involved changing/adding/removing some classes or
> > > methods. I fear that if you rely blindly on the IvyDE "API", we may
> > break
> > > your plugin in the long run.
> > > Maybe with your input we can start building a real API. Only the
> useful
> > > package would be exposed. Only the useful classes. And then we will
> make
> > > sure that IvyDE won't break the API of these classes.
> > > We could start with the list of classes of IvyDE you are actually
> using.
> > >
> >
> > That makes total sense. However, I feel that you should follow the same
> > pattern as Eclipse team itself. Put an API division between API and
> > "internal" classes by putting "internal" in package path, but still you
> > can
> > export everything. Because in many cases you can't fully know how
> > adopters
> > will use the plugin and you wouldn't want to prohibit the use of it out
> of
> > the box just because the packages were exported people end up having to
> > fork the project just to use it for a specific release. If all packages
> > were exported but some marked internal then those programmers will have
> > already been warned by eclipse and if they choose to ignore it, it is on
> > them if the API breaks in the future. This way we can have best of both
> > worlds. :)
> >
> >
> > But regardless, currently in my first integration attempt I'm using the
> > following classes:
> >
> > org.apache.ivyde.eclipse.IvyNature
> > org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
> > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
> > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
> > org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
> > org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
> > org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
> >
> > Here is the code where you can see I'm calling the ivy classes:
> >
> >
>
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
>
> >
> >
> > Right now that code is all messy and just a POC. But you can see that
> I'm
> > doing 3 things:
> > -adding ivy nature
> > -adding ivy classpath container
> > -running "resolve" on classpath container
> >
> >
> > > > 2. Improved support in ResolvedPath.java class to support relative
> > > paths
> > > > that use the "../" parent path.
> > >
> > > The problem with relative paths is that they got messed up while being
> > > used within the java launcher. Maybe you can share your use case so we
> > can
> > > figure out a proper way to solve it ? For instance it would be nice if
> > you
> > > could provide a patch which is adding a test project [1].
> > >
> >
> > Sure thing, I can add a test project. In my scenario with Liferay IDE,
> > all
> > of our Ivy Projects will live in a parent folder structure that will
> > contain some shared Ivy configuration settings and also a shared ivy
> > cache. So when I configure the Ivy container, I need to use relative
> > paths
> > for the IvySettings file and the IvyUserDir like this:
> >
> >
> >
>
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
>
> >
> >
> > something like this for settings file
> > file:../../ivy-settings.xml
> >
> > and this for user dir
> > ../../.ivy
> >
> > So with my modification to ResolvedPath below it fixes it for that
> issue,
> > although that code would need to be cleaned up before I submited the
> patch
> > :)
> >
> >
>
> https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>
> >
> >
> >
> > >
> > >
> > > > You can see that I have forked the IvyDE repo over on my github
> > account
> > > and
> > > > made a few commits:
> > > > https://github.com/gamerson/ivyde/commits/liferay-ide
> > > >
> > > > Several of those commits are just my hacks in order to build the POC
> > in
> > > my
> > > > dev environment, e.g. setting up a tycho build instead of ant-based
> > > build.
> > > > The only two interesting commits are the following:
> > > >
> > > > Modified the Manifest to export all *eclipse* packages
> > > >
> > >
> >
> >
>
> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
>
> >
> > > >
> > > > Modified ResolvedPath to add support for "../.." style paths:
> > > >
> > >
> >
> >
>
> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
>
> >
> > > >
> > > > I'd like to discuss with IvyDE maintainers on how I can get these
> two
> > > > changes merged into trunk. I can create JIRA tickets and submit
> > proper
> > > > pull requests, or however, you would prefer me to try to contribute.
> > >
> > > The way to contribute code is to go through Jira. So it somehow
> clearly
> > > state that you do want to contribute your patch to the ASF, and we are
> > not
> > > picking code from you with an unclear license. (You could probably do
> a
> > > pull request, but I don't know where it would actually go…)
> > >
> >
> > Sure thing, I'll open JIRA ticket with the API export and the
> ResolvedPath
> > as those are the two blockers right now.
> >
> >
> > >
> > > > Hope to hear from you all soon and thanks again for the great IvyDE!
> > >
> > > Thank you for coming here discussing here ! :)
> > >
> >
> > Absolutely! and thanks for responding so quickly.
> >
> >
> > >
> > > Nicolas
> > >
> > > [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
> >
>
>
> --
> Greg Amerson
> Liferay Developer Tools
> Liferay, Inc. www.liferay.com
>
>
>
--
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
Antwort: Re: Re: IvyDE adopter use-cases
Posted by Ca...@gebit.de.
Hi Greg,
nature and container IDs should be as stable as an API, so it should not
be a problem to rely on them.
There's also a command org.apache.ivyde.commands.resolve, which can be
parameterized with the
project you to be resolved. Not sure if you can resolve a single ivy.xml
(in case a project has multiple).
I don't know your exact problem with ResolvedPath, but you can also
specify your ivysettings.xml
relative to a system property, environment variable, a project location,
workspace, ...
Cheers
Carsten
Von: Greg Amerson <gr...@liferay.com>
An: Ant Developers List <de...@ant.apache.org>
Datum: 03.07.2013 05:04
Betreff: Re: Re: IvyDE adopter use-cases
Hey Carsten,
Thanks for those pointers, that is good to consider, especially for the
nature and the container. The resolveall is a bit much but would rather
just resolve that single ivy.xml file. I'm sure there is a way to pass
that to an existing handler so it only resolves one.
But in general, me hard coding natureIds and container IDs is as brittle
as
calling an API, so I would prefer a real API that I could call. But until
that is settled what the API should look like, this method would work.
That only leaves the ResolvedPath changes. I can try to submit a patch
and
test project to import ResolvedPath support for parent directory relative
paths.
On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
> Hi Greg,
>
> most of what you do with the IvyDE API can be done without the IvyDE
API.
>
> 1. You can easily add the nature by using IProject.setDescription() and
> providing the Ivy nature ID as a string.
> 2. You can add the Ivy classpath container to a project's classpath with
> JavaCore.newContainerEntry(
> "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
> and adding that via IProject.setRawClasspath(). Adding your specific
> options of the container is a little
> problematic though, I agree. You would have to add all those in the
> right syntax to the container string.
> 3. You can invoke the resolving e.g. by calling ICommandService.
> getCommand("org.apache.ivyde.commands.resolveall")
> and invoking the execute() method on the command's handler.
>
> Cheers
> Carsten
>
>
> Von: Greg Amerson <gr...@liferay.com>
> An: Ant Developers List <de...@ant.apache.org>
> Datum: 02.07.2013 16:24
> Betreff: Re: IvyDE adopter use-cases
>
>
>
> Hey Nicolas,
>
> Answers inline:
>
>
> On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
> <ni...@hibnet.org>wrote:
>
> > Hi Greg,
> >
> > Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com> a
> > écrit :
> >
> > > Hello IvyDE developers,
> > >
> > > My name is Greg Amerson and I am the project lead for Liferay IDE,
> which
> > is
> > > a set of Eclipse plugins for Liferay development. In an upcoming
> version
> > > of Liferay Portal, we have integrated the use of Ivy dependency
> > management
> > > for plugin projects, e.g. liferay plugins (fancy j2ee web projects)
> that
> > > are built using JSF portlets now use Ivy to manage jsf dependencies.
> > >
> > > Therefore in Liferay IDE when our users create Liferay plugin
> projects,
> > we
> > > want users to be able to take advantage of the good support in IvyDE
> for
> > > dependency management, namely the Ivy classpath container. So for
new
> > > Liferay projects that are created by our "New Liferay Project
wizard"
> in
> > > our plugins, I want to go ahead and automatically configure that
> project
> > to
> > > have all the IvyDE goodness, (nature, container, pre-resolve the
> > container,
> > > deployment assembly configuration). In order to test things out I
> forked
> > > the latest trunk on git hub and imported it into my Eclipse SDK dev
> > > environment. I then went and built a POC for integration of Liferay
> > plugin
> > > projects enhanced with IvyDE settings. During this process I
noticed
> > that
> > > for our use-cases it seems it will require a few change to IvyDE to
> > support
> > > what we want to do:
> > >
> > >
> > > 1. MANIFEST.MF on the eclipse plugin bundle to export all packages
> (so
> > > they can be called from 3rd-party plugins like ours)
> >
> > The API of IvyDE was never properly maintained. Adding new features or
> > fixing bugs often involved changing/adding/removing some classes or
> > methods. I fear that if you rely blindly on the IvyDE "API", we may
> break
> > your plugin in the long run.
> > Maybe with your input we can start building a real API. Only the
useful
> > package would be exposed. Only the useful classes. And then we will
make
> > sure that IvyDE won't break the API of these classes.
> > We could start with the list of classes of IvyDE you are actually
using.
> >
>
> That makes total sense. However, I feel that you should follow the same
> pattern as Eclipse team itself. Put an API division between API and
> "internal" classes by putting "internal" in package path, but still you
> can
> export everything. Because in many cases you can't fully know how
> adopters
> will use the plugin and you wouldn't want to prohibit the use of it out
of
> the box just because the packages were exported people end up having to
> fork the project just to use it for a specific release. If all packages
> were exported but some marked internal then those programmers will have
> already been warned by eclipse and if they choose to ignore it, it is on
> them if the API breaks in the future. This way we can have best of both
> worlds. :)
>
>
> But regardless, currently in my first integration attempt I'm using the
> following classes:
>
> org.apache.ivyde.eclipse.IvyNature
> org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
> org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
> org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
>
> Here is the code where you can see I'm calling the ivy classes:
>
>
https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
>
>
> Right now that code is all messy and just a POC. But you can see that
I'm
> doing 3 things:
> -adding ivy nature
> -adding ivy classpath container
> -running "resolve" on classpath container
>
>
> > > 2. Improved support in ResolvedPath.java class to support relative
> > paths
> > > that use the "../" parent path.
> >
> > The problem with relative paths is that they got messed up while being
> > used within the java launcher. Maybe you can share your use case so we
> can
> > figure out a proper way to solve it ? For instance it would be nice if
> you
> > could provide a patch which is adding a test project [1].
> >
>
> Sure thing, I can add a test project. In my scenario with Liferay IDE,
> all
> of our Ivy Projects will live in a parent folder structure that will
> contain some shared Ivy configuration settings and also a shared ivy
> cache. So when I configure the Ivy container, I need to use relative
> paths
> for the IvySettings file and the IvyUserDir like this:
>
>
>
https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
>
>
> something like this for settings file
> file:../../ivy-settings.xml
>
> and this for user dir
> ../../.ivy
>
> So with my modification to ResolvedPath below it fixes it for that
issue,
> although that code would need to be cleaned up before I submited the
patch
> :)
>
>
https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>
>
>
> >
> >
> > > You can see that I have forked the IvyDE repo over on my github
> account
> > and
> > > made a few commits:
> > > https://github.com/gamerson/ivyde/commits/liferay-ide
> > >
> > > Several of those commits are just my hacks in order to build the POC
> in
> > my
> > > dev environment, e.g. setting up a tycho build instead of ant-based
> > build.
> > > The only two interesting commits are the following:
> > >
> > > Modified the Manifest to export all *eclipse* packages
> > >
> >
>
>
https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
>
> > >
> > > Modified ResolvedPath to add support for "../.." style paths:
> > >
> >
>
>
https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
>
> > >
> > > I'd like to discuss with IvyDE maintainers on how I can get these
two
> > > changes merged into trunk. I can create JIRA tickets and submit
> proper
> > > pull requests, or however, you would prefer me to try to contribute.
> >
> > The way to contribute code is to go through Jira. So it somehow
clearly
> > state that you do want to contribute your patch to the ASF, and we are
> not
> > picking code from you with an unclear license. (You could probably do
a
> > pull request, but I don't know where it would actually go…)
> >
>
> Sure thing, I'll open JIRA ticket with the API export and the
ResolvedPath
> as those are the two blockers right now.
>
>
> >
> > > Hope to hear from you all soon and thanks again for the great IvyDE!
> >
> > Thank you for coming here discussing here ! :)
> >
>
> Absolutely! and thanks for responding so quickly.
>
>
> >
> > Nicolas
> >
> > [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
--
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
Re: Re: IvyDE adopter use-cases
Posted by Greg Amerson <gr...@liferay.com>.
Hey Carsten,
Thanks for those pointers, that is good to consider, especially for the
nature and the container. The resolveall is a bit much but would rather
just resolve that single ivy.xml file. I'm sure there is a way to pass
that to an existing handler so it only resolves one.
But in general, me hard coding natureIds and container IDs is as brittle as
calling an API, so I would prefer a real API that I could call. But until
that is settled what the API should look like, this method would work.
That only leaves the ResolvedPath changes. I can try to submit a patch and
test project to import ResolvedPath support for parent directory relative
paths.
On Tue, Jul 2, 2013 at 11:09 PM, <Ca...@gebit.de> wrote:
> Hi Greg,
>
> most of what you do with the IvyDE API can be done without the IvyDE API.
>
> 1. You can easily add the nature by using IProject.setDescription() and
> providing the Ivy nature ID as a string.
> 2. You can add the Ivy classpath container to a project's classpath with
> JavaCore.newContainerEntry(
> "org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
> and adding that via IProject.setRawClasspath(). Adding your specific
> options of the container is a little
> problematic though, I agree. You would have to add all those in the
> right syntax to the container string.
> 3. You can invoke the resolving e.g. by calling ICommandService.
> getCommand("org.apache.ivyde.commands.resolveall")
> and invoking the execute() method on the command's handler.
>
> Cheers
> Carsten
>
>
> Von: Greg Amerson <gr...@liferay.com>
> An: Ant Developers List <de...@ant.apache.org>
> Datum: 02.07.2013 16:24
> Betreff: Re: IvyDE adopter use-cases
>
>
>
> Hey Nicolas,
>
> Answers inline:
>
>
> On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
> <ni...@hibnet.org>wrote:
>
> > Hi Greg,
> >
> > Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com> a
> > écrit :
> >
> > > Hello IvyDE developers,
> > >
> > > My name is Greg Amerson and I am the project lead for Liferay IDE,
> which
> > is
> > > a set of Eclipse plugins for Liferay development. In an upcoming
> version
> > > of Liferay Portal, we have integrated the use of Ivy dependency
> > management
> > > for plugin projects, e.g. liferay plugins (fancy j2ee web projects)
> that
> > > are built using JSF portlets now use Ivy to manage jsf dependencies.
> > >
> > > Therefore in Liferay IDE when our users create Liferay plugin
> projects,
> > we
> > > want users to be able to take advantage of the good support in IvyDE
> for
> > > dependency management, namely the Ivy classpath container. So for new
> > > Liferay projects that are created by our "New Liferay Project wizard"
> in
> > > our plugins, I want to go ahead and automatically configure that
> project
> > to
> > > have all the IvyDE goodness, (nature, container, pre-resolve the
> > container,
> > > deployment assembly configuration). In order to test things out I
> forked
> > > the latest trunk on git hub and imported it into my Eclipse SDK dev
> > > environment. I then went and built a POC for integration of Liferay
> > plugin
> > > projects enhanced with IvyDE settings. During this process I noticed
> > that
> > > for our use-cases it seems it will require a few change to IvyDE to
> > support
> > > what we want to do:
> > >
> > >
> > > 1. MANIFEST.MF on the eclipse plugin bundle to export all packages
> (so
> > > they can be called from 3rd-party plugins like ours)
> >
> > The API of IvyDE was never properly maintained. Adding new features or
> > fixing bugs often involved changing/adding/removing some classes or
> > methods. I fear that if you rely blindly on the IvyDE "API", we may
> break
> > your plugin in the long run.
> > Maybe with your input we can start building a real API. Only the useful
> > package would be exposed. Only the useful classes. And then we will make
> > sure that IvyDE won't break the API of these classes.
> > We could start with the list of classes of IvyDE you are actually using.
> >
>
> That makes total sense. However, I feel that you should follow the same
> pattern as Eclipse team itself. Put an API division between API and
> "internal" classes by putting "internal" in package path, but still you
> can
> export everything. Because in many cases you can't fully know how
> adopters
> will use the plugin and you wouldn't want to prohibit the use of it out of
> the box just because the packages were exported people end up having to
> fork the project just to use it for a specific release. If all packages
> were exported but some marked internal then those programmers will have
> already been warned by eclipse and if they choose to ignore it, it is on
> them if the API breaks in the future. This way we can have best of both
> worlds. :)
>
>
> But regardless, currently in my first integration attempt I'm using the
> following classes:
>
> org.apache.ivyde.eclipse.IvyNature
> org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
> org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
> org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
>
> Here is the code where you can see I'm calling the ivy classes:
>
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
>
>
> Right now that code is all messy and just a POC. But you can see that I'm
> doing 3 things:
> -adding ivy nature
> -adding ivy classpath container
> -running "resolve" on classpath container
>
>
> > > 2. Improved support in ResolvedPath.java class to support relative
> > paths
> > > that use the "../" parent path.
> >
> > The problem with relative paths is that they got messed up while being
> > used within the java launcher. Maybe you can share your use case so we
> can
> > figure out a proper way to solve it ? For instance it would be nice if
> you
> > could provide a patch which is adding a test project [1].
> >
>
> Sure thing, I can add a test project. In my scenario with Liferay IDE,
> all
> of our Ivy Projects will live in a parent folder structure that will
> contain some shared Ivy configuration settings and also a shared ivy
> cache. So when I configure the Ivy container, I need to use relative
> paths
> for the IvySettings file and the IvyUserDir like this:
>
>
> https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
>
>
> something like this for settings file
> file:../../ivy-settings.xml
>
> and this for user dir
> ../../.ivy
>
> So with my modification to ResolvedPath below it fixes it for that issue,
> although that code would need to be cleaned up before I submited the patch
> :)
>
> https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>
>
>
> >
> >
> > > You can see that I have forked the IvyDE repo over on my github
> account
> > and
> > > made a few commits:
> > > https://github.com/gamerson/ivyde/commits/liferay-ide
> > >
> > > Several of those commits are just my hacks in order to build the POC
> in
> > my
> > > dev environment, e.g. setting up a tycho build instead of ant-based
> > build.
> > > The only two interesting commits are the following:
> > >
> > > Modified the Manifest to export all *eclipse* packages
> > >
> >
>
> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
>
> > >
> > > Modified ResolvedPath to add support for "../.." style paths:
> > >
> >
>
> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
>
> > >
> > > I'd like to discuss with IvyDE maintainers on how I can get these two
> > > changes merged into trunk. I can create JIRA tickets and submit
> proper
> > > pull requests, or however, you would prefer me to try to contribute.
> >
> > The way to contribute code is to go through Jira. So it somehow clearly
> > state that you do want to contribute your patch to the ASF, and we are
> not
> > picking code from you with an unclear license. (You could probably do a
> > pull request, but I don't know where it would actually go…)
> >
>
> Sure thing, I'll open JIRA ticket with the API export and the ResolvedPath
> as those are the two blockers right now.
>
>
> >
> > > Hope to hear from you all soon and thanks again for the great IvyDE!
> >
> > Thank you for coming here discussing here ! :)
> >
>
> Absolutely! and thanks for responding so quickly.
>
>
> >
> > Nicolas
> >
> > [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
--
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
Antwort: Re: IvyDE adopter use-cases
Posted by Ca...@gebit.de.
Hi Greg,
most of what you do with the IvyDE API can be done without the IvyDE API.
1. You can easily add the nature by using IProject.setDescription() and
providing the Ivy nature ID as a string.
2. You can add the Ivy classpath container to a project's classpath with
JavaCore.newContainerEntry(
"org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER")
and adding that via IProject.setRawClasspath(). Adding your specific
options of the container is a little
problematic though, I agree. You would have to add all those in the
right syntax to the container string.
3. You can invoke the resolving e.g. by calling ICommandService.
getCommand("org.apache.ivyde.commands.resolveall")
and invoking the execute() method on the command's handler.
Cheers
Carsten
Von: Greg Amerson <gr...@liferay.com>
An: Ant Developers List <de...@ant.apache.org>
Datum: 02.07.2013 16:24
Betreff: Re: IvyDE adopter use-cases
Hey Nicolas,
Answers inline:
On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
<ni...@hibnet.org>wrote:
> Hi Greg,
>
> Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com> a
> écrit :
>
> > Hello IvyDE developers,
> >
> > My name is Greg Amerson and I am the project lead for Liferay IDE,
which
> is
> > a set of Eclipse plugins for Liferay development. In an upcoming
version
> > of Liferay Portal, we have integrated the use of Ivy dependency
> management
> > for plugin projects, e.g. liferay plugins (fancy j2ee web projects)
that
> > are built using JSF portlets now use Ivy to manage jsf dependencies.
> >
> > Therefore in Liferay IDE when our users create Liferay plugin
projects,
> we
> > want users to be able to take advantage of the good support in IvyDE
for
> > dependency management, namely the Ivy classpath container. So for new
> > Liferay projects that are created by our "New Liferay Project wizard"
in
> > our plugins, I want to go ahead and automatically configure that
project
> to
> > have all the IvyDE goodness, (nature, container, pre-resolve the
> container,
> > deployment assembly configuration). In order to test things out I
forked
> > the latest trunk on git hub and imported it into my Eclipse SDK dev
> > environment. I then went and built a POC for integration of Liferay
> plugin
> > projects enhanced with IvyDE settings. During this process I noticed
> that
> > for our use-cases it seems it will require a few change to IvyDE to
> support
> > what we want to do:
> >
> >
> > 1. MANIFEST.MF on the eclipse plugin bundle to export all packages
(so
> > they can be called from 3rd-party plugins like ours)
>
> The API of IvyDE was never properly maintained. Adding new features or
> fixing bugs often involved changing/adding/removing some classes or
> methods. I fear that if you rely blindly on the IvyDE "API", we may
break
> your plugin in the long run.
> Maybe with your input we can start building a real API. Only the useful
> package would be exposed. Only the useful classes. And then we will make
> sure that IvyDE won't break the API of these classes.
> We could start with the list of classes of IvyDE you are actually using.
>
That makes total sense. However, I feel that you should follow the same
pattern as Eclipse team itself. Put an API division between API and
"internal" classes by putting "internal" in package path, but still you
can
export everything. Because in many cases you can't fully know how
adopters
will use the plugin and you wouldn't want to prohibit the use of it out of
the box just because the packages were exported people end up having to
fork the project just to use it for a specific release. If all packages
were exported but some marked internal then those programmers will have
already been warned by eclipse and if they choose to ignore it, it is on
them if the API breaks in the future. This way we can have best of both
worlds. :)
But regardless, currently in my first integration attempt I'm using the
following classes:
org.apache.ivyde.eclipse.IvyNature
org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
Here is the code where you can see I'm calling the ivy classes:
https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
Right now that code is all messy and just a POC. But you can see that I'm
doing 3 things:
-adding ivy nature
-adding ivy classpath container
-running "resolve" on classpath container
> > 2. Improved support in ResolvedPath.java class to support relative
> paths
> > that use the "../" parent path.
>
> The problem with relative paths is that they got messed up while being
> used within the java launcher. Maybe you can share your use case so we
can
> figure out a proper way to solve it ? For instance it would be nice if
you
> could provide a patch which is adding a test project [1].
>
Sure thing, I can add a test project. In my scenario with Liferay IDE,
all
of our Ivy Projects will live in a parent folder structure that will
contain some shared Ivy configuration settings and also a shared ivy
cache. So when I configure the Ivy container, I need to use relative
paths
for the IvySettings file and the IvyUserDir like this:
https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
something like this for settings file
file:../../ivy-settings.xml
and this for user dir
../../.ivy
So with my modification to ResolvedPath below it fixes it for that issue,
although that code would need to be cleaned up before I submited the patch
:)
https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>
>
> > You can see that I have forked the IvyDE repo over on my github
account
> and
> > made a few commits:
> > https://github.com/gamerson/ivyde/commits/liferay-ide
> >
> > Several of those commits are just my hacks in order to build the POC
in
> my
> > dev environment, e.g. setting up a tycho build instead of ant-based
> build.
> > The only two interesting commits are the following:
> >
> > Modified the Manifest to export all *eclipse* packages
> >
>
https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
> >
> > Modified ResolvedPath to add support for "../.." style paths:
> >
>
https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
> >
> > I'd like to discuss with IvyDE maintainers on how I can get these two
> > changes merged into trunk. I can create JIRA tickets and submit
proper
> > pull requests, or however, you would prefer me to try to contribute.
>
> The way to contribute code is to go through Jira. So it somehow clearly
> state that you do want to contribute your patch to the ASF, and we are
not
> picking code from you with an unclear license. (You could probably do a
> pull request, but I don't know where it would actually go…)
>
Sure thing, I'll open JIRA ticket with the API export and the ResolvedPath
as those are the two blockers right now.
>
> > Hope to hear from you all soon and thanks again for the great IvyDE!
>
> Thank you for coming here discussing here ! :)
>
Absolutely! and thanks for responding so quickly.
>
> Nicolas
>
> [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
>
>
> ---------------------------------------------------------------------
> 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: IvyDE adopter use-cases
Posted by Greg Amerson <gr...@liferay.com>.
Hey Nicolas,
Answers inline:
On Tue, Jul 2, 2013 at 8:34 PM, Nicolas Lalevée
<ni...@hibnet.org>wrote:
> Hi Greg,
>
> Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com> a
> écrit :
>
> > Hello IvyDE developers,
> >
> > My name is Greg Amerson and I am the project lead for Liferay IDE, which
> is
> > a set of Eclipse plugins for Liferay development. In an upcoming version
> > of Liferay Portal, we have integrated the use of Ivy dependency
> management
> > for plugin projects, e.g. liferay plugins (fancy j2ee web projects) that
> > are built using JSF portlets now use Ivy to manage jsf dependencies.
> >
> > Therefore in Liferay IDE when our users create Liferay plugin projects,
> we
> > want users to be able to take advantage of the good support in IvyDE for
> > dependency management, namely the Ivy classpath container. So for new
> > Liferay projects that are created by our "New Liferay Project wizard" in
> > our plugins, I want to go ahead and automatically configure that project
> to
> > have all the IvyDE goodness, (nature, container, pre-resolve the
> container,
> > deployment assembly configuration). In order to test things out I forked
> > the latest trunk on git hub and imported it into my Eclipse SDK dev
> > environment. I then went and built a POC for integration of Liferay
> plugin
> > projects enhanced with IvyDE settings. During this process I noticed
> that
> > for our use-cases it seems it will require a few change to IvyDE to
> support
> > what we want to do:
> >
> >
> > 1. MANIFEST.MF on the eclipse plugin bundle to export all packages (so
> > they can be called from 3rd-party plugins like ours)
>
> The API of IvyDE was never properly maintained. Adding new features or
> fixing bugs often involved changing/adding/removing some classes or
> methods. I fear that if you rely blindly on the IvyDE "API", we may break
> your plugin in the long run.
> Maybe with your input we can start building a real API. Only the useful
> package would be exposed. Only the useful classes. And then we will make
> sure that IvyDE won't break the API of these classes.
> We could start with the list of classes of IvyDE you are actually using.
>
That makes total sense. However, I feel that you should follow the same
pattern as Eclipse team itself. Put an API division between API and
"internal" classes by putting "internal" in package path, but still you can
export everything. Because in many cases you can't fully know how adopters
will use the plugin and you wouldn't want to prohibit the use of it out of
the box just because the packages were exported people end up having to
fork the project just to use it for a specific release. If all packages
were exported but some marked internal then those programmers will have
already been warned by eclipse and if they choose to ignore it, it is on
them if the API breaks in the future. This way we can have best of both
worlds. :)
But regardless, currently in my first integration attempt I'm using the
following classes:
org.apache.ivyde.eclipse.IvyNature
org.apache.ivyde.eclipse.cpcontainer.ClasspathSetup;
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer;
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfAdapter;
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration;
org.apache.ivyde.eclipse.cpcontainer.SettingsSetup;
org.apache.ivyde.eclipse.retrieve.RetrieveSetup;
Here is the code where you can see I'm calling the ivy classes:
https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L300
Right now that code is all messy and just a POC. But you can see that I'm
doing 3 things:
-adding ivy nature
-adding ivy classpath container
-running "resolve" on classpath container
> > 2. Improved support in ResolvedPath.java class to support relative
> paths
> > that use the "../" parent path.
>
> The problem with relative paths is that they got messed up while being
> used within the java launcher. Maybe you can share your use case so we can
> figure out a proper way to solve it ? For instance it would be nice if you
> could provide a patch which is adding a test project [1].
>
Sure thing, I can add a test project. In my scenario with Liferay IDE, all
of our Ivy Projects will live in a parent folder structure that will
contain some shared Ivy configuration settings and also a shared ivy
cache. So when I configure the Ivy container, I need to use relative paths
for the IvySettings file and the IvyUserDir like this:
https://github.com/gamerson/liferay-ide/blob/94e2cde3e3e2b65587efc03b2247f5a984088420/tools/plugins/com.liferay.ide.portlet.jsf.core/src/com/liferay/ide/portlet/jsf/core/JSFPortletFrameworkWizardProvider.java#L376
something like this for settings file
file:../../ivy-settings.xml
and this for user dir
../../.ivy
So with my modification to ResolvedPath below it fixes it for that issue,
although that code would need to be cleaned up before I submited the patch
:)
https://github.com/gamerson/ivyde/blob/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/ResolvedPath.java#L103
>
>
> > You can see that I have forked the IvyDE repo over on my github account
> and
> > made a few commits:
> > https://github.com/gamerson/ivyde/commits/liferay-ide
> >
> > Several of those commits are just my hacks in order to build the POC in
> my
> > dev environment, e.g. setting up a tycho build instead of ant-based
> build.
> > The only two interesting commits are the following:
> >
> > Modified the Manifest to export all *eclipse* packages
> >
> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
> >
> > Modified ResolvedPath to add support for "../.." style paths:
> >
> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
> >
> > I'd like to discuss with IvyDE maintainers on how I can get these two
> > changes merged into trunk. I can create JIRA tickets and submit proper
> > pull requests, or however, you would prefer me to try to contribute.
>
> The way to contribute code is to go through Jira. So it somehow clearly
> state that you do want to contribute your patch to the ASF, and we are not
> picking code from you with an unclear license. (You could probably do a
> pull request, but I don't know where it would actually go…)
>
Sure thing, I'll open JIRA ticket with the API export and the ResolvedPath
as those are the two blockers right now.
>
> > Hope to hear from you all soon and thanks again for the great IvyDE!
>
> Thank you for coming here discussing here ! :)
>
Absolutely! and thanks for responding so quickly.
>
> Nicolas
>
> [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
>
>
> ---------------------------------------------------------------------
> 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: IvyDE adopter use-cases
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Hi Greg,
Le 2 juil. 2013 à 12:16, Greg Amerson <gr...@liferay.com> a écrit :
> Hello IvyDE developers,
>
> My name is Greg Amerson and I am the project lead for Liferay IDE, which is
> a set of Eclipse plugins for Liferay development. In an upcoming version
> of Liferay Portal, we have integrated the use of Ivy dependency management
> for plugin projects, e.g. liferay plugins (fancy j2ee web projects) that
> are built using JSF portlets now use Ivy to manage jsf dependencies.
>
> Therefore in Liferay IDE when our users create Liferay plugin projects, we
> want users to be able to take advantage of the good support in IvyDE for
> dependency management, namely the Ivy classpath container. So for new
> Liferay projects that are created by our "New Liferay Project wizard" in
> our plugins, I want to go ahead and automatically configure that project to
> have all the IvyDE goodness, (nature, container, pre-resolve the container,
> deployment assembly configuration). In order to test things out I forked
> the latest trunk on git hub and imported it into my Eclipse SDK dev
> environment. I then went and built a POC for integration of Liferay plugin
> projects enhanced with IvyDE settings. During this process I noticed that
> for our use-cases it seems it will require a few change to IvyDE to support
> what we want to do:
>
>
> 1. MANIFEST.MF on the eclipse plugin bundle to export all packages (so
> they can be called from 3rd-party plugins like ours)
The API of IvyDE was never properly maintained. Adding new features or fixing bugs often involved changing/adding/removing some classes or methods. I fear that if you rely blindly on the IvyDE "API", we may break your plugin in the long run.
Maybe with your input we can start building a real API. Only the useful package would be exposed. Only the useful classes. And then we will make sure that IvyDE won't break the API of these classes.
We could start with the list of classes of IvyDE you are actually using.
> 2. Improved support in ResolvedPath.java class to support relative paths
> that use the "../" parent path.
The problem with relative paths is that they got messed up while being used within the java launcher. Maybe you can share your use case so we can figure out a proper way to solve it ? For instance it would be nice if you could provide a patch which is adding a test project [1].
> You can see that I have forked the IvyDE repo over on my github account and
> made a few commits:
> https://github.com/gamerson/ivyde/commits/liferay-ide
>
> Several of those commits are just my hacks in order to build the POC in my
> dev environment, e.g. setting up a tycho build instead of ant-based build.
> The only two interesting commits are the following:
>
> Modified the Manifest to export all *eclipse* packages
> https://github.com/gamerson/ivyde/commit/29a4e2e9f4e27aabfe44f0227683a5ec20c8bc01
>
> Modified ResolvedPath to add support for "../.." style paths:
> https://github.com/gamerson/ivyde/commit/ca6db8f8b0f8b0b1c529a1e2aaaa565b37d9a5e2
>
> I'd like to discuss with IvyDE maintainers on how I can get these two
> changes merged into trunk. I can create JIRA tickets and submit proper
> pull requests, or however, you would prefer me to try to contribute.
The way to contribute code is to go through Jira. So it somehow clearly state that you do want to contribute your patch to the ASF, and we are not picking code from you with an unclear license. (You could probably do a pull request, but I don't know where it would actually go…)
> Hope to hear from you all soon and thanks again for the great IvyDE!
Thank you for coming here discussing here ! :)
Nicolas
[1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org