[nbdev] Re: Wrapper module enhancements.
- From: Ernie Rael < >
- Subject: [nbdev] Re: Wrapper module enhancements.
- Date: Thu, 28 Jun 2012 13:45:08 -0700
On 6/28/2012 1:33 PM, Gregg Wonderly wrote:
On 6/28/2012 3:28 PM, Ernie Rael wrote:
In the wrapper's build.xml there is
<property name="original.project.dir" value="../my-project"/>
I may be misunderstanding but, AFAICT, that satisfies the criteria you've laid
out. If the jar file's project is in a common location, then a full path can be
specified in the wrapper module with the property original.project.dir and the
wrapper module can be copied anywhere.
For me, the module
which module? The java project whose jar gets wrapped?
is in a known location. But, the two modules
One of them being the wrapper?
that I have to link together, are not in the same tree. So, there is no relative path that makes sense for me, and for someone else who might download and build the project.
So, I need something more like
<property name="original.project.name" value="myproject1"/>
<property name="original.project.jar" value="build/myproject1.jar"/>
AFAIK, original.project.dir, as used in the wiki, can be an absolute path to what you call myproject1. When the wrapper is built, myproject1 is built and the jar is copied into the wrapper.
And then when I asked to build the wrapper, it should have a dependency on "myproject1" that will cause it to be built, and when that succeeds, then we know that "...myproject1.../build/myproject1.jar" is up to date and we can reference it (preferred) or copy it into the wrapper's binary dir.
On 6/28/2012 12:54 PM, Gregg Wonderly wrote:
On 6/28/2012 1:09 PM, Ernie Rael wrote:
Have you taken a look at http://wiki.netbeans.org/DevFaqWrapperModules ? "Method
2" shows a simple way to have the jar built and installed as part of the
wrapper. I agree that this would be a nice thing to have automatically, if you
specify a project, but until then ...
There isn't a "convenient" way to specify the path to the build jar. I really
need it to come from the "build" directory of the project itself so that the
projects can be placed into different directory structures as needed.
On 6/28/2012 10:52 AM, Gregg Wonderly wrote:
Let me add to this question a bit. Since the user selects a jar file, without
revealing the "project" that builds it, there isn't really enough information
to find the project and build it. So, the question would be, could the
project be designated too, and when that is done, then the build for the
wrapper module would know to build that project(s) and then copy the library
jar file into the wrapper project, or I think if the project to build was
known, the binary reference could be set to the original jar location and the
wrapper module not copy the jar into a sub directory.
If anyone has any insight into this I'd appreciate hearing it.
On 6/28/2012 10:02 AM, Gregg Wonderly wrote:
I continue to find frustration with how opaque and unproductive wrapper
are. It is hard for me to understand why a wrapper module would not be
build and extract the output of a project without having to be rewired.
The problem that I have, is that I have projects that I build for work that
in one tree, and projects I build for various open source projects that are
under other trees. So, there is never, really, a practical relative path
between projects/modules. When I export projects to open source trees, then
people may install those projects into other tree structures which will
be in a place that relative paths work.
The stuff on the http://wiki.netbeans.org/DevFaqWrapperModules page thus just
doesn't seem usable at all. Since the wrapper creation process can find the
output of the project and copy it into the module, why isn't there a switch or
option in the wrapper module to "update now", or "always update" etc?
I understand there are some versioning issues that wrapper modules can be used
to resolve, when they are "static" copies of some version of the project they
What would it take to fix the wrapper module business to have this kind of
[nbdev] Re: Wrapper module enhancements.