Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
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
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
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
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
Issue 15 has been merged into this issue.
Original comment by samuel.a...@gmail.com
on 7 Apr 2012 at 12:17
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
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:
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
"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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
adam.waldenberg@gmail.com
on 29 Feb 2012 at 9:17Attachments: