ant-dev mailing list archives

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