Lack of Maven integration

[GoogleCodeExporter]

I have made a quick-n-dirty POM file that enables compilation of JavaCPP with 
Maven 3 and converted the whole project to a maven project. See attachment.

I also made an assembly.xml that creates dist zip files and I had to shuffle 
files around a little to make it conform with "maven recommendations". 

just do:

mvn install 
or
mvn package

to generate a distribution bin dist file that looks pretty much the same as the 
ones under Downloads/. It generates .zip file and includes license texts etc.

This should get you going and should be a good starting point in getting it 
accepted in the central repository.

Original issue reported on code.google.com by adam.waldenberg@gmail.com on 29 Feb 2012 at 9:17

Attachments:

• javacpp-20120229-SNAPSHOT.tar.gz

[GoogleCodeExporter]

Great, thank you so much! I'll start looking at this see how I can make 
everything work with both Ant and Maven properly...

... like, the "resources" branch is part of Maven's recommendation?

BTW, I've given you permission to modify the "Wiki", thanks in advance!

Original comment by samuel.a...@gmail.com on 29 Feb 2012 at 11:38

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Yes. Resources are packaged together with the rest of the classes and should 
consist of stuff that's not specifically java binaries.

I would almost say you can throw out the ant support altogether. The maven 
integration
in IDE's such as Netbeans and Eclipse works really well anyway.

If that's the reason for using Ant, that is :)

Original comment by adam.waldenberg@gmail.com on 29 Feb 2012 at 12:30

[GoogleCodeExporter]

Yeah, I'm just not yet a big fan of Maven downloading the whole Internet 
whenever I want to build my project :) But it does sound very useful for 
developers who want to use JavaCV/JavaCPP quickly because we can distribute the 
/binaries/ themselves, and not just the source code a la GitHub.

I think I can modify the Ant files to work with the Maven directory structure 
without too much problem... And it would also be a good occasion to switch to 
Git, now that Google Code supports it :) And while we're at it, why not GitHub? 
... Well, GitHub has advantages, but not enough IMO to offset its disadvantages 
(slow and confusing UI, the "please please please, give us money!!!" ads, the 
use of Flash to upload files, and probably lots of other annoying "features")

Original comment by samuel.a...@gmail.com on 29 Feb 2012 at 11:13

[GoogleCodeExporter]

Sounds good.

I always prefered google code myself. The Github interface just tends to piss 
me off. I never noticed any adds though...

Original comment by adam.waldenberg@gmail.com on 1 Mar 2012 at 8:12

[GoogleCodeExporter]

I was exaggerating a bit, it's nothing like SourceForge, but they have that 
"Signup and Pricing" highlighted on their top menu bar, and you would think 
that they would get some good money from Microsoft, among others, having their 
logo displayed like that on their homepage (along with "Plans, Pricing [...] 
free!") Besides, Wikipedia is less conspicuous and I feel more like given them 
money for some reason...

Original comment by samuel.a...@gmail.com on 1 Mar 2012 at 11:21

[GoogleCodeExporter]

Back to the issue at hand. If I'm to add a pom.xml file and change the 
directory structure of JavaCPP's source, I'd also like to do the same for 
JavaCV, but in that case, I'd need to do a few more things you may already be 
doing for your own project. Let me know how (if) you solved those, thanks!

The first thing is that I need to copy a bunch of ".h" files as resources 
alongside the ".class" files, but only during build. Once JavaCPP finishes 
building them, I need to delete them (or have them not added to javacv.jar).

Another thing is that after build, I get a bunch of "*.so", "*.dll", or 
whatever files in the build directory (which is fine for NetBeans to work 
properly), but I do not want to have them added to javacv.jar, since they get 
jarred up in separate files by JavaCPP, one per platform (Windows, Linux, etc.)

And finally, I need to hard code the names of those JAR files to the Class-Path 
entry of the manifest.mf file...

The answers to those questions would actually make a nice addition to the Wiki 
page for Maven! Nothing urgent, but thanks if you work this out!

Original comment by samuel.a...@gmail.com on 21 Mar 2012 at 10:21

[GoogleCodeExporter]

For the shuffling (copying) of files, I really don't know what is considered 
"best pratice", but you could use an exec block... This is how we compile 
bullet under Android for example:

<execution>
        <id>build-bullet</id>
        <phase>process-classes</phase>
        <goals>
                <goal>exec</goal>
        </goals>
        <configuration>
                <executable>${env.ANDROID_NDK_HOME}/ndk-build</executable>
                <arguments>
                        <argument>NDK_APP_OUT=${project.build.directory}</argument>
                        <argument>NDK_APP_PROJECT_PATH=${project.build.outputDirectory}</argument>
                        <argument>-j10</argument>
                </arguments>
                <workingDirectory>${basedir}</workingDirectory>
         </configuration>
</execution>

Take note of build.outputDirectory and build.directory. Ofcourse, you need to 
include the exec plugin to be able to do the above.

With a little imagination you should be able to come up with something to copy 
*.so and *.dll files during compilation.

Also... There is a "native plugin for C compilation" available, but I have not 
really used that... I think you might be able to easily pass in Maven env 
variables into a Makefile with that plugin. So that might be an alternative.

Yet another alternative is to use an execution block and an ant task for 
copying files. The exec plugin supports ant tasks.

For the manifest file, there is a maven-jar-plugin that you can use to add 
entries to the manifest. Something like this:

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
                <archive>
                         <manifestEntries>
                                 <Built-By>Anonymous dude</Built-By>
                                 <Class-Path>bobo.jar</Class-Path>
                         </manifestEntries>
                </archive>
        </configuration>
</plugin>

You can also control more specifically what should be included in the JAR using 
maven-jar-plugin.

More details here:
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html

Hope that helps :).

Original comment by adam.waldenberg@gmail.com on 21 Mar 2012 at 2:24

[GoogleCodeExporter]

Ant tasks, good idea. I guess I could always fallback on that in the worst care!

"excludes" looks like the right option to exclude files with the JAR plugin..

Thanks for your help! Sounds like I could get this done without too much 
trouble after all...

Original comment by samuel.a...@gmail.com on 22 Mar 2012 at 6:49

[GoogleCodeExporter]

Issue 15 has been merged into this issue.

Original comment by samuel.a...@gmail.com on 7 Apr 2012 at 12:17

[GoogleCodeExporter]

Ok! It's done! I've switched to Git as the source code repository and committed 
all the files to match the Maven's standard directory layout, also including 
this `pom.xml` file:
    http://code.google.com/p/javacpp/source/browse/javacpp/pom.xml
Let me know what you think, thank you!

I've also managed to get JavaCV working quite well, and found some more tricks 
you may want to add to the Wiki:
    http://code.google.com/p/javacv/source/browse/javacv/pom.xml

I must admit, Maven and JavaCPP work really well together, and although there 
are some rough edges that could use some polishing, it feels really powerful. 
For example, in JavaCV I could use the "classifier" for the artifact JAR files 
containing native libraries, and not only that, but I could hack the "profiles" 
to automatically detect the build platform, build, install, and deploy binaries 
for that platform! And manually overriding the property variable works just 
great too!

The profile hack also allows applications dependent on JavaCV to download the 
right native artifact automatically on build:
    http://code.google.com/p/javacv/source/browse/procamcalib/pom.xml

Sounds like something that could kick ass :) Thanks a lot for your help!

Original comment by samuel.a...@gmail.com on 8 Apr 2012 at 12:51

[GoogleCodeExporter]

in git, the source (pom.xml) does not compile yet with "mvn install".
This is because the project javacpp is now a project with packaging 
"maven-plugin", instead of "jar".

I think it is however a good idea to transform the Builder class to a Mojo in a 
maven-plugin, but let the main artifact be a jar, so that it can be used by 
others tools (java -jar, ant task, ...)

here is a git diff for an initial draft to add a maven-plugin to the project.

Original comment by arnaud.n...@gmail.com on 8 Apr 2012 at 9:39

Attachments:

• diff.txt

[GoogleCodeExporter]

Oops, I experimented with a Mojo, and forgot to change back the packaging to 
"jar".. I am not sure I see the advantage of it for now, until more we 
implement more features, while creating a dependency on Maven, a bad thing. Do 
you see any specific advantage that I am missing?

Original comment by samuel.a...@gmail.com on 9 Apr 2012 at 4:21

[GoogleCodeExporter]

"SNAPSHOT" seems like a valid version number in Maven and AFAIK gets handled 
correctly... Do we really need something "1.0-SNAPSHOT"?

I see there's also other changes unrelated to a Mojo or Maven in your patch. 
I'll check them out and apply as appropriate, thanks!

Original comment by samuel.a...@gmail.com on 9 Apr 2012 at 5:34

[GoogleCodeExporter]

I tested it. It works perfectly by just changing packaging to JAR. Making a 
mojo would enable us to easily specify properties directly on the command line 
to javacpp when using maven, but if you ask me it's not really necessary and 
adds additional code that will need to be maintained.

It's probably a good idea to stick to ver-SNAPSHOT as it's the standard way of 
numbering. Maven doesn't require anything specific when it comes to version 
numbers, but there are guidelines:

http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-s
yntax.html

Great work. And thanks for moving everything over to git. Bummer that the 
history isn't preserved! I thought google code would handle that. -1 for Google 
:).

Btw:

<groupId>com.googlecode.javacpp</groupId>
<artifactId>javacpp</artifactId>

should porbably be:

<groupId>com.googlecode</groupId>
<artifactId>javacpp</artifactId>

Original comment by adam.waldenberg@gmail.com on 9 Apr 2012 at 2:27

[GoogleCodeExporter]

I think this is pretty simple:
    http://code.google.com/p/javacv/source/browse/javacv/pom.xml#91
A Mojo wouldn't get us much there.. I guess if we start hacking stuff for 
conditional builds, and provide support for autoinstall and autodeploy of 
native artifacts, ok, easier than specifying it in the POM file, but anything 
else?

About the version, will Maven still do everything the same way with either 
1.0-SNAPSHOT or SNAPSHOT? I just don't want to commit to any version numbers at 
this point.

As for the history of the repository, there isn't much to see IMO, but the SVN 
server is still up:
    https://javacpp.googlecode.com/svn/?r=28
So in theory we could import it, but since all the files moved around, I felt 
it would just be a mess

Original comment by samuel.a...@gmail.com on 9 Apr 2012 at 2:53

[GoogleCodeExporter]

About the groupdId:

"groupId: This is generally unique amongst an organization or a project."
- http://maven.apache.org/pom.html#Maven_Coordinates

I don't consider myself as part of the Google Code organization, but I do 
identify myself to JavaCPP, so...

For example, this is how Plexus identifies itself:
  <groupId>org.codehaus.plexus</groupId>
  <artifactId>plexus</artifactId>

Original comment by samuel.a...@gmail.com on 9 Apr 2012 at 3:00

[GoogleCodeExporter]

Few remarks:

- on the groupId "com.googlecode.javacpp" 
It is supposed to be yours and unique because you own the internet domain name 
"code.google.com/javacpp", but you don't own the parent name "code.google.com". 
Morehower the groupId becomes a directory in your maven repository, and you can 
have several artifacts in this directory javacpp (the jar, the maven-plugin, 
jni dlls, some docs, etc..). Putting everything directly under "com.googlecode" 
would be a mess with other projects.

- on the version "1.0.0-SNAPSHOT"
Maven use the following versionning scheme with 3 version numbers: 
major-minor-fix - timestamp
A change in the major number implies big incompatibilities (a full rewrite) of 
the projet.
A change in the minor number implies a change in API, not backward compatible.
A change in the third number is supposed to be only an internal fix, without 
change in API (There are maven tools to check api changes, like animal-sniffer 
maven plugin)
Now the last part of the version "SNAPSHOT" has a very different meaning: 
during development mode, a branch is continuously under development, so the 
version "SNAPSHOT" means in maven the latest that was built for this branch and 
published to a maven repository (like nexus server). Maven is even able to use 
timestamp versionning when deploying it to nexus, by appending the YYMMddhhmmss 
autogenerated date. The publish feature is implemented in Jenkins by the action 
"deploy artifacts", when selecting a build number.
Then when you have finish your development on the branch, you do in jenkins 
"perform maven release"  (which is equivalent to maven command line "mvn 
release:prepare ; mvn release:perform"). It will automatically deploy the 
artifact with the fixed (released without the SNAPSHOT) version number, and 
increase in your branch the version number to the next snapshot number. 
example:  you are in version 1.0.0-SNAPSHOT, when you release, maven deploy the 
immutable version "1.0.0" to repositories, then edit your pom.xml to set 
"1.0.1-SNAPSHOT". 
Anybody using a maven dependency will cache the result files forever when 
getting the released version number, but they will poll to check the server at 
every recompilation (every X minutes) for the SNAPSHOT version.

- on the Mojo
it is quite easy to implements a Mojo, and configure it in a project, and 
contrarily to "ant task", you have for free many maven goodies : download with 
versionning, local repo, standard way of configuring, lifecycle phase or 
explicit executions, interactive help (mvn help:help, and mvn -X), 
documentation site, etc...

However, an even better way of doing might bethe use of javac Processor : you 
write processors that hooks themselves to javac compilation by declaring them 
in the manifest of your jar. It is less easy to configure in a standard way 
(your tool will need properties file...).

Original comment by arnaud.n...@gmail.com on 9 Apr 2012 at 7:12

[GoogleCodeExporter]

Here is a second version of the git diff file for javacpp maven plugin

Then, to test, I have added the following configuration in the pom.xml of javacv

<plugin>
   <groupId>com.googlecode.javacpp</groupId>
   <artifactId>javacpp-maven-plugin</artifactId>
   <version>1.0-SNAPSHOT</version>
   <configuration>
    <jarPrefix>javacv</jarPrefix>
    <classNames>
            <className>com.googlecode.javacv.cpp.*</className>
    </classNames>
   </configuration>
   <executions>
    <execution>
        <id>javacpp</id>
        <phase>process-classes</phase>
        <goals><goal>compile</goal></goals>
    </execution>
   </executions>
</plugin>

Unfortunatly, I am still not able to execute it on project javacv because I 
have a lot of C++ errors ...
(I took several hours configuring debian libraries, compiling opencv in the 
correct version, ...). I still have the file "opencv_adapters.h" not found, and 
then thousands of errors:

In file included from /home/arnaud/javacv/target/javacv.cpp:50:
/usr/include/libavformat/avformat.h:158: warning: ‘AVMetadata’ is 
deprecated (declared at /usr/include/libavutil/dict.h:41)
/home/arnaud/javacv/target/javacv.cpp:94: error: ISO C++ forbids declaration of 
‘AVFilterPicRef’ with no type
/home/arnaud/javacv/target/javacv.cpp:94: error: expected ‘;’ before 
‘*’ token
/home/arnaud/target/javacv.cpp:97: error: ‘AVFilterPicRef’ has not been 
declared

Original comment by arnaud.n...@gmail.com on 9 Apr 2012 at 9:20

Attachments:

• diff.txt

[GoogleCodeExporter]

Thanks for the thorough explanation of versioning with Maven! It sounds 
alright, but I am just not sure I want to stick a "1.0" in there now. If I just 
put "SNAPSHOT" for now, is Maven going to go crazy when deploying that to some 
temporary repository or when people try to use it?

About the Mojo, do you see any of the facilities available as being useful to 
JavaCPP? I am afraid I must be missing something... Anyway, I figured out one 
good reason why it should NOT be a Mojo, apart from adding a dependency on 
Maven, or a javac processor: These tools do not offer the capability to 
generate automatically C/C++ dependencies based on include files to check 
whether or not they should rebuild a given native library.

For a project with a small number of C/C++ files, we can execute JavaCPP 
directly, just like we can execute GCC to compile directly. But if we depend on 
a some large codebase in C/C++, we need to figure out a way to not build what 
we do not need to build. With GCC and GNU Make, this is done using the 
preprocessor output of some command like "gcc -M" or "gcc -MM", but nothing for 
Maven supports that, although I did fall on this discussion:
   http://markmail.org/message/pfbivcha2tbcwljk
I don't know what happened to that one. In any case, there is a lot of other 
things Maven does not support that CMake supports for C/C++, and one could 
realistically call JavaCPP from a Makefile to generate C++ files at build time, 
to use whatever feature of GNU Make. And that's the problem: We cannot use a 
Mojo inside a Makefile, unless we call Maven just to call JavaCPP, which makes 
no sense at all, unless some feature of Maven could actually be useful to 
JavaCPP... ?

As for JavaCV, it depends on quite a mess of native libraries, so unless you 
really have a lot of free time, there is probably something better to do with 
your time than trying to recompile that :) But thanks for looking into this

Original comment by samuel.a...@gmail.com on 10 Apr 2012 at 2:35

[GoogleCodeExporter]

Concerning the group id, it does not always correlate to domain names, even if 
Maven guidelines recommend it... Your reasoning about gid/artifactid isn't 
wrong. And you also indirectly "hold" javacpp.googlecode.com.

If you don't want to commit to a version number yet, you could probably just 
put 0.0.0-SNAPSHOT for now I guess. I don't see a problem with that.

In the current repository used in the Maven wiki, version numbers are just the 
release dates, but you will probably need to pick a "real" version number 
whenever you publish it to the official maven repo.

Original comment by adam.waldenberg@gmail.com on 11 Apr 2012 at 12:40

[GoogleCodeExporter]

I understand that we need a version number to get accepted on a large 
repository, but for now I think I'll stick with just SNAPSHOT. Maven appears to 
be OK with that: 
"If your version number does not match this format, then the entire version 
number is treated as being the Qualifier." 
- http://mojo.codehaus.org/versions-maven-plugin/version-rules.html

If you, Adam, have problems because of that when deploying it to your 
repository (e.g.: Is it really going to fetch the artifact on EVERY build??), 
please let me know and I'll get back to this. But for now since I don't think 
this project would be accepted right away by the central repository (?), I'll 
think about the versioning a bit more.. It's kind of annoying having to change 
the filenames of JAR files because of versioning too...

Another request I had, for Arnaud at least, I would be glad to have a mojo in 
JavaCPP, but unfortunately, right now your proposal makes JavaCPP unusable 
without Maven. If you could figure out a way to isolate the mojo stuff, it 
would be great. I guess having an AbstractMojo use the base Builder class 
should do the trick... ? The main package could even be a "maven-plugin" since 
it still produces a JAR file usable from Ant or whatever!

Other than that, I applied some of the changes from Arnaud's patch, and 
committed them to the repository, thank you very much! I hope I didn't miss 
anything important. Just one question: Why did you move class loading out from 
ClassList/ClassScanner? Another thing with the patch is that it assigns the 
system class loader as parent to our URLClassLoader. This is not a good idea, 
because then the system class loader gets priority over our URLClassLoader and 
our own production code could then more easily interfere with the build.

And about a javac processor, another issue occurs when the user wants to build 
one native library from multiple classes using JavaCPP... it just doesn't work.

Original comment by samuel.a...@gmail.com on 15 Apr 2012 at 8:52

[GoogleCodeExporter]

OK.... For the current repository, I will just change the version to the 
release date. The current version numbers i'm using in the repository are in 
the form "20120303", just as your releases are marked under Downloads. Maybe 
you could make a quick modification in the pom to that form whenever you do an 
official release.

Also.. About building one library from multiple classes, I do this with our 
bullet bindings, and it works like a charm. But maybe we are talking about 
different things?

Original comment by adam.waldenberg@gmail.com on 15 Apr 2012 at 7:59

[GoogleCodeExporter]

Btw, you can generate the JAR files from the version in the POM whenever you 
build (with the above form). IIRC I did something like that in the pom i posted 
at the top of this issue. Or even better, specify on the command-line.

A better idea might be to maybe use maven's release:prepare and let it handle 
all the manual labour for you.

Then you can just call maven release whenever you want it to build a jar with a 
specific "version" (so it is defined correctly in the pom and file name). It 
might even be possible to just automatically fetch the daily date somehow 
during the release phase ;)... I haven't done it before, though... Tell me if 
you need/want help with it.

Original comment by adam.waldenberg@gmail.com on 15 Apr 2012 at 8:08

[GoogleCodeExporter]

Oh, I noticed you were talking about javac specifically in 
http://code.google.com/p/javacpp/issues/detail?id=10#c21, please ommit the last 
section in the subsequent comment ;).

Original comment by adam.waldenberg@gmail.com on 15 Apr 2012 at 8:27

[GoogleCodeExporter]

Oh I'm sorry Arnaud, I should get my eyes checked. You did separate Builder 
into BuilderMain and BuildMojo. I had troubles applying your patch so I went on 
reading the diff file directly, not a good idea in retrospect.  I'll be 
including that BuildMojo there, but I will be limiting changes to Builder as 
much as possible, I like it the way it is :) So, could you please let me know 
if it's important that the ClassScanner /not/ load the classes, and why? Thank 
you! Also, you don't mind if I unify the license of your code to GPLv2 + 
Classpath exception and add your copyright?

Adam, the number I am using for my archives are a bit like the timestamp that 
Maven 3 appends to SNAPSHOT qualifiers: It's not a version number. I've been 
doing SNAPSHOTs all the way :) So, I guess you guys recommend we just get a 
version "1.0" or something released? And attempt to get it into the central 
repository?

About the JAR filenames, I meant that Maven automatically creates 
javacpp-1.0.jar or something, it doesn't get us javacpp.jar. This doesn't play 
well with non-Maven tools. (How would you feel if suddenly you had to call 
gcc-4.6.2 instead of gcc-4.6.3 to build the Linux kernel, for example? Any idea 
where to make that change?) Is there a way to get it to output javacpp.jar, for 
example, for "non-Maven" use under the Downloads tab for example? Besides, 
Maven appends back the version number to the filename whenever we attempt to 
install it in the local repository anyway...

Original comment by samuel.a...@gmail.com on 17 Apr 2012 at 2:32

[GoogleCodeExporter]

Ok, I was able to hack Maven's configuration to make it do all that I want from 
it! No need of scripts anymore to make my distribution packages :)

I chose to target version 0.1 ... Sounds about right to me. What do you think? 
Please let me know if there are any problems with the code in the repository 
right now or if you have other requests. In particular with these two:
http://code.google.com/p/javacpp/source/browse/javacpp/src/main/java/com/googlec
ode/javacpp/BuildMojo.java
http://code.google.com/p/javacpp/source/browse/javacpp/src/main/java/com/googlec
ode/javacpp/Builder.java

Arnaud, it looks like the system class loader is always used as default parent 
loader, but Maven creates a few other loaders, so you were right in that we 
need to set the parent manually. With that, the mojo seems to be working fine. 
In particular, I am able to build fully JavaCV with:

<plugin>
  <groupId>com.googlecode.javacpp</groupId>
  <artifactId>javacpp</artifactId>
  <version>0.1-SNAPSHOT</version>
  <configuration>
    <jarPrefix>target/javacv</jarPrefix>
    <classOrPackageName>com.googlecode.javacv.cpp.*</classOrPackageName>
  </configuration>
  <executions>
    <execution>
      <phase>process-classes</phase>
      <goals><goal>build</goal></goals>
    </execution>
  </executions>
</plugin>

However, I need this hack to compile some stuff on Windows:
http://code.google.com/p/javacv/source/browse/javacv/pom.xml#91
so I cannot use the mojo for JavaCV, but anyway, looking forward to your 
comments!

Original comment by samuel.a...@gmail.com on 21 Apr 2012 at 3:34

[GoogleCodeExporter]

Err, please do let me know if I did something wrong, said something rude, 
didn't do something that I should do... It isn't as obvious to me what looks 
like should be obvious! It's one of my weak points. Thank you for your 
understanding

Original comment by samuel.a...@gmail.com on 28 Apr 2012 at 4:11

[GoogleCodeExporter]

Don't worry Samuel. Personally, I just had a lot to do during the week, so I 
haven't been around :/. I was hoping to get a quick look at it this weekend.

I looked quickly at everything, and most of it looks good. However, I'm 
wondering if the plugin/mojo shouldn't be in a separate plugin jar instead of 
of putting it into the ordinary JavaCPP jar. It feels like a much cleaner 
solution. In that case, just make it depend on the ordinary javacpp project.

Concerning the version number, it might be better to stick to x.y.z (0.1.0) 
instead of x.y , it will give you more flexibility. If you don't need the .z 
(minor revision) part, you just dont touch it, but I found it's great for small 
bugfix releases. Ofcourse, it's up to you :).

You should be able to use the Mojo in JavaCV as well, just make sure that weird 
env variable is set before the mojo executes. Just use the setenv plugin and 
execute it earlier in the lifecycle and you should be fine. Hopefully ;). I 
haven't tried it myself, but it should hopefully work.

Other than that, everything compiles and seems to work fine. Feels like a it's 
getting time for a new release soon :).

Original comment by adam.waldenberg@gmail.com on 28 Apr 2012 at 1:50

[GoogleCodeExporter]

Ok, thanks for getting back at me!

From what I understand, Maven lets up include "optional" dependencies, i.e.:
    http://code.google.com/p/javacpp/source/browse/javacpp/pom.xml#39
so even if JavaCPP gets installed as a plugin, we should be able to use it as a 
normal JAR artifact! This way, we only need to distribute one JAR file. And the 
maven-plugin-api doesn't get copied as a dependency for projects depending on 
JavaCPP. Or did you encounter any problems using it as a normal JAR artifact? 

I thought 0.1 was the same as 0.1.0, such that we could upgrade to 0.1.1 in 
either case, or did I get that wrong? Looks like I am right though, e.g.:
    http://mojo.codehaus.org/exec-maven-plugin/exec-mojo.html
The version numbers expand from 1.0 to 1.2.1

AFAIK, we cannot change the environment variables from Java, because it's not 
portable. We can only modify it for a new subprocess, but that's exactly what 
does NOT happen when executing a mojo. I would have to include some sort of 
support in JavaCPP itself, which would have to include variable parsing or rely 
on the one from Maven... Wait a minute, we can easily do that. I've just added 
an environmentVariables configuration option to the mojo, along with some 
slight refactoring of the Builder.Main. That should work!

Yup, I guess we should make one last SNAPSHOT/timestamp release before 
submitting it to the central repository :)

Original comment by samuel.a...@gmail.com on 29 Apr 2012 at 2:59

[GoogleCodeExporter]

Sorry for being a bit slow answering.

Concerning the version number, 0.1 is indeed the same thing as 0.1.0. I just 
have the opinion that if you intend to use it, you should specify it, in the 
same way you normally specify 1.0 (and not 1). Ofcourse, that's just my opinion.

Other than that, I didn't encounter any problems (yet). My thought was that 
maybe it's not the best idea to include Maven specific classes in the main 
archive, as everyone doesn't use Maven. It will also "package" any "Maven 
classes" with the application (that uses JavaCPP) when distributing it like 
this, because they are in the ordinary jar. Then again, the same is actually 
kinda true about Builder.class and Generator.class I guess...

I'll let you think about it ;). It actually doesn't affect me, as I use 
ProGuard anyway.

In any case, I'll post the next SNAPSHOT/timestamp release in the repo when you 
release it.

Original comment by adam.waldenberg@gmail.com on 7 May 2012 at 11:26

[GoogleCodeExporter]

No worries Adam, I'll probably be busy from now on myself. I'm wondering about 
what happened with Arnaud though..

About the version number, I may just have to skip to 0.2 anyway, so I may not 
even get to 0.1.1 ;)

As for packaging, I just hate it when people distribute stuff in small pieces 
that we're supposed to put together somehow. The whole of JavaCPP is less than 
100 kB, for crying out loud! For those who /really/ care, it's still possible 
to chop it down manually or with some tool as you mentioned. Obviously, when 
Java SE gets something like JavaCPP, it will make sense to split the runtime 
components and the development components between the JRE and the JDK, because 
they already are big packages with a lot of other stuff in them.

So, anyway, I've release one last SNAPSHOT/timestamp, before probably 
submitting it to the central repository at some point...

Original comment by samuel.a...@gmail.com on 12 May 2012 at 2:37

[GoogleCodeExporter]

I figured out it's possible to host a Maven repository with Git, so I created 
one here: 
    http://maven2.javacv.googlecode.com/git/
Right now I'm simply copying files from my local repository and pushing this 
with Git manually, there must be a better way, but it doesn't look too ugly... 
What do you think?

Original comment by samuel.a...@gmail.com on 20 May 2012 at 1:30

[GoogleCodeExporter]

Oops, for JavaCPP that would be
    http://maven2.javacpp.googlecode.com/git/

Original comment by samuel.a...@gmail.com on 20 May 2012 at 1:31

[GoogleCodeExporter]

Well, I've released version 0.1! Thank you for all your guidance and support! 
The pseudo Maven repository above seems to work well enough, so, unless there 
are great advantages to having stuff in the central repository to warrant the 
paperwork and other limitations, it looks good to me for now. Comments?

Original comment by samuel.a...@gmail.com on 27 May 2012 at 11:56

• Changed state: Done

[GoogleCodeExporter]

Sorry, completely forgot to get back to you.

It's looking good! However, I would recommend generating an index in the repo. 
This allows one to list available artifacts etc and also allows for code 
completion in POM files under IDE's such as NetBeans and Eclipse.

I use the nexus-indexer for this myself, but maybe there are other tools for it 
also? We actually use a cron job that goes through the repository and 
re-generates the index from time to time. Here is the cron file, in case it 
might help:

#!/bin/sh
generate_repository_index() {
    if [ -e "$1/.index.sha1" ]; then
        ls -lR $1 | sha1sum --check $1/.index.sha1 --status

        if [ $? -eq 0 ]; then
            return 0
        fi
    fi

    java -jar /opt/bin/nexus-indexer-3.0.4-cli.jar -s -r $1 -i $1/.index -d $1/.index
    rm $1/.index/segments* $1/.index/timestamp $1/.index/*.cfs
    ls -lR $1 | sha1sum > $1/.index.sha1
    chmod -R g+w $1/.index*
    return 1
}
generate_repository_index /var/maven/public

Original comment by adam.waldenberg@gmail.com on 27 May 2012 at 12:13

[GoogleCodeExporter]

Manually? I thought Maven was supposed to make things simple. I guess it's 
simple for the artifact consumer, but deploying them appears to require much 
manual work and custom scripting... :( Will try it out eventually, thanks!

BTW, the Maven wiki page could use some updating. Let me know if you feel up to 
it! thanks

Original comment by samuel.a...@gmail.com on 31 May 2012 at 3:36

[GoogleCodeExporter]

Good news, JavaCPP has been deployed on the central repository!
https://oss.sonatype.org/content/groups/public/com/googlecode/javacpp/
Let me know if there is anything that should be fixed with that (for the next 
release), and thanks again for your help.

Original comment by samuel.a...@gmail.com on 9 Mar 2013 at 1:19

[GoogleCodeExporter]

Sorry for the slow answer :).

Anyway; great news! Thanks for all your hard work with JavaCPP; it's a great 
tool. I'll get back to you if I find something.

Original comment by adam.waldenberg@gmail.com on 19 Apr 2013 at 5:15

[GoogleCodeExporter]

Hi guys! Check the cool stuff I've been doing with Maven as build system for 
the JavaCPP Presets:
http://code.google.com/p/javacpp/source/browse?repo=presets

Original comment by samuel.a...@gmail.com on 17 Sep 2013 at 10:09