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. > 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]. > 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…) > Hope to hear from you all soon and thanks again for the great IvyDE! Thank you for coming here discussing here ! :) 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
