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
