You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2016/02/10 16:39:48 UTC
[DISCUSS] Artifact production in test phase
I don't think we should create artifacts from test jars. I guess
hadoop-gremlin does that now and it prevents you from doing simple stuff
like:
mvn clean install -DskipTests
if it's the first time you're building a particular version (the artifact
can't be found)
[ERROR] Failed to execute goal on project spark-gremlin: Could not resolve
dependencies for project
org.apache.tinkerpop:spark-gremlin:jar:3.1.1-incubating: Failure to find
org.apache.tinkerpop:hadoop-gremlin:jar:tests:3.1.1-incubating in
http://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced -> [Help 1]
It has lead to a lot of confusion with the release and it's testing for
purpose of VOTE. Is there a really good reason that we have to structure
the project this way? Or is there some other way to change the poms so that
this works without having to first build without skipTests? What other
options are available here?
Re: [DISCUSS] Artifact production in test phase
Posted by Stephen Mallette <sp...@gmail.com>.
I don't think I mind "more modules" where it makes sense to have them. I'd
rather be able to rely on maven facilities behaving in an expected way than
worry too much about the cosmetics of additional modules. Perhaps we could
hide the "test" modules (as there should be more - gremlin-server-test is
becoming something i think that needs to exist) as sub-modules to
gremlin-test? we plan to have sub-modules for gremlin-example already so
introducing that idea doesn't seem too whacky.
On Wed, Feb 10, 2016 at 11:47 AM, Marko Rodriguez <ok...@gmail.com>
wrote:
> I hear ya, but hadoop-gremlin-test/ sucks…"yet another module."
>
> ?,
> Marko.
>
> http://markorodriguez.com
>
> On Feb 10, 2016, at 9:32 AM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
> >> Finally, I think "mvn clean install -Dmaven.test.skip=true" works fine.
> >
> > i don't think either works. that was what was in
> validate-distribution.sh
> > and it failed for folks.
> >
> > something generally seems weird/wrong to me about generating an artifact
> in
> > a test phase. doesn't feel right.
> >
> > On Wed, Feb 10, 2016 at 11:19 AM, Marko Rodriguez <ok...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> The reason I did this was because there are test classes shared between
> >> Hadoop, Giraph, and Spark. We could go the route of creating a
> >> hadoop-gremlin-test package, but dah… I almost think we should get rid
> of
> >> gremlin-groovy-test and gremlin-test and use the model in Hadoop.
> >>
> >> Finally, I think "mvn clean install -Dmaven.test.skip=true" works fine.
> >> Perhaps we can override -DskipTests to do -Dmaven.test.skip=true? I'm
> not
> >> to good with pom.xml stuff so I don't know if thats possible…
> >>
> >> Marko.
> >>
> >> http://markorodriguez.com
> >>
> >> On Feb 10, 2016, at 8:39 AM, Stephen Mallette <sp...@gmail.com>
> >> wrote:
> >>
> >>> I don't think we should create artifacts from test jars. I guess
> >>> hadoop-gremlin does that now and it prevents you from doing simple
> stuff
> >>> like:
> >>>
> >>> mvn clean install -DskipTests
> >>>
> >>> if it's the first time you're building a particular version (the
> artifact
> >>> can't be found)
> >>>
> >>> [ERROR] Failed to execute goal on project spark-gremlin: Could not
> >> resolve
> >>> dependencies for project
> >>> org.apache.tinkerpop:spark-gremlin:jar:3.1.1-incubating: Failure to
> find
> >>> org.apache.tinkerpop:hadoop-gremlin:jar:tests:3.1.1-incubating in
> >>> http://repo.maven.apache.org/maven2 was cached in the local
> repository,
> >>> resolution will not be reattempted until the update interval of central
> >> has
> >>> elapsed or updates are forced -> [Help 1]
> >>>
> >>> It has lead to a lot of confusion with the release and it's testing for
> >>> purpose of VOTE. Is there a really good reason that we have to
> structure
> >>> the project this way? Or is there some other way to change the poms so
> >> that
> >>> this works without having to first build without skipTests? What other
> >>> options are available here?
> >>
> >>
>
>
Re: [DISCUSS] Artifact production in test phase
Posted by Marko Rodriguez <ok...@gmail.com>.
I hear ya, but hadoop-gremlin-test/ sucks…"yet another module."
?,
Marko.
http://markorodriguez.com
On Feb 10, 2016, at 9:32 AM, Stephen Mallette <sp...@gmail.com> wrote:
>> Finally, I think "mvn clean install -Dmaven.test.skip=true" works fine.
>
> i don't think either works. that was what was in validate-distribution.sh
> and it failed for folks.
>
> something generally seems weird/wrong to me about generating an artifact in
> a test phase. doesn't feel right.
>
> On Wed, Feb 10, 2016 at 11:19 AM, Marko Rodriguez <ok...@gmail.com>
> wrote:
>
>> Hi,
>>
>> The reason I did this was because there are test classes shared between
>> Hadoop, Giraph, and Spark. We could go the route of creating a
>> hadoop-gremlin-test package, but dah… I almost think we should get rid of
>> gremlin-groovy-test and gremlin-test and use the model in Hadoop.
>>
>> Finally, I think "mvn clean install -Dmaven.test.skip=true" works fine.
>> Perhaps we can override -DskipTests to do -Dmaven.test.skip=true? I'm not
>> to good with pom.xml stuff so I don't know if thats possible…
>>
>> Marko.
>>
>> http://markorodriguez.com
>>
>> On Feb 10, 2016, at 8:39 AM, Stephen Mallette <sp...@gmail.com>
>> wrote:
>>
>>> I don't think we should create artifacts from test jars. I guess
>>> hadoop-gremlin does that now and it prevents you from doing simple stuff
>>> like:
>>>
>>> mvn clean install -DskipTests
>>>
>>> if it's the first time you're building a particular version (the artifact
>>> can't be found)
>>>
>>> [ERROR] Failed to execute goal on project spark-gremlin: Could not
>> resolve
>>> dependencies for project
>>> org.apache.tinkerpop:spark-gremlin:jar:3.1.1-incubating: Failure to find
>>> org.apache.tinkerpop:hadoop-gremlin:jar:tests:3.1.1-incubating in
>>> http://repo.maven.apache.org/maven2 was cached in the local repository,
>>> resolution will not be reattempted until the update interval of central
>> has
>>> elapsed or updates are forced -> [Help 1]
>>>
>>> It has lead to a lot of confusion with the release and it's testing for
>>> purpose of VOTE. Is there a really good reason that we have to structure
>>> the project this way? Or is there some other way to change the poms so
>> that
>>> this works without having to first build without skipTests? What other
>>> options are available here?
>>
>>
Re: [DISCUSS] Artifact production in test phase
Posted by Stephen Mallette <sp...@gmail.com>.
> Finally, I think "mvn clean install -Dmaven.test.skip=true" works fine.
i don't think either works. that was what was in validate-distribution.sh
and it failed for folks.
something generally seems weird/wrong to me about generating an artifact in
a test phase. doesn't feel right.
On Wed, Feb 10, 2016 at 11:19 AM, Marko Rodriguez <ok...@gmail.com>
wrote:
> Hi,
>
> The reason I did this was because there are test classes shared between
> Hadoop, Giraph, and Spark. We could go the route of creating a
> hadoop-gremlin-test package, but dah… I almost think we should get rid of
> gremlin-groovy-test and gremlin-test and use the model in Hadoop.
>
> Finally, I think "mvn clean install -Dmaven.test.skip=true" works fine.
> Perhaps we can override -DskipTests to do -Dmaven.test.skip=true? I'm not
> to good with pom.xml stuff so I don't know if thats possible…
>
> Marko.
>
> http://markorodriguez.com
>
> On Feb 10, 2016, at 8:39 AM, Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > I don't think we should create artifacts from test jars. I guess
> > hadoop-gremlin does that now and it prevents you from doing simple stuff
> > like:
> >
> > mvn clean install -DskipTests
> >
> > if it's the first time you're building a particular version (the artifact
> > can't be found)
> >
> > [ERROR] Failed to execute goal on project spark-gremlin: Could not
> resolve
> > dependencies for project
> > org.apache.tinkerpop:spark-gremlin:jar:3.1.1-incubating: Failure to find
> > org.apache.tinkerpop:hadoop-gremlin:jar:tests:3.1.1-incubating in
> > http://repo.maven.apache.org/maven2 was cached in the local repository,
> > resolution will not be reattempted until the update interval of central
> has
> > elapsed or updates are forced -> [Help 1]
> >
> > It has lead to a lot of confusion with the release and it's testing for
> > purpose of VOTE. Is there a really good reason that we have to structure
> > the project this way? Or is there some other way to change the poms so
> that
> > this works without having to first build without skipTests? What other
> > options are available here?
>
>
Re: [DISCUSS] Artifact production in test phase
Posted by Marko Rodriguez <ok...@gmail.com>.
Hi,
The reason I did this was because there are test classes shared between Hadoop, Giraph, and Spark. We could go the route of creating a hadoop-gremlin-test package, but dah… I almost think we should get rid of gremlin-groovy-test and gremlin-test and use the model in Hadoop.
Finally, I think "mvn clean install -Dmaven.test.skip=true" works fine. Perhaps we can override -DskipTests to do -Dmaven.test.skip=true? I'm not to good with pom.xml stuff so I don't know if thats possible…
Marko.
http://markorodriguez.com
On Feb 10, 2016, at 8:39 AM, Stephen Mallette <sp...@gmail.com> wrote:
> I don't think we should create artifacts from test jars. I guess
> hadoop-gremlin does that now and it prevents you from doing simple stuff
> like:
>
> mvn clean install -DskipTests
>
> if it's the first time you're building a particular version (the artifact
> can't be found)
>
> [ERROR] Failed to execute goal on project spark-gremlin: Could not resolve
> dependencies for project
> org.apache.tinkerpop:spark-gremlin:jar:3.1.1-incubating: Failure to find
> org.apache.tinkerpop:hadoop-gremlin:jar:tests:3.1.1-incubating in
> http://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced -> [Help 1]
>
> It has lead to a lot of confusion with the release and it's testing for
> purpose of VOTE. Is there a really good reason that we have to structure
> the project this way? Or is there some other way to change the poms so that
> this works without having to first build without skipTests? What other
> options are available here?