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 18:27:42 GMT
Since we already have $ivyproject_loc, having $ivyproject_name which is quite similar is not
much of a worry to me.

Nicolas

Le 3 juil. 2013 à 11:51, Greg Amerson <gregory.amerson@liferay.com> a écrit :

> Oops! I just noticed that the ivy container path already contains the
> project name, via the first argument, ?project="" so I guess I encode the
> project name in my own variable it isn't going to be making the situation
> worse.
> 
> 
> On Wed, Jul 3, 2013 at 5:43 PM, Greg Amerson <gregory.amerson@liferay.com>wrote:
> 
>> Hey Nicolas,
>> 
>> I noticed that, unfortunately all liferay plugin projects are not
>> physically nested under the workspace location but rather they have custom
>> locations.  So even though they are IProjects their locations are never
>> children of workspace root.  So unfortunately doesn't work.  However, if
>> there was another hack in there, one for the current IProject name, that
>> would be nice :)
>> 
>> ${sdk_dir:${ivyproject_name}}
>> 
>> even though that isn't a valid use of eclipse dynamic variables, if the
>> ResolvedPath would do another search and replace using the
>> IProject.getName(), that would work for me.  Then I can use the current
>> project name as an argument into my own "sdk_dir" variable that I can
>> contribute via my own Eclipse plugin.
>> 
>> What do you think?  Can you add one more hacky variable to ResolvedPath?
>> 
>> 
>> On Wed, Jul 3, 2013 at 5:31 PM, Nicolas Lalevée <
>> nicolas.lalevee@hibnet.org> wrote:
>> 
>>> 
>>> 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
>>> 
>>> 
>> 
>> 
>> --
>> 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


Mime
View raw message