Building on OSX

[Alexander Broekhuis]

Hi,

I am trying to use this plugin on OSX and run into some problems.

First of, is there no binary plugin with cmake for OSX? When using the released version it complains about the mac configuration not being available.

Second, when trying to build it myself, I run into the following error:

"[ERROR] Failed to parse plugin descriptor for com.googlecode.cmake-maven-project:cmake-binaries-plugin:2.8.11-b4 (/Users/abroekhuis/Development/Thales/CMake-Maven/cmake-maven-project-fcdc057ab16d/cmake-binaries-plugin/target/classes): No plugin descriptor found at META-INF/maven/plugin.xml -> [Help 1]"

Does this plugin support OSX? If so, what am I doing wrong, if not, what is missing for it? OSX is fairly close to linux/unix, and could probably be made working without to much effort.

Thanks!

[Kevin S. Clarke]

It looks like there should be a cmake binary available. What's the
full exception message that you get? Can you run mvn with -e?

Regarding the source build, which versions of Java and Maven are you using?

Thanks,
Kevin

> --
> You received this message because you are subscribed to the Google Groups
> "cmake-maven-project-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cmake-maven-projec...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
"There are two kinds of people in this world: those who believe there
are two kinds of people in this world and those who know better."

[Alexander Broekhuis]

Hi,

See my comments inline below.

2014/1/31 Kevin S. Clarke <kscl...@gmail.com>

It looks like there should be a cmake binary available.  What's the
full exception message that you get?  Can you run mvn with -e?

Here you go, quite a long listing... 

-----------------------

[ERROR] Failed to execute goal com.googlecode.cmake-maven-project:cmake-maven-plugin:2.8.11-b4:generate (cmake-generate) on project example: Unable to execute mojo: Unable to find artifact. Failure to find com.googlecode.cmake-maven-project:cmake-binaries:jar:mac:2.8.11-b4 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

[ERROR] 

[ERROR] Try downloading the file manually from the project website.

[ERROR] 

[ERROR] Then, install it using the command:

[ERROR] mvn install:install-file -DgroupId=com.googlecode.cmake-maven-project -DartifactId=cmake-binaries -Dversion=2.8.11-b4 -Dclassifier=mac -Dpackaging=jar -Dfile=/path/to/file

[ERROR] 

[ERROR] Alternatively, if you host your own repository you can deploy the file there:

[ERROR] mvn deploy:deploy-file -DgroupId=com.googlecode.cmake-maven-project -DartifactId=cmake-binaries -Dversion=2.8.11-b4 -Dclassifier=mac -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

[ERROR] 

[ERROR] 

[ERROR] com.googlecode.cmake-maven-project:cmake-binaries:jar:2.8.11-b4

[ERROR] 

[ERROR] from the specified remote repositories:

[ERROR] central (http://repo.maven.apache.org/maven2, releases=true, snapshots=false)

[ERROR] -> [Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.googlecode.cmake-maven-project:cmake-maven-plugin:2.8.11-b4:generate (cmake-generate) on project example: Unable to execute mojo

at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)

at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)

at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)

at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)

at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)

at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)

at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)

at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)

at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)

at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to execute mojo

at org.twdata.maven.mojoexecutor.MojoExecutor.executeMojo(MojoExecutor.java:96)

at com.googlecode.cmakemavenproject.GenerateMojo.execute(GenerateMojo.java:146)

at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)

at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)

... 19 more

Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to find artifact.

at org.apache.maven.plugin.dependency.fromConfiguration.AbstractFromConfigurationMojo.getArtifact(AbstractFromConfigurationMojo.java:265)

at org.apache.maven.plugin.dependency.fromConfiguration.AbstractFromConfigurationMojo.getProcessedArtifactItems(AbstractFromConfigurationMojo.java:171)

at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.getProcessedArtifactItems(UnpackMojo.java:144)

at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.doExecute(UnpackMojo.java:101)

at org.apache.maven.plugin.dependency.AbstractDependencyMojo.execute(AbstractDependencyMojo.java:167)

at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)

at org.twdata.maven.mojoexecutor.MojoExecutor.executeMojo(MojoExecutor.java:94)

... 22 more

Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Failure to find com.googlecode.cmake-maven-project:cmake-binaries:jar:mac:2.8.11-b4 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

Try downloading the file manually from the project website.

Then, install it using the command: 

    mvn install:install-file -DgroupId=com.googlecode.cmake-maven-project -DartifactId=cmake-binaries -Dversion=2.8.11-b4 -Dclassifier=mac -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there: 

    mvn deploy:deploy-file -DgroupId=com.googlecode.cmake-maven-project -DartifactId=cmake-binaries -Dversion=2.8.11-b4 -Dclassifier=mac -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  com.googlecode.cmake-maven-project:cmake-binaries:jar:2.8.11-b4

from the specified remote repositories:

  central (http://repo.maven.apache.org/maven2, releases=true, snapshots=false)

at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:219)

at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:157)

at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:525)

at org.apache.maven.plugin.dependency.fromConfiguration.AbstractFromConfigurationMojo.getArtifact(AbstractFromConfigurationMojo.java:257)

... 28 more

Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failure to find com.googlecode.cmake-maven-project:cmake-binaries:jar:mac:2.8.11-b4 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

at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:538)

at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216)

at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:193)

at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:286)

at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:213)

... 31 more

Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Failure to find com.googlecode.cmake-maven-project:cmake-binaries:jar:mac:2.8.11-b4 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

at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.newException(DefaultUpdateCheckManager.java:230)

at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.checkArtifact(DefaultUpdateCheckManager.java:204)

at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:427)

... 35 more

[ERROR] 

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR] 

[ERROR] For more information about the errors and possible solutions, please read the following articles:

[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException 

-----------------------

Regarding the source build, which versions of Java and Maven are you using?

The output of mvn -v is:

-----------------------

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)

Maven home: /opt/local/share/java/maven3

Java version: 1.7.0_40, vendor: Oracle Corporation

Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "mac os x", version: "10.9", arch: "x86_64", family: "mac" 

-----------------------

If there is anything more you need, please say so.

You received this message because you are subscribed to a topic in the Google Groups "cmake-maven-project-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cmake-maven-project-users/dqc5QQ-S7Eg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cmake-maven-projec...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Met vriendelijke groet,

Alexander Broekhuis

[15 knots]

The cmake binaries jar (or zip?) is missing on central for windows, too.

2014-01-31 Alexander Broekhuis <a.bro...@gmail.com>:

[Kevin S. Clarke]

Hmm, last time was my first time releasing this project so perhaps I
did something wrong. Gili, I just ran the Maven release steps from my
Linux machine. Do I need access to Mac and Windows machines, too, to
release it?

Kevin

[Kevin S. Clarke]

I mean I knew the Mac and Linux binaries wouldn't be compiled on my
machine but I thought the plugins downloaded them on the user's side
of things as needed.

Kevin

[Kevin S. Clarke]

Bah, Mac and Windows that is.

Kevin

[Alexander Broekhuis]

Hi,

The way I see it, the artifacts have to be build and uploaded to the maven repo. I am not aware of a solution where an artifact would download some other binaries and include those on-the-fly in the artifact. But I am not that familiar with Maven, so perhaps I am completely wrong..

Besides the missing artifact, any insight why it isn't building for me when I use the source (clone)?

[cowwoc]

Kevin,

The way it works now, you're going to need to build it once per
platform. Your could conceivably rework it to work the way you mention,
but the downside is that the binaries will no longer be stored on Maven
Central and as such the plugin might stop working in the future (if the
binaries are removed by the CMake authors).

Gili

[Kevin S. Clarke]

On Fri, Jan 31, 2014 at 11:48 AM, Alexander Broekhuis
<a.bro...@gmail.com> wrote:

> The way I see it, the artifacts have to be build and uploaded to the maven
> repo. I am not aware of a solution where an artifact would download some
> other binaries and include those on-the-fly in the artifact. But I am not
> that familiar with Maven, so perhaps I am completely wrong..

I didn't write that code (binary plugin) so I may have a flawed
understanding, but my quick look at it made me think it downloaded the
binary rather than required me uploading it into the Maven central
repo. I'm at work now (and my interest in cmake isn't work related),
so can't look in more detail now, but will take a deeper look this
weekend if Gili doesn't respond first.

> Besides the missing artifact, any insight why it isn't building for me when
> I use the source (clone)?

That file should be supplied when a project has a
<packaging>maven-plugin</packaging> in the pom. Strangely the
cmake-binaries plugin doesn't seem to have a packaging element(?)

https://code.google.com/p/cmake-maven-project/source/browse/cmake-binaries/pom.xml

Try adding that to the pom and rebuilding? That's not something
that's been removed so I'm not sure why it would just break now. But
without looking into it deeper (I will this weekend), that would be my
first suggestion to try.

Kevin

[Kevin S. Clarke]

Ah, thanks Gili. So, sorry folks. Seems I screwed up the release.

Yes, that downside seems significant (not having the binaries in the
repo). I guess I'll have to redo. I can get a Windows VM easily
enough but will have to think how to get my hands on a Mac.

Kevin

[Martin Weber]

Am Freitag, 31. Januar 2014, 17:48:27 schrieb Alexander Broekhuis:
> Hi,

Hi,

>
> The way I see it, the artifacts have to be build and uploaded to the maven

At least, the binary artifacts have to be _uploaded_ to maven central in order
to download them when plugin goals get invoked. But I think that is
questionable, because

a) It would be a waste of disc space on maven central, if pre-build binaries
can be downloaded from the cmake website.

b) Consider different CPU architectures: Looking just at Linux, binaries for
x86, x86_64, ppc, arm, MIPS, and more must be uploaded. Not to mention
windos/cygwin, windos/MinGW, windos/Borland (only x86 and x86_64) and OSX
arches.

c) What if the cmake guys release a new version? Uploading all those cmake
binaries again? Are the maintainers of cmake-maven-project willing to
constantly, perpetual track new cmake releases and take action when a new
cmake is released?

d) Users of cmake-maven-project have no control on the version of cmake that
is used in their build process. Google for cmake 3.

e) Having the cmake-maven-project downloading the cmake binaries clearly is
the mavenish way to set up the build process. But that is insufficient: A
build system processor (think of make, gmake, nmake, mingw-make, ninja,
whatever) is still needed. Shouldn't compilers (C, C++, Fortran, Pascal,...)
and code generators like lex, yacc be downloaded, too? If these will be
downloaded on demand, how does cmake find them?

I think the mavenish way of downloading all required build tools comes to its
limits here. It might work for tools written in Java (platform and arch
independent).

In any case, end users of cmake-maven-project will have to install tools in
order to make the build work. And they will tend to install these in a place
where cmake is supposed to find them (using rpms, msis, debs).

My suggestion: cmake-maven-project should not even try to download cmake.
Instead, simply assume the cmake executable is in path (or PATH). And rely on
cmake to find the tools required by the generated build system. On linux, the
cmake-rpms care for that. On windos, the installer offers to put cmake in
PATH. What on OSX?

Cheers,
Martin

PS: And please refrain from top posting!


--
Cd wrttn wtht vwls s mch trsr.

[Alexander Broekhuis]

Hi,

Changing the packaging doesn't help. If I can get this working, I don't mind deploying my OSX artifact...

2014/1/31 Kevin S. Clarke <kscl...@gmail.com>

On Fri, Jan 31, 2014 at 11:48 AM, Alexander Broekhuis

--
You received this message because you are subscribed to a topic in the Google Groups "cmake-maven-project-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cmake-maven-project-users/dqc5QQ-S7Eg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cmake-maven-projec...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Kevin S. Clarke]

On Fri, Jan 31, 2014 at 4:35 PM, Martin Weber <fifteen...@gmail.com> wrote:

> a) It would be a waste of disc space on maven central, if pre-build binaries
> can be downloaded from the cmake website.

I think you make some good counterpoints to the way it's currently
done. It might be interesting to change the project to either
download a version stored in the central Maven repo or download a
"latest" version or use a system installed version (based on a
property value or something), but it's not something that would rank
high on my personal list of priorities. I've got other projects I'm
knee-deep in at the moment.

So, anyway, I've rented a Mac in the cloud now and have access to a
Windows VM, so I'll go ahead and update the binaries for Mac and
Windows versions this weekend. Again, my apologies for botching the
release.

Kevin

[Alexander Broekhuis]

Hi,

2014/1/31 Martin Weber <fifteen...@gmail.com>

At least, the binary artifacts have to be _uploaded_ to maven central in order
to download them when plugin goals get invoked. But I think that is
questionable, because

<snip> 

 

My suggestion: cmake-maven-project should not even try to download cmake.
Instead, simply assume the cmake executable is in path (or PATH). And rely on
cmake to find the tools required by the generated build system. On linux, the
cmake-rpms care for that. On windos, the installer offers to put cmake in
PATH. What on OSX?

+1 to all of this. 

Regarding CMake on OSX, similar as on Windows, on OSX the CMake installer asks to add links to one of the bin paths in PATH.

But even if the CMake executable is not on the path, it would be simple enough to add an option/parameter to the plugin which specifies the path. This way the user is always on control wrt the used CMake version.

Also, besides convenience, are there any other reasons the binaries should be on maven central? As far as I know CMake has a fairly stable API wrt configuring and generating the build files. So from that point of view, a good cmake-maven plugin would be able to work with most CMake releases without any update.

 

[Kevin S. Clarke]

Hi Alexander Broekhuis, you wrote:

> Changing the packaging doesn't help. If I can get this working, I don't mind
> deploying my OSX artifact...

Thanks, but I've rented time at macincloud.com now so I should be able
to get a Mac version uploaded. Fwiw, it built fine for me on that Mac
instance. Not sure what would be different with your setup. I assume
you did a `mvn clean` between tries?

Kevin

[Kevin S. Clarke]

On Fri, Jan 31, 2014 at 5:06 PM, Alexander Broekhuis
<a.bro...@gmail.com> wrote:

> +1 to all of this.

> [ ... ]

> Also, besides convenience, are there any other reasons the binaries should
> be on maven central? As far as I know CMake has a fairly stable API wrt
> configuring and generating the build files. So from that point of view, a
> good cmake-maven plugin would be able to work with most CMake releases
> without any update.

I agree the points were all good. One compelling counterpoint to them
(arguing in favor of storing the cmake binaries in central or, even,
pulling them at the point of building with the plugin (vs. relying on
system versions)) might just be the drop-dead simplicity of use. It's
very Maven-y to one run one command to build a project and another to
deploy it.

Kevin

[Alexander Broekhuis]

2014/1/31 Kevin S. Clarke <kscl...@gmail.com>

On Fri, Jan 31, 2014 at 5:06 PM, Alexander Broekhuis
<a.bro...@gmail.com> wrote:

I agree the points were all good.  One compelling counterpoint to them
(arguing in favor of storing the cmake binaries in central or, even,
pulling them at the point of building with the plugin (vs. relying on
system versions)) might just be the drop-dead simplicity of use.  It's
very Maven-y to one run one command to build a project and another to
deploy it.

IMHO maven sometimes tries to oversimplify things... Which in the end makes it more complicated ;). But besides that, when someone is using native code, and wants to compile it using maven-cmake, they still needs loads of other items.

For java, all these items are (most of the time) platform independent and can simply be downloaded, for native code and utilities (compilers etc) this simply is not the case. You would end up with a huge (unmaintainable) set of artifacts, and even then probably still miss platforms/compilers ;).

For me it is more than logical to have a dependency to an installed CMake version (either on the path or via some configuration). This would make maintenance of the plugin code base much simple (no need to update with each new release of CMake), and also give the user the flexibility to use the CMake version they already have installed.

[Alexander Broekhuis]

2014/1/31 Kevin S. Clarke <kscl...@gmail.com>

Thanks, but I've rented time at macincloud.com now so I should be able

to get a Mac version uploaded.  Fwiw, it built fine for me on that Mac
instance.  Not sure what would be different with your setup.  I assume
you did a `mvn clean` between tries?

I tried, but this doesn't help. I even tried removing the repository etc, but still no luck.

What maven version etc are you using? 

[Kevin S. Clarke]

On Fri, Jan 31, 2014 at 5:22 PM, Alexander Broekhuis
<a.bro...@gmail.com> wrote:
>
> IMHO maven sometimes tries to oversimplify things... Which in the end makes
> it more complicated ;). But besides that, when someone is using native code,
> and wants to compile it using maven-cmake, they still needs loads of other
> items.

I don't know that I've really arguing against you on this. The
project I'm interested in using the cmake-maven-project with does take
the approach of installing native dependencies that it doesn't find on
the system (which is why I thought a hybrid approach, like that, might
also be worthwhile for cmake-maven-project -- perhaps it's not
property driven but driven by checking for the binaries on the
system(?)).

> For me it is more than logical to have a dependency to an installed CMake
> version (either on the path or via some configuration). This would make
> maintenance of the plugin code base much simple (no need to update with each
> new release of CMake), and also give the user the flexibility to use the
> CMake version they already have installed.

Personally, I'd prefer the hybrid approach because it fits my
particular use case (I want that simplicity and can use it with what
I'm using cmake for) and, like I said, I'm happy enough with the way
it currently works (so I don't have that itch to scratch). I'm not
the project owner, though, and don't know whether patches for such
changes would entertained.

Kevin

ps: I'll let you know the Maven version on the Mac VM I've rented
later tonight. It's pretty slow to fire up and I need to get a bit
more accomplished in my work today. :-)

[cowwoc]

For what it's worth: one of the main reason I wrote this plugin is to avoid tools that assume binaries are on the PATH. After all, I could have used "exec:exec" for that.

I'd advocate the following:

• We don't build a new plugin every time a new version of cmake comes out. Whenever a new version of the plugin comes out, we build against the latest version.
• If a long time passes without a new version of the plugin, we can consider forcing a build just for the sake of updating the cmake binaries (in practice this is unlikely to happen).
• The user should have the option of using the default version of CMake (whatever the plugin was built against), a specific version found on Maven Central, or the version found on the PATH.

This should please everyone.

Also, for what it's worth I tried asking on the Maven mailing list "how much is too much" when it comes to uploading native binaries. I got no answer. It doesn't seem like anyone cares. If it gets to the point where it becomes a problem we can always make a change in the future. "Ask for forgiveness, not permission"

Have a good weekend! :)

Gili

[Alexander Broekhuis]

HI all,

2014-02-01 cowwoc <cow...@bbs.darktech.org>:

For what it's worth: one of the main reason I wrote this plugin is to avoid tools that assume binaries are on the PATH. After all, I could have used "exec:exec" for that.

I'd advocate the following:

• We don't build a new plugin every time a new version of cmake comes out. Whenever a new version of the plugin comes out, we build against the latest version.
• If a long time passes without a new version of the plugin, we can consider forcing a build just for the sake of updating the cmake binaries (in practice this is unlikely to happen).
• The user should have the option of using the default version of CMake (whatever the plugin was built against), a specific version found on Maven Central, or the version found on the PATH.

This sounds good to me (from a user point of view). Though I still like to see an option to choose the local CMake version if it is not found on the path.

Are you guys open for patches that extend the CMake support? Not saying I'll create something, but if I have some extra time and want to change some things it would be nice if they are supported upstream as well.

[Martin Weber]

Am Freitag, 31. Januar 2014, 17:05:57 schrieb Kevin S. Clarke:
> On Fri, Jan 31, 2014 at 4:35 PM, Martin Weber <fifteen...@gmail.com>
wrote:
> > a) It would be a waste of disc space on maven central, if pre-build
> > binaries can be downloaded from the cmake website.
>

[...]

>
> So, anyway, I've rented a Mac in the cloud now and have access to a
> Windows VM, so I'll go ahead and update the binaries for Mac and

'update the binaries'? Are You planning to build the binaries from the CMake
sources?
If so, just a hint: Prebuilt CMake binaries for various platforms can be found
here: <http://www.cmake.org/cmake/resources/software.html>
That site states that the zipped 'files are gziped tar files of the install
tree'. The windows zip definitely contains the install tree.

If the URLs of the binaries were stable (I'm not sure), the need to upload
them to maven central (together with the pom.xmls) can be eliminated: Let the
cmake-plugin download and extract them on demand from the *CMake site*.

> Windows versions this weekend. Again, my apologies for botching the
> release.

The release is working. On Linux. But nobody ever tried it on windos or OSX.


Martin

[Martin Weber]

Am Freitag, 31. Januar 2014, 18:36:38 schrieb cowwoc:

Hi cowwoc,

> For what it's worth: one of the main reason I wrote this plugin is to
> avoid tools that assume binaries are on the PATH. After all, I could
> have used "exec:exec" for that.
>
> I'd advocate the following:
>

> * We don't build a new plugin every time a new version of cmake comes

> out. Whenever a new version of the plugin comes out, we build
> against the latest version.

> * If a long time passes without a new version of the plugin, we can

> consider forcing a build just for the sake of updating the cmake
> binaries (in practice this is unlikely to happen).

> * The user should have the option of using the default version of

> CMake (whatever the plugin was built against), a specific version
> found on Maven Central, or the version found on the PATH.
>
> This should please everyone.

It would please me.
Giving the user an option to use the cmake command found on path (and skip
downloading) would be sufficient for me:

a) Once implemented, the cmake plugin immediately will start working on all
platform supported by cmake. (Implementation of the download stuff can wait)

b) That option can be used as a fall-back in case of no network access (I
think of building on OBS [1] here)

c) Users in the urgent need to use the latest version of cmake do not have to
wait for a new release of the plugin.

Cheers,
Martin

[1] OBS: open build service. See example project:
<https://build.opensuse.org/project/monitor/Apache>

[Kevin S. Clarke]

On Sat, Feb 1, 2014 at 10:14 AM, Martin Weber <fifteen...@gmail.com> wrote:

>> So, anyway, I've rented a Mac in the cloud now and have access to a
>> Windows VM, so I'll go ahead and update the binaries for Mac and
>
> 'update the binaries'? Are You planning to build the binaries from the CMake
> sources?

No. Just building cmake-maven-project on Windows and Mac so that the
cmake binaries for those OSes are downloaded from the upstream and
then uploaded into Maven central. I guess, conceivable, I could just
supply the Mac and Windows profile to my Linux build (and skip the
tests), but it will be good to go through the whole process on Windows
and Mac machines. Doing this now.

>> Windows versions this weekend. Again, my apologies for botching the
>> release.
>
> The release is working. On Linux. But nobody ever tried it on windos or OSX.

Yes, my fault. I'm a Linux user so that part was done. I'm fixing
the Windows and OSX issue now.

[Kevin S. Clarke]

On Fri, Jan 31, 2014 at 5:23 PM, Alexander Broekhuis
<a.bro...@gmail.com> wrote:

> What maven version etc are you using?

The version I used on the Mac was:

Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /usr/share/maven
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"

The version I used on my laptop:

Apache Maven 3.0.4
Maven home: /usr/share/maven
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "linux", version: "3.8.0-26-generic", arch: "amd64", family: "unix"

Kevin

[Alexander Broekhuis]

Hi,

2

Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /usr/share/maven
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"

Strange.. Maybe totally irrelevant, but as it still doesn't work for me, what maven commands do you use?

[Kevin S. Clarke]

Just: mvn install

Kevin

--
You received this message because you are subscribed to the Google Groups "cmake-maven-project-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cmake-maven-projec...@googlegroups.com.

[Kevin S. Clarke]

At the project/top level directory.

[Alexander Broekhuis]

Hi,

2014-02-02 Kevin S. Clarke <kscl...@gmail.com>:

At the project/top level directory.

On Feb 2, 2014 12:51 PM, "Kevin S. Clarke" <kscl...@gmail.com> wrote:

Just: mvn install

I've cloned the repository again, and now it seems to work. So I don't know what went wrong.. Probably something on my machine was mixed up.

 

Kevin

On Feb 2, 2014 4:42 AM, "Alexander Broekhuis" <a.bro...@gmail.com> wrote:

Hi,

2

Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /usr/share/maven
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"

Strange.. Maybe totally irrelevant, but as it still doesn't work for me, what maven commands do you use?

--
Met vriendelijke groet,

Alexander Broekhuis

--
You received this message because you are subscribed to the Google Groups "cmake-maven-project-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cmake-maven-projec...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

You received this message because you are subscribed to a topic in the Google Groups "cmake-maven-project-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cmake-maven-project-users/dqc5QQ-S7Eg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cmake-maven-projec...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.