grails-data-mapping: test for findWhere and repository question

[Stefan Armbruster-2]

Hi Guys,

as of now the gdm tck does not have an explicit test class for
'findWhere'. I've added that locally to the neo4j plugin, if you find it
useful for other implemenations, plz move it to
grails-datastore-gorm-tck, see http://bit.ly/MvD6Ma.

Regarding repositories being used for g-d-m: currently the build seems
to fetch all deps from http://repo.grails.org/grails/core. Is there a
reason not to add mavenCentral to the build? repo.grails.org seems to
act as a kind of cacheproxy for mavenCentral in the current
build.gradle. I'm having some problems a dependency with a classifier is
being used, e.g.
[group: "org.neo4j", name:"neo4j-kernel", version:1.8.M05,
classifier:'tests']
Additionally using repo.grails.org seems to be rather slow compared to
mavenCentral. So, any objections against adding mavenCentral to the
repository section in build.gradle?

Thx,
Stefan

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-4]

Using multiple repositories is  going to be slower than using one. The
grails/core repo proxies maven central? Why would you need maven
central as well?

Cheers

On Fri, Jun 29, 2012 at 6:09 PM, Stefan Armbruster
<[hidden email]> wrote:

> Hi Guys,
>
> as of now the gdm tck does not have an explicit test class for
> 'findWhere'. I've added that locally to the neo4j plugin, if you find it
> useful for other implemenations, plz move it to
> grails-datastore-gorm-tck, see http://bit.ly/MvD6Ma.
>
> Regarding repositories being used for g-d-m: currently the build seems
> to fetch all deps from http://repo.grails.org/grails/core. Is there a
> reason not to add mavenCentral to the build? repo.grails.org seems to
> act as a kind of cacheproxy for mavenCentral in the current
> build.gradle. I'm having some problems a dependency with a classifier is
> being used, e.g.
> [group: "org.neo4j", name:"neo4j-kernel", version:1.8.M05,
> classifier:'tests']
> Additionally using repo.grails.org seems to be rather slow compared to
> mavenCentral. So, any objections against adding mavenCentral to the
> repository section in build.gradle?
>
> Thx,
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Stefan Armbruster-2]

Hi,

did not yet receive an answer here, could you please look at the
repository question?

Regards,
Stefan

Am 29.06.2012 18:09, schrieb Stefan Armbruster:

> Hi Guys,
>
> as of now the gdm tck does not have an explicit test class for
> 'findWhere'. I've added that locally to the neo4j plugin, if you find it
> useful for other implemenations, plz move it to
> grails-datastore-gorm-tck, see http://bit.ly/MvD6Ma.
>
> Regarding repositories being used for g-d-m: currently the build seems
> to fetch all deps from http://repo.grails.org/grails/core. Is there a
> reason not to add mavenCentral to the build? repo.grails.org seems to
> act as a kind of cacheproxy for mavenCentral in the current
> build.gradle. I'm having some problems a dependency with a classifier is
> being used, e.g.
> [group: "org.neo4j", name:"neo4j-kernel", version:1.8.M05,
> classifier:'tests']
> Additionally using repo.grails.org seems to be rather slow compared to
> mavenCentral. So, any objections against adding mavenCentral to the
> repository section in build.gradle?
>
> Thx,
> Stefan
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-4]

I already answered, did you not get the below?

Cheers

On Mon, Jul 2, 2012 at 9:47 AM, Graeme Rocher <[hidden email]> wrote:

> Using multiple repositories is  going to be slower than using one. The
> grails/core repo proxies maven central? Why would you need maven
> central as well?
>
> Cheers
>
> On Fri, Jun 29, 2012 at 6:09 PM, Stefan Armbruster
> <[hidden email]> wrote:
>> Hi Guys,
>>
>> as of now the gdm tck does not have an explicit test class for
>> 'findWhere'. I've added that locally to the neo4j plugin, if you find it
>> useful for other implemenations, plz move it to
>> grails-datastore-gorm-tck, see http://bit.ly/MvD6Ma.
>>
>> Regarding repositories being used for g-d-m: currently the build seems
>> to fetch all deps from http://repo.grails.org/grails/core. Is there a
>> reason not to add mavenCentral to the build? repo.grails.org seems to
>> act as a kind of cacheproxy for mavenCentral in the current
>> build.gradle. I'm having some problems a dependency with a classifier is
>> being used, e.g.
>> [group: "org.neo4j", name:"neo4j-kernel", version:1.8.M05,
>> classifier:'tests']
>> Additionally using repo.grails.org seems to be rather slow compared to
>> mavenCentral. So, any objections against adding mavenCentral to the
>> repository section in build.gradle?
>>
>> Thx,
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> SpringSource - A Division of VMware
> http://www.springsource.com

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Stefan Armbruster-2]

Didn't receive your first answer, strange.
At first I though repo.grails.org does not proxy dependencies with
classifiers correctly. I've dropped the local gradle cache and
dependencies are now correctly fetched from repo.grails.org.

I have the feeling that whenever you request a dependency that is not
yet cached on repo.grails.org, sometimes the build shows up an
dependency error. I've observed this more than once when bumping the
version of a dependency but I did not observe a consistent pattern on
the failures.

Anyway, problem is solved for now.

Regards,
Stefan

Am 04.07.2012 09:45, schrieb Graeme Rocher:

> I already answered, did you not get the below?
>
> Cheers
>
> On Mon, Jul 2, 2012 at 9:47 AM, Graeme Rocher <[hidden email]> wrote:
>> Using multiple repositories is  going to be slower than using one. The
>> grails/core repo proxies maven central? Why would you need maven
>> central as well?
>>
>> Cheers
>>
>> On Fri, Jun 29, 2012 at 6:09 PM, Stefan Armbruster
>> <[hidden email]> wrote:
>>> Hi Guys,
>>>
>>> as of now the gdm tck does not have an explicit test class for
>>> 'findWhere'. I've added that locally to the neo4j plugin, if you find it
>>> useful for other implemenations, plz move it to
>>> grails-datastore-gorm-tck, see http://bit.ly/MvD6Ma.
>>>
>>> Regarding repositories being used for g-d-m: currently the build seems
>>> to fetch all deps from http://repo.grails.org/grails/core. Is there a
>>> reason not to add mavenCentral to the build? repo.grails.org seems to
>>> act as a kind of cacheproxy for mavenCentral in the current
>>> build.gradle. I'm having some problems a dependency with a classifier is
>>> being used, e.g.
>>> [group: "org.neo4j", name:"neo4j-kernel", version:1.8.M05,
>>> classifier:'tests']
>>> Additionally using repo.grails.org seems to be rather slow compared to
>>> mavenCentral. So, any objections against adding mavenCentral to the
>>> repository section in build.gradle?
>>>
>>> Thx,
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>>
>> --
>> Graeme Rocher
>> Grails Project Lead
>> SpringSource - A Division of VMware
>> http://www.springsource.com
>
>
>

--
Systemberatung & Softwareentwicklung | Mail: [hidden email]
Dipl.-Phys. univ. Stefan Armbruster  | Twitter: darthvader42
Kornblumenweg 5                      | Tel.: [phone]
85586 Poing                          | Fax.: [phone]
WWW: http://blog.armbruster-it.de    | Mobil: [phone]
PGP Fingerprint: F330 A4FC 6286 EB83 E7E1 6654 6075 769B 4491 04D6

 "Es genügt nicht, keine Gedanken zu haben,
man muss auch unfähig sein, sie auszudrücken."
(Karl Krauss)

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-4]

Hi Stefan,

There is a problem with Gradle's caching that occasionally results in
this issue. We have a 'clean gradle' Hudson job to solve the problem
on the build server that does:

http://hudson.grails.org/job/clean%20gradle%20cache/lastBuild/console

Hopefully it will be fixed in a future version of Gradle

Cheers

On Wed, Jul 4, 2012 at 10:55 AM, Stefan Armbruster
<[hidden email]> wrote:

> Didn't receive your first answer, strange.
> At first I though repo.grails.org does not proxy dependencies with
> classifiers correctly. I've dropped the local gradle cache and
> dependencies are now correctly fetched from repo.grails.org.
>
> I have the feeling that whenever you request a dependency that is not
> yet cached on repo.grails.org, sometimes the build shows up an
> dependency error. I've observed this more than once when bumping the
> version of a dependency but I did not observe a consistent pattern on
> the failures.
>
> Anyway, problem is solved for now.
>
> Regards,
> Stefan
>
> Am 04.07.2012 09:45, schrieb Graeme Rocher:
>> I already answered, did you not get the below?
>>
>> Cheers
>>
>> On Mon, Jul 2, 2012 at 9:47 AM, Graeme Rocher <[hidden email]> wrote:
>>> Using multiple repositories is  going to be slower than using one. The
>>> grails/core repo proxies maven central? Why would you need maven
>>> central as well?
>>>
>>> Cheers
>>>
>>> On Fri, Jun 29, 2012 at 6:09 PM, Stefan Armbruster
>>> <[hidden email]> wrote:
>>>> Hi Guys,
>>>>
>>>> as of now the gdm tck does not have an explicit test class for
>>>> 'findWhere'. I've added that locally to the neo4j plugin, if you find it
>>>> useful for other implemenations, plz move it to
>>>> grails-datastore-gorm-tck, see http://bit.ly/MvD6Ma.
>>>>
>>>> Regarding repositories being used for g-d-m: currently the build seems
>>>> to fetch all deps from http://repo.grails.org/grails/core. Is there a
>>>> reason not to add mavenCentral to the build? repo.grails.org seems to
>>>> act as a kind of cacheproxy for mavenCentral in the current
>>>> build.gradle. I'm having some problems a dependency with a classifier is
>>>> being used, e.g.
>>>> [group: "org.neo4j", name:"neo4j-kernel", version:1.8.M05,
>>>> classifier:'tests']
>>>> Additionally using repo.grails.org seems to be rather slow compared to
>>>> mavenCentral. So, any objections against adding mavenCentral to the
>>>> repository section in build.gradle?
>>>>
>>>> Thx,
>>>> Stefan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>     http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Graeme Rocher
>>> Grails Project Lead
>>> SpringSource - A Division of VMware
>>> http://www.springsource.com
>>
>>
>>
>
>
>
> --
> Systemberatung & Softwareentwicklung | Mail: [hidden email]
> Dipl.-Phys. univ. Stefan Armbruster  | Twitter: darthvader42
> Kornblumenweg 5                      | Tel.: [phone]
> 85586 Poing                          | Fax.: [phone]
> WWW: http://blog.armbruster-it.de    | Mobil: [phone]
> PGP Fingerprint: F330 A4FC 6286 EB83 E7E1 6654 6075 769B 4491 04D6
>
>  "Es genügt nicht, keine Gedanken zu haben,
> man muss auch unfähig sein, sie auszudrücken."
> (Karl Krauss)
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[zlegein]

HI all,

I have some fixes and a merge pull request that i want to publish in a
new version of the grails-dustjs-resources plugin, but need
permissions.

Publishing to Grails Central
Publishing to http://grails.org/api/v1.0/publish/dustjs-resources/0.3
| Error Error executing script PublishPlugin:
java.lang.RuntimeException: Server returned error deploying to Grails
central repository: 401 (Use --stacktrace to see the full trace)

Thanks,

-zach

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-4]

Why ask the question in an unrelated thread? Please email the dev list
with the your grails.org username in your plugin name and confirmation
you have permission from the original author

Cheers

On Wed, Jul 4, 2012 at 6:14 PM, Zach Legein <[hidden email]> wrote:

> HI all,
>
> I have some fixes and a merge pull request that i want to publish in a
> new version of the grails-dustjs-resources plugin, but need
> permissions.
>
> Publishing to Grails Central
> Publishing to http://grails.org/api/v1.0/publish/dustjs-resources/0.3
> | Error Error executing script PublishPlugin:
> java.lang.RuntimeException: Server returned error deploying to Grails
> central repository: 401 (Use --stacktrace to see the full trace)
>
> Thanks,
>
> -zach
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email