Maven NetBeans Module Plugin

missing update-tracking files in the created nbm-application

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 3.1
  • Fix Version/s: 3.2
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

jglick suggests to add this update tracking file as they are important for updates. They are supposed to be reconstructable from the nbm content.

Activity

Hide
Jesse Glick added a comment -

Trivially reconstructable from an NBM file (not from an unpacked cluster which has lost all information about which module bundled which file). For example, org.netbeans.nbbuild.AutoUpdate generates it.

Show
Jesse Glick added a comment - Trivially reconstructable from an NBM file (not from an unpacked cluster which has lost all information about which module bundled which file). For example, org.netbeans.nbbuild.AutoUpdate generates it.
Hide
Milos Kleint added a comment -

http://fisheye.codehaus.org/changelog/mojo/?cs=11498 should be a good start. Still need to do the same in CreateClusterMojo.
It's not that easy, the hard part is figuring what jar within the nbm is the module jar. Additionally the whole process is suboptimal. We need to create the update tracking file twice. Once before generating the nbm and then again when assembling the complete application. I'm wondering if we could somehow drop the tracking file into the nbm file and reuse it later.
Another optimization is to calculate the crc of the nbm content while copying it, not afterwards.

The AutoUpdate class is not public, just package private.

Show
Milos Kleint added a comment - http://fisheye.codehaus.org/changelog/mojo/?cs=11498 should be a good start. Still need to do the same in CreateClusterMojo. It's not that easy, the hard part is figuring what jar within the nbm is the module jar. Additionally the whole process is suboptimal. We need to create the update tracking file twice. Once before generating the nbm and then again when assembling the complete application. I'm wondering if we could somehow drop the tracking file into the nbm file and reuse it later. Another optimization is to calculate the crc of the nbm content while copying it, not afterwards. The AutoUpdate class is not public, just package private.
Hide
Jesse Glick added a comment -

"the hard part is figuring what jar within the nbm is the module jar" - I think this is just an artifact of using an Ant task in a way it was not designed for. The Ant task only uses the module property to load the manifest, which is already available in the NBM's Info/info.xml.

You're probably better off writing the code you need directly rather than trying to call into some old crufty Ant tasks; the logic is quite simple anyway.

Show
Jesse Glick added a comment - "the hard part is figuring what jar within the nbm is the module jar" - I think this is just an artifact of using an Ant task in a way it was not designed for. The Ant task only uses the module property to load the manifest, which is already available in the NBM's Info/info.xml. You're probably better off writing the code you need directly rather than trying to call into some old crufty Ant tasks; the logic is quite simple anyway.
Hide
Milos Kleint added a comment -

the reactor based cluster goal copies the expanded directories, so update tracking is there already, closing

Show
Milos Kleint added a comment - the reactor based cluster goal copies the expanded directories, so update tracking is there already, closing

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: