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
<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
