[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- WIP: See https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.parent/ and https://repository.jboss.org/nexus/index.html#nexus-search;quick~org.jbos... Next steps: 1. rename org.jboss.tools.parent.pom into parent (to conform with Maven conventions) 2. Add nexus Snapshot and release repo to all components (to resolve parent when not available locally) 3. Remove build of parent in jobs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- That would make sense. We need to find a nice name for this job. But since we are not that sure of the future of the target platform, I don't think this effort will be worth it, and I don't see anything annoying in having 2 jobs. Either we maintain backward compatibility for build (which means builder in 4.x should be able to build 3.3), either we version and branch our build elements the same way we do for anything else in the project. I am in favor of the 2nd way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- And what about the idea of replacing TP by an update-site ? I'm ok with merging both jobs, I just tried to justify my laziness. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11157: ------------------------------------ Oops, we've been doing that for 2 years now. :) That's why I mirror everything onto download.jboss.org and www.qa servers, and change URLs every time we release a major update to the TP sites. History: http://download.jboss.org/jbosstools/updates/target-platform/ (3.2.helios version) http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/ (3.3.insigo SR0 version) http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo.SR1 http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo.S... http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo.SR2/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- Basically, a TP is just a difficult to maintain composite update-site. Having the list of sites in a pom.xml and the list of features we want in a site.xml (or category.xml) would provide us the same control as we have for TP, and would be much more Maven-friendly and easy to maintain. About renaming to "parent" that changes nothing except that JBoss Tools now looks more "normal" when trying to find the parent in the M2 repo. IT is now done and nothing has changed except the name. We would not release anything on component, we will add a referece to JBoss Nexus repo in components to ensure they will be able to locate their parent from here. The release of parent or TP or whatever is done on staging repository, and we'll have to go through the process of promoting it to "release" to get components consume releases. I don't think this is an experiment any more ;) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- What is to clean up? We cannot work on improving the way parent is published and, more important consume by components, if we don't publish it to Nexus. Is your ban also true for SNAPSHOTs? I think other Tycho projects are not big enough yet to see drawbacks with target platforms. true, but we don't really need this composite update-site for our deps, we prefer an aggregated update site. Tycho allows us to make update-site of ours with more comfortable ways that using TP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- Ok, fine. There is no plan to move stuff to release at this moment. I allows us to control the set of dependencies we allow for components without using target files. I think it is easier to maintain a site.xml than a target file. Please keep in mind that I am just thinking about the Eclipse mirro "dependency" site. No, and it sounds more complicated than other alternatives ;) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- The idea would be to put stict version for features in the site.xml file, and to put the repo where we pull features in the pom. So we have explicit versions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11157: ------------------------------------ 1. Desire to have multiple TPs which are combined: see JBIDE-10915. We can have 1 top-level org.jboss.tools.target-platform.all.feature which includes everything, and child features like org.jboss.tools.target-platform.webtools.feature or org.jboss.tools.target-platform.maven.feature included in that feature. Then we build a site from that feature, and all its included features/plugins will be on the site. Sorta-kinda-exactly like the existing Target Platform sites we have today, except that instead of being built from .target -> xslt transform w/ ant -> p2.mirror, they're simply built using Tycho, a simple pom.xml, and a simple site.xml. No more XSLT, no more Ant, no more calling Eclipse to run p2.mirror. Way more cross-platform portable, and a smaller .m2 repo footprint. 2. Desire to have contents of TP be locked down to explicit versions: see JBIDE-10915. The org.jboss.tools.target-platform.*.feature will define explicit versions of IUs to be included. Same as the .target files do today, but in a format that's more easily editable / maintainable in Eclipse. AND which allows - should we way - a RANGE of acceptable versions rather than a single version. 3. Desire to have TP offline (eg., as a zip or built locally): since Tycho is more than happy to generate an update site as a zip, this requirement won't change. In fact, it'll be simpler because now I can reuse the same code in ~/trunk/build/aggregate/ to build the site and optionally insert or remove references to other sites (eg., add jboss.org URLs, remove eclipse.org URLs). This also means that the speed boost we get from caching the TP outside Jenkins and using that instead of the copy on download.jb.org ot www.qa will continue. 4. Would the site.xml control the content? NO. The feature.xml(s) would do that. Site.xml will just use 0.0.0 to fetch the versions defined in the features. 5. Does any of this talk about TPs have anything to do w/ putting the parent pom in Nexus? No, not really. Please restrict that conversation to JBIDE-10915. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- Parent job build must be merged with target platform build. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11157: ------------------------------------ Parent pom [1] only depends on target platform pom [2] (and accompanying .target file(s)), but not the target sites [3], [4]. Thus we can save time/effort/maintenance by having these two artifacts pushed to Nexus via a single job instead of 2. [1] https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... [2] https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... [3] http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.target-platform/ [4] http://hudson.qa.jboss.com/hudson/job/devstudio-5.0_trunk.target-platform/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria edited comment on JBIDE-11157 at 4/16/12 11:29 AM: ------------------------------------------------------------------ Seems like we are now sure that parent pom has to follow branch versioning. We need to find a convention. For instance 3.3.0.Beta3-SNAPSHOT is fine for Maven. Since it is currently not necessary for JBoss Tools to expose its parent pom publicly. we can in a first time keep -SNAPSHOT on all versions. We assume the required version of parent is the latest -SNAPSHOT. At this moment ne need to build and tag a specific version or something like that. was (Author: mickael_istria): Seems like we are now sure that parent pom has to follow branch versioning. We need to find a convention, 3.3.0-Beta3-SNAPSHOT Since it is currently not necessary for JBoss Tools to expose its parent pom publicly. we can in a first time keep -SNAPSHOT on all versions. We assume the required version of parent is the latest -SNAPSHOT. At this moment ne need to build and tag a specific version or something like that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11157: ------------------------------------ Please be sure to update the document detailing how to branch for a milestone [5] with this additional step, as we'll now have to: a) update parent pom every time we branch to set a new version b) update all root poms that depend on parent pom to set a new version [5] https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/2... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11157: ------------------------------------ This also means we need a job to publish the parent pom for the branch since currently we publish it only for trunk as part of the target platform job. *sigh* MOAR WERK! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- Don't worry, I don't want to create more work ;) I think such changes will make us follow the same patterns as code and will finally end by making small tasks not necessary to always backport and to ensure we can always rebuild old stuff without effort. It's investment for doing less, that's progress! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11157: ------------------------------------ Max: read this: https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/2... Numerous things change after branching so that the branch builds point at the correct composites / aggregates. This is how we avoid mixing trunk bits into the stable branch builds. Beyond the parent pom, a lot of other files have to change too. Some in trunk, some in branch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11157: ------------------------------------ So much for waiting until we branch for Beta3, eh? Did you update all the room poms including notifying component leads of the SOA projects (other SVN and Git repos) ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11157?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11157: ---------------------------------------- No I didn't. Is there a mailing-list to contact SOA people only. Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira