This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | SNAPSHOT version is deprecated | ||
---|---|---|---|
Product: | www | Reporter: | Milos Kleint <mkleint> |
Component: | Builds & Repositories | Assignee: | pgebauer <pgebauer> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jglick, pgebauer, skygo |
Priority: | P2 | ||
Version: | 7.2 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 228747 |
Description
Milos Kleint
2012-03-30 13:51:52 UTC
Has to be fixed in the repository generation script before apisupport.maven can do anything. What version name do you suggest? dev-SNAPSHOT perhaps? Any sorting considerations relative to RELEASEnn? the "maven style" versioning is RELEASE71-SNAPSHOT, then RELEASE-71, then RELEASE72-SNAPSHOT.. I guess dev-SNAPSHOT as a generic name for non-release artifacts is fine as well. Given that we will never unintentionally release the DEV version. As a result it's less work for us to remember to do on every release.. we don't use a numbering scheme, so I believe sorting doesn't apply to us. (In reply to comment #2) > the "maven style" versioning is RELEASE71-SNAPSHOT Unfortunately this would be trickier to use from maven.apisupport; prefer to have a predetermined version label. Hi, this issue allows me to wake up mine :p #207852. I look at many places but I did not find pointer for "maven framework for netbeans". 1) I am not aware why RELEASEnn scheme was choosen but why not having: 7.1.1 as a version instead RELEASE711 using number means release. RELEASEnn scheme consider 3 digits version superior as 2 digits (i.e. R711 > R72) (Sorting as a bonus) 2) I don't know when new version number of netbeans is choosen but last dev SNAPSHOT may be 7.2-SNAPSHOT for a new release. allowing a per bugfix branch 7.1.2-SNAPSHOT 3) I don't have the point using predetermined scheme versus not. If artifact version become comparable it may be possible to seek last snapshot from the repository and propose it. If maven.apisupport generate version using properties it may facilitate works for user to "migrate" to any scheme. <netbeans.version>RELEASE711</netbeans.version> <dependency> <groupId>org.netbeans.api</groupId> <artifactId>org-netbeans-modules-settings</artifactId> <version>${netbeans.version}</version> </dependency> skygo - these comments are out of scope here. For current purposes we need a single fixed string for the snapshot repository, and "SNAPSHOT" is just not allowed by Maven 3, so we need some other fixed string ending in "-SNAPSHOT". That is all. Sorry for out of scope. To make new naming more consistent I suggest having an upcased whatever string before the -SNAPSHOT. ( DEV-SNAPSHOT ) may also be NEXTRELEASE-SNAPSHOT (Next Release is a term used in wiki page on netbeans.org) The issue isn't related to any NetBeans release but to the daily trunk build. The daily build maven repository with the string dev-SNAPSHOT is available internally for testing issue 228747 depends on this. I would suggest the transition plan should include migrating to http://bits.netbeans.org/nexus/content/repositories/snapshots/ as the official URL when changing to dev-SNAPSHOT. and keeping the old snapshot repository around for a while with the old SNAPSHOT version but not upgrading it. once the new snapshot repository is created, I'll update the locations in maven archetypes and code we have.. would be nice to have before 7.4 beta, thanks I have generated a repository dev-SNAPSHOT into the URL http://bits.netbeans.org/nexus/content/repositories/snapshots/ . Could you please do a sanity check? Seems OK to me. I had a problem building an NBM app against this repo—failure to find org.netbeans.modules:org-netbeans-modules-apisupport-harness in the nbm-application module—but I think it was an issue with a *-mirror. Nice :). Tested on NBM with lots of clusters + integration test. (api ide java platform ...) worked like a charm. No checksum issue. Metadata seems also ok. (AFAIK only last build must be in snapshot metadata, that was the case for the 4th of june and 5th of june) BTW if you need specific check. Let me know. Thanks for the evolution. appears to be working for me fine for the basic scenarios and for issue 228747 (In reply to comment #11) > Seems OK to me. I had a problem building an NBM app against this repo—failure > to find org.netbeans.modules:org-netbeans-modules-apisupport-harness in the > nbm-application module—but I think it was an issue with a *-mirror. are you using 3.8/3.9 nbm maven plugin? issue 228747 fixes the problem for 3.10, but I assume for 3.8/3.9 the new or old format doesn't matter. Currently NetBeans nightly builds generate data two maven repositories: - http://bits.netbeans.org/trunk/maven-snapshot/ -> the old fashion repo with SNAPSHOT version - http://bits.netbeans.org/nexus/content/repositories/snapshots/ -> the repo with dev-SNAPSHOT version Please, let me know once I can stop data generation for the old one. (In reply to comment #13) > are you using 3.8/3.9 nbm maven plugin? 3.9 |