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 a écrit :
> Oops! I just noticed that the ivy container path already contains the
> project name, via the first argument, ?project="
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 wrote:
> Hey Nicolas,
>
>
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
Le 3 juil. 2013 à 11:21, Greg Amerson 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
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 l
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 als
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.
Also maintenance o
Hey Carsten,
On Wed, Jul 3, 2013 at 3:53 PM, 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
Hi Greg,
nature and container IDs should be as stable as an API, so it should not
be a problem to rely on them.
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 proj
