[nbdev] Re: Wrapper module enhancements.
- From: Ernie Rael < >
- Subject: [nbdev] Re: Wrapper module enhancements.
- Date: Thu, 28 Jun 2012 14:32:51 -0700
On 6/28/2012 2:06 PM, Gregg Wonderly wrote:
Okay, let me try and explain this better. I have a project that has a whole bunch of utility classes in it. I have this placed in a particular directory tree that is associated with all my work projects.
I have another project that is a netbeans module suite. It includes a bunch of modules, which are SPI and interface definitions for the suite. The utility project, above, is one of the modules I want to put in the suite.
That utility module also happens to be visible as an open source project that people will download and build themselves. I have no idea where they will put that project.
I want the suite project's wrapper for this utility project, to be dynamic, and I have no idea where they will put the utility project.
So, when I distribute this suite, I want the users to be able to just download the utility project and load it into netbeans,
"load it into netbeans". Does that mean open it as a NetBeans project?
and then be able to built the suite.
Thus, the suite's wrapper module, has to have a dynamic link to this utility project
"dynamic link". By project name? Without a reference to a path? There's nothing that has to be done to indicate where the utility class is accessed by the wrapper? Just open it in NetBeans. That doesn't sound right; seems like the user has to do something to set the path, or otherwise indicate to the wrapper that the downloaded utility project is where to get the jar.
so that it can be built, and the wrapper module can identity, to the suite, how to get the wrapper jar.
The workaround I'm suggesting involves changing one line in the wrapper module to set the install location (the dynamic link) of the utility project. It is probably possible to have this build property come from somewhere else (for example, can ant access the environment?)
On 6/28/2012 3:45 PM, Ernie Rael wrote:
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 ?
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
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
option in the wrapper module to "update now", or "always update" etc?
I understand there are some versioning issues that wrapper modules can be
to resolve, when they are "static" copies of some version of the project
What would it take to fix the wrapper module business to have this kind of
[nbdev] Re: Wrapper module enhancements.