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 <gregory.amer...@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.lale...@hibnet.org> wrote:
>
>>
>> Le 3 juil. 2013 à 11:21, Greg Amerson <gregory.amer...@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
>> > <nicolas.lale...@hibnet.org>wrote:
>> >
>> >>
>> >> Le 3 juil. 2013 à 10:42, carsten.pfeif...@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 <gregory.amer...@liferay.com>
>> >>> An: Ant Developers List <dev@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, <carsten.pfeif...@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 <gregory.amer...@liferay.com>
>> >>>> An: Ant Developers List <dev@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, <carsten.pfeif...@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 <gregory.amer...@liferay.com>
>> >>>>> An: Ant Developers List <dev@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
>> >>>>> <nicolas.lale...@hibnet.org>wrote:
>> >>>>>
>> >>>>>> Hi Greg,
>> >>>>>>
>> >>>>>> Le 2 juil. 2013 à 12:16, Greg Amerson <gregory.amer...@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-unsubscr...@ant.apache.org
>> >>>>>> For additional commands, e-mail: dev-h...@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-unsubscr...@ant.apache.org
>> >> For additional commands, e-mail: dev-h...@ant.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Greg Amerson
>> > Liferay Developer Tools
>> > Liferay, Inc. www.liferay.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>
>
> --
> Greg Amerson
> Liferay Developer Tools
> Liferay, Inc. www.liferay.com
>
--
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
