[nbdev] Re: Wrapper module enhancements.

  • From: Gregg Wonderly < >
  • To:
  • Cc: Ernie Rael < >
  • Subject: [nbdev] Re: Wrapper module enhancements.
  • Date: Thu, 28 Jun 2012 16:06:51 -0500

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, and then be able to built the suite.

Thus, the suite's wrapper module, has to have a dynamic link to this utility project so that it can be built, and the wrapper module can identity, to the suite, how to get the wrapper jar.

Gregg

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.

Gregg


> -ernie

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.

Gregg

-ernie

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.

Gregg Wonderly

On 6/28/2012 10:02 AM, Gregg Wonderly wrote:
I continue to find frustration with how opaque and unproductive wrapper
modules
are.  It is hard for me to understand why a wrapper module would not be
able to
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
are
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
then not
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
wrap.

What would it take to fix the wrapper module business to have this kind of
feature set?

Gregg Wonderly




























[nbdev] Wrapper module enhancements.

Gregg Wonderly 06/28/2012

[nbdev] Re: Wrapper module enhancements.

Gregg Wonderly 06/28/2012

[nbdev] Re: Wrapper module enhancements.

Ernie Rael 06/28/2012

[nbdev] Re: Wrapper module enhancements.

Gregg Wonderly 06/28/2012

[nbdev] Re: Wrapper module enhancements.

Ernie Rael 06/28/2012

[nbdev] Re: Wrapper module enhancements.

Gregg Wonderly 06/28/2012

[nbdev] Re: Wrapper module enhancements.

Ernie Rael 06/28/2012

[nbdev] Re: Wrapper module enhancements.

Gregg Wonderly 06/28/2012

[nbdev] Re: Wrapper module enhancements.

Ernie Rael 06/28/2012

[nbdev] Re: Wrapper module enhancements.

Gregg Wonderly 06/28/2012

Project Features

About this Project

www was started in November 2009, is owned by jpirek, and has 21 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20140418.2d69abc). © 2013, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close