Hi
Not sure to have the full scope. there is an outdated target “patch-for-maven” at the bottom of nbbuild/templates/projectized we can maybe take inspiration nb-repository is the plugin used for doing that work. In the current maven population for repository I have to use the download index feature to permit to use the “true” maven dependencies. Naïve interpretation: Otherwise it populate org.netbeans.external with clone of existing dependencies on central. Maybe incomplete. I guess this use is only because nb-plugin use finished artefact and is not knowing the build If we show from outside: We should cache a index of maven central (it takes time to get it 12min on apache build). If we are knowing the build We may use central coordinate from externals. Regards Eric De : Jaroslav Tulach <[email protected]> Envoyé : mercredi 4 septembre 2019 09:26 À : dev <[email protected]>; Jan Lahoda <[email protected]>; Eric Barboni <[email protected]> Objet : Allowing top down approach was: Maven experiment Hi. Jan just explained me what is going on and contrary to his suggestion in the quoted email we ended up with an idea to start converting the top-most clusters first. Maybe `enterprise`, etc. To make that possible I suggest small improvement to `nbbuild/templates/common.xml`: Let's add there a target `maven-install` - with it one could switch into any existing NetBeans project directory and just invoke: ``` $ cd platform/openide.util.lookup platform/openide.util.lookup$ ant maven-install ``` The module would build normally. However, in addition to that, Eric's NBM Maven plugin would be used to install the necessary artifacts into the local Maven repository `.m2/repository`. Of course, there would also be a way to build and install whole NetBeans: ``` nbbuild$ ant maven-install ``` Once we have it, anyone can start experimenting with changing build of for example `enterprise` cluster to Maven - as all the necessary artifacts would already be installed in the local Maven repository. Eric, do you think having `ant maven-install` is possible? I believe it would be a great enabler of the other steps. -jt út 3. 9. 2019 v 8:10 odesílatel Jan Lahoda <[email protected] <mailto:[email protected]> > napsal: Hi Robert, I'd recommend to start with platform/openide.util.lookup - the code for it does not have any dependencies, the group of its test dependencies is fairly small and self-contained, and the resulting jar is useful by itself. It also shows what Lazslo mentioned - a semi-circular dependency in test dependencies. The test dependencies for openide.util.lookup are: platform/libs.junit4 and harness/nbjunit. platform/libs.junit4 is a plain wrapped for junit4, that shouldn't be a problem. harness/nbjunit has module dependencies: harness/o.n.insane, platform/junit4 and platform/openide.util.lookup and test dependencies: platform/libs.junit4 (which is unnecessary to mention), platform/openide.util.ui, platform/openide.util and platform/openide.util.lookup. And I believe all these modules only have dependencies from this list, so this should be self-contained. Not sure what would be the next step once the openide.util.lookup would work - possibly have a working platform (i.e. everything under the platform directory, so that it would actually start), but the issue there is that the NetBeans modulesystem needs a specific filesystem structure to start. Here: https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin are tasks like: https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin/blob/master/src/main/java/org/apache/netbeans/nbm/CreateClusterAppMojo.java https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin/blob/master/src/main/java/org/apache/netbeans/nbm/CreateClusterMojo.java may be interesting there, although those are not meant to work on the base platform cluster, I believe, so I'd expect some tweaking there. A completely different approach might be to try to peel off some "leaf" clusters of modules (those that noone else is depending on them) using the existing tools above (i.e. depending on existing modules built by Ant, and "exported" to Maven - there are tools for that already). This might mean e.g. the apisupport of javafx clusters (directories in the repository). The main complication there might be that in the main NetBeans code base, tests directories may have dependencies on other test directories. So, e.g., tests of apisupport/apisupport.project.ant depend on tests of platform/openide.util.lookup (and other). So solving this might be tricky, esp. if openide.util.lookup would not be converted to Maven yet. I am eager to hear what you think/what are your experiences! Thanks, Jan On Mon, Sep 2, 2019 at 11:24 PM Robert Scholte <[email protected] <mailto:[email protected]> > wrote: > Hi, > > this month I'll be giving a training about Maven. The last part of the > session I want to use to transform existing projects to Maven. > Since Netbeans is still using Ant, it might be an interesting experiment > to see if this project can ALSO be built with Maven. > To increase the chance of success, I'd like to have an ordered list of > the > Netbeans "deliverables", starting with the least amount of internal > dependencies. > Can anybody provide me such a starting list? > > regards, > Robert Scholte > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
