ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Configuring the Ivy classpath container (was: IvyDE adopter use-cases)
Date Wed, 03 Jul 2013 09:31:40 GMT

Le 3 juil. 2013 à 11:21, Greg Amerson <gregory.amerson@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.lalevee@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 <gregory.amerson@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.Pfeiffer@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.amerson@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.Pfeiffer@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.amerson@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.lalevee@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


Mime
View raw message