> Artifact and group IDs for target-platform will change. However, profiles will be updated in parent pom to use those new artifacts, so you should not be affected by this change, but since Target Platform are a central component, it may cause a bad day if things go worse than expected. this means there will be a pom/directory for each, right ? Got a view of the new project layout/ GAV names ?

For me as a developer .target file is the window to update sites. This window lets in only those versions of bundles/feature we can use in development. For JBT it is features/bundles released for Juno 4.2.0 because I really would like to avoid issues like https://issues.jboss.org/browse/JBIDE-12248 (JBoss Tools (Indigo) Installation from Eclipse Marketplace fails for Eclipse Indigo 3.7.0 and 3.7.1). All these means .target file for JBT 4.0.x should not be changed much. The only reason to change it is to add some new dependency(ies) to it and those dependencies should have versions released for 4.2.0 for the same reason explained above. Could someone explain what are these unified/local/multiple targets below used for? It looks like they point out to latest version of Juno, which would not let to use them in development process.

>> For me as a developer .target file is the window to update sites. This window lets in only those versions of bundles/feature we can use in development. For JBT it is features/bundles released for Juno 4.2.0 because I really would like to avoid issues like https://issues.jboss.org/browse/JBIDE-12248 (JBoss Tools (Indigo) Installation from Eclipse Marketplace fails for Eclipse Indigo 3.7.0 and 3.7.1). All these means .target file for JBT 4.0.x should not be changed much. The only reason to change it is to add some new dependency(ies) to it and those dependencies should have versions released for 4.2.0 for the same reason explained above. >> >> Could someone explain what are these unified/local/multiple targets below used for? It looks like they point out to latest version of Juno, which would not let to use them in development process. > Hi Denis, > > This change we're about to make does not affect the content (plugins and features) of the target-platform. Instead it affects what is the process to publish a new platform. > I agree with you that the less often .target change for JBT, the less often we may have issues. > However, it's not the same for JBDS, for which we want the latest/greatest/stablest version of Eclipse. Both JBT and JBDS want the best and greatest to *run* against, but they both should have the "minimal compatibility" to *compile/build* against. Only the installer/product build of JBDS should use the "latest/greatest" for its binary build. > You note probably highlight the need for 2 target-platforms: the "minimal compatibiliy" for JBT, and the "Best and greatest" for JBDS. Yes. > About the file we have, I sent some mails a few month ago on this topic, I'll try to sum it up: > * multiple.target: points to the composite target site, good to use inside IDE with PDE since it also contains source (PDE is greedy and also finds sources from the composite) should really get another name than multiple.

> * local.target: if you want to perform lots of local build and save time, just run "mvn install" on local.target, you'll get all the TP repo locally, and you'll be able to consume it in your builds using the -Plocal.target profile. Not that this target is probably going to be replaced by Maven mirrors as soon as Tycho 0.16 is resolved: https://issues.jboss.org/browse/JBIDE-12608 yes, always felt wrong. > * unified.target: resolves against the aggregated target site. It's the one we recommand for "sporadic" local builds. "sporadic" ? I thought this was *the* recommended and default one used for builds ? /max

>>> About the file we have, I sent some mails a few month ago on this topic, I'll try to sum it up: >>> * multiple.target: points to the composite target site, good to use inside IDE with PDE since it also contains source (PDE is greedy and also finds sources from the composite) >> should really get another name than multiple. > why not: > multiple -> composite > local is replaced by maven mirroring > unified - > aggregated wether they are composite, aggregated, multiple or unified is rather irrelevant IMO. (its important for build setup for sure) Its whats in them that is different - one has source jars, the others dont. One is for building against, the other is for PDE. multiple shouldn't actually be used by anyone but PDE users. or unified should get these added too. ...but the build need to be very clear that the final result does not include the full target platform since that would now point to unnecessary sources /max _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

>> For me as a developer .target file is the window to update sites. This window lets in only those versions of bundles/feature we can use in development. For JBT it is features/bundles released for Juno 4.2.0 because I really would like to avoid issues like https://issues.jboss.org/browse/JBIDE-12248 (JBoss Tools (Indigo) Installation from Eclipse Marketplace fails for Eclipse Indigo 3.7.0 and 3.7.1). All these means .target file for JBT 4.0.x should not be changed much. The only reason to change it is to add some new dependency(ies) to it and those dependencies should have versions released for 4.2.0 for the same reason explained above. >> >> Could someone explain what are these unified/local/multiple targets below used for? It looks like they point out to latest version of Juno, which would not let to use them in development process. > Hi Denis, > > This change we're about to make does not affect the content (plugins and features) of the target-platform. Instead it affects what is the process to publish a new platform. > I agree with you that the less often .target change for JBT, the less often we may have issues. > However, it's not the same for JBDS, for which we want the latest/greatest/stablest version of Eclipse. Both JBT and JBDS want the best and greatest to *run* against, but they both should have the "minimal compatibility" to *compile/build* against. Only the installer/product build of JBDS should use the "latest/greatest" for its binary build.

> About the file we have, I sent some mails a few month ago on this topic, I'll try to sum it up: > * multiple.target: points to the composite target site, good to use inside IDE with PDE since it also contains source (PDE is greedy and also finds sources from the composite) should really get another name than multiple.

> * unified.target: resolves against the aggregated target site. It's the one we recommand for "sporadic" local builds. "sporadic" ? I thought this was *the* recommended and default one used for builds ?