Hi Rob, From a maintenance point-of-view, it would certainly improve matters for Teiid Designer since I have to update Designer's clone of the integration-stack-base.target every time a new build of locus is made. However, there is a strong possibility in the future that locus will carry multiple versions of the same plugins, eg. saxon 9.2.1 (current in locus) and 9.4 (current released stable). In that scenario, JBT-IS will have to specify both versions if some projects use one version and some projects use another version. How likely this is remains a good question!

Regards PGR On 07/31/2013 06:00 PM, Rob Cernich wrote: > Hey all, > > Recently, the JBTIS builds were broken and after a little analysis it > appears the culprit is Locus. After looking at how JBTIS is using Locus, > I'm wondering if the target files for JBTIS are incorrect. > > Currently, the target files declare specific artifact versions, but specify > the root locus repository URL. Besides the fact that the JBTIS TP is > pointing to the "integration" repository for Locus, I'm wondering if it > would be better if we pointed at a specific version of Locus and simply > specified the artifacts without version. This would require less > maintenance of the TP and should make the build more stable. That said, > the solution would only work if it is acceptable to version the > dependencies based on a specific version of Locus. Is this acceptable? > > Reference: > https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... > Specific plugin versions would go to 0.0.0, while the repository URL would > go to .../stable/locus/<some-version>. > > Thanks in advance, > Rob > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- Paul Richardson * p.g.richardson(a)phantomjinx.co.uk * p.g.richardson(a)redhat.com * pgrichardson(a)linux.com "I know exactly who reads the papers ... * The Daily Mirror is read by people who think they run the country. * The Guardian is read by people who think they ought to run the country. * The Times is read by people who do actually run the country. * The Daily Mail is read by the wives of the people who run the country. * The Financial Times is read by the people who own the country. * The Morning Star is read by the people who think the country ought to be run by another country. * The Daily Telegraph is read by the people who think it is." Jim Hacker, Yes Minister

On 07/31/2013 08:24 PM, Rob Cernich wrote:

> Isn't part of the goal of Locus to align the dependencies used by various > components? Not exactly, Locus is just aimed at providing some dependencies as OSGi bundles/p2 artifacts. It's not the place where we'll manage dependency.

> Hypothetically, what would happen if those two projects, using different > versions of saxon, were installed in the same instance of Eclipse? Unless > the plugin depending on v. 9.2.1 were configured to only use versions 9.2.x > or exactly 9.2.1, I'm guessing both projects would resolve the 9.4 version > of saxon. Personally, I think Locus, just like the TP's should be used for > coordinating these dependencies. (Just my opinion, as I haven't been > involved with any of the activity surrounding Locus. I'm sure there's a > good > pun in there somewhere;))

Both bundles resolving against Saxon 9.4 is not an issue. If it appears to be an issue, it has to be fixed in relevant MANIFEST.MF. Locus and Target Platform are not workarounds for such issues. Target Platforms are more the place where we manage dependency consistency. Having JBTIS target platform based on JBT target platform makes it easier to provide compatibility.

Basically: * MANIFEST.MF/feature.xml define dependency * Target Platforms define the set of available dependency to resolve against * Locus provides some artifacts in an Eclipse-friendly way.

-- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets

_______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Once Paul gets back we need to go over what locus is and what it isn't and find other ways to handle what was done.

It was never intended to include snapshots nor custom red hat builds of anything.

The introduction of the massive runtime dependency set from fuse makes things a lot more muddier which is what we'll need to fix/work on.

Locus is *not* a repository for usage by other p2 repositories. Locus is just for builds and They should be included not referenced. Just like eclipse orbit.

The target files is what is used to align dependencies and we should get that weeded through - for now it seems like everything fuse included just been added without much consideration besides "can it build".

Once I return from pto (national holidays here this long weekend) I'll catch up with Paul and Lars H. To see what we can/need to do.

/max (sent from my phone)

On 31/07/2013, at 22.31, Rob Cernich < rcernich(a)redhat.com > wrote:

> > On 07/31/2013 08:24 PM, Rob Cernich wrote: >

> > > Isn't part of the goal of Locus to align the dependencies used by > > > various > > > components? > > > > > Not exactly, Locus is just aimed at providing some dependencies as OSGi > > bundles/p2 artifacts. It's not the place where we'll manage dependency. >

> > > Hypothetically, what would happen if those two projects, using > > > different > > > versions of saxon, were installed in the same instance of Eclipse? > > > Unless > > > the plugin depending on v. 9.2.1 were configured to only use versions > > > 9.2.x > > > or exactly 9.2.1, I'm guessing both projects would resolve the 9.4 > > > version > > > of saxon. Personally, I think Locus, just like the TP's should be used > > > for > > > coordinating these dependencies. (Just my opinion, as I haven't been > > > involved with any of the activity surrounding Locus. I'm sure there's a > > > good > > > pun in there somewhere;)) > > >

> > Both bundles resolving against Saxon 9.4 is not an issue. If it appears > > to > > be > > an issue, it has to be fixed in relevant MANIFEST.MF. Locus and Target > > Platform are not workarounds for such issues. > > > Target Platforms are more the place where we manage dependency > > consistency. > > Having JBTIS target platform based on JBT target platform makes it easier > > to > > provide compatibility. > > Given that the target platforms align to a specific version, does it make > sense to have more than one version available in Locus? The component will > get the version specified in the TP, so why does it matter beyond that? The > only situation I can think of is where you have different versions of the > TP > pointing to the same version of Locus. Just an observation.

> > Basically: > > > * MANIFEST.MF/feature.xml define dependency > > > * Target Platforms define the set of available dependency to resolve > > against > > > * Locus provides some artifacts in an Eclipse-friendly way. >

> > -- > > > Mickael Istria > > > Eclipse developer at JBoss, by Red Hat > > > My blog - My Tweets >

> > _______________________________________________ > > > jbosstools-dev mailing list > > > jbosstools-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev >

> _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

I just noticed that Locus is including a bunch of site references to juno sites, e.g. http://download.jboss.org/jbosstools/updates/development/juno/

I don't think there is any reason why a site like Locus should be referencing other update sites.

----- Original Message -----

> Sounds good. Please let me know if you need me to do anything.

----- Original Message -----

> > Once Paul gets back we need to go over what locus is and what it isn't > > and > > find other ways to handle what was done. >

> > It was never intended to include snapshots nor custom red hat builds of > > anything. >

> > The introduction of the massive runtime dependency set from fuse makes > > things > > a lot more muddier which is what we'll need to fix/work on. >

> > Locus is *not* a repository for usage by other p2 repositories. Locus is > > just > > for builds and They should be included not referenced. Just like eclipse > > orbit. >

> > The target files is what is used to align dependencies and we should get > > that > > weeded through - for now it seems like everything fuse included just been > > added without much consideration besides "can it build". >

> > Once I return from pto (national holidays here this long weekend) I'll > > catch > > up with Paul and Lars H. To see what we can/need to do. >

> > /max (sent from my phone) >

> > On 31/07/2013, at 22.31, Rob Cernich < rcernich(a)redhat.com > wrote: >

> > > > On 07/31/2013 08:24 PM, Rob Cernich wrote: > > > > > >

> > > > > Isn't part of the goal of Locus to align the dependencies used by > > > > > various > > > > > components? > > > > > > > > > > > > > > Not exactly, Locus is just aimed at providing some dependencies as > > > > OSGi > > > > bundles/p2 artifacts. It's not the place where we'll manage > > > > dependency. > > > > > >

> > > > > Hypothetically, what would happen if those two projects, using > > > > > different > > > > > versions of saxon, were installed in the same instance of Eclipse? > > > > > Unless > > > > > the plugin depending on v. 9.2.1 were configured to only use > > > > > versions > > > > > 9.2.x > > > > > or exactly 9.2.1, I'm guessing both projects would resolve the 9.4 > > > > > version > > > > > of saxon. Personally, I think Locus, just like the TP's should be > > > > > used > > > > > for > > > > > coordinating these dependencies. (Just my opinion, as I haven't > > > > > been > > > > > involved with any of the activity surrounding Locus. I'm sure > > > > > there's > > > > > a > > > > > good > > > > > pun in there somewhere;)) > > > > > > > > > >

> > > > Both bundles resolving against Saxon 9.4 is not an issue. If it > > > > appears > > > > to > > > > be > > > > an issue, it has to be fixed in relevant MANIFEST.MF. Locus and > > > > Target > > > > Platform are not workarounds for such issues. > > > > > > > > > > Target Platforms are more the place where we manage dependency > > > > consistency. > > > > Having JBTIS target platform based on JBT target platform makes it > > > > easier > > > > to > > > > provide compatibility. > > > > > > > > > Given that the target platforms align to a specific version, does it > > > make > > > sense to have more than one version available in Locus? The component > > > will > > > get the version specified in the TP, so why does it matter beyond that? > > > The > > > only situation I can think of is where you have different versions of > > > the > > > TP > > > pointing to the same version of Locus. Just an observation. > > >

> > > > Basically: > > > > > > > > > > * MANIFEST.MF/feature.xml define dependency > > > > > > > > > > * Target Platforms define the set of available dependency to resolve > > > > against > > > > > > > > > > * Locus provides some artifacts in an Eclipse-friendly way. > > > > > >

> > > > -- > > > > > > > > > > Mickael Istria > > > > > > > > > > Eclipse developer at JBoss, by Red Hat > > > > > > > > > > My blog - My Tweets > > > > > >

> > > > _______________________________________________ > > > > > > > > > > jbosstools-dev mailing list > > > > > > > > > > jbosstools-dev(a)lists.jboss.org > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > > > >

> > > _______________________________________________ > > > > > > jbosstools-dev mailing list > > > > > > jbosstools-dev(a)lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > >

> _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Agreed, but looking at it I don't spot these. lets continue on the jira. Another issue I see is 1.0.0.CI is being used as its version (http://download.jboss.org/jbosstools/updates/integration/locus/1.1.0.CI/) ....making it never than any 1.0.0.Alpha/Beta release....thats confusing What happend to using nightly site and/or 1.1.x for indicating "ever moving content". Nick/Mickael? On Wed, Aug 14, 2013 at 12:11:12PM -0400, Rob Cernich wrote: > I just noticed that Locus is including a bunch of site references to juno sites, e.g. http://download.jboss.org/jbosstools/updates/development/juno/ > > I don't think there is any reason why a site like Locus should be referencing other update sites. > > ----- Original Message ----- > >> Sounds good. Please let me know if you need me to do anything. > >> ----- Original Message ----- > >>> Once Paul gets back we need to go over what locus is and what it isn't and >>> find other ways to handle what was done. >> > >>> It was never intended to include snapshots nor custom red hat builds of >>> anything. >> > >>> The introduction of the massive runtime dependency set from fuse makes >>> things >>> a lot more muddier which is what we'll need to fix/work on. >> > >>> Locus is *not* a repository for usage by other p2 repositories. Locus is >>> just >>> for builds and They should be included not referenced. Just like eclipse >>> orbit. >> > >>> The target files is what is used to align dependencies and we should get >>> that >>> weeded through - for now it seems like everything fuse included just been >>> added without much consideration besides "can it build". >> > >>> Once I return from pto (national holidays here this long weekend) I'll >>> catch >>> up with Paul and Lars H. To see what we can/need to do. >> > >>> /max (sent from my phone) >> > >>> On 31/07/2013, at 22.31, Rob Cernich < rcernich(a)redhat.com > wrote: >> > >>>>> On 07/31/2013 08:24 PM, Rob Cernich wrote: >>>> >>> >> > >>>>>> Isn't part of the goal of Locus to align the dependencies used by >>>>>> various >>>>>> components? >>>>> >>>> >>> >> >>>>> Not exactly, Locus is just aimed at providing some dependencies as OSGi >>>>> bundles/p2 artifacts. It's not the place where we'll manage dependency. >>>> >>> >> > >>>>>> Hypothetically, what would happen if those two projects, using >>>>>> different >>>>>> versions of saxon, were installed in the same instance of Eclipse? >>>>>> Unless >>>>>> the plugin depending on v. 9.2.1 were configured to only use versions >>>>>> 9.2.x >>>>>> or exactly 9.2.1, I'm guessing both projects would resolve the 9.4 >>>>>> version >>>>>> of saxon. Personally, I think Locus, just like the TP's should be >>>>>> used >>>>>> for >>>>>> coordinating these dependencies. (Just my opinion, as I haven't been >>>>>> involved with any of the activity surrounding Locus. I'm sure there's >>>>>> a >>>>>> good >>>>>> pun in there somewhere;)) >>>>> >>>> >>> >> > >>>>> Both bundles resolving against Saxon 9.4 is not an issue. If it appears >>>>> to >>>>> be >>>>> an issue, it has to be fixed in relevant MANIFEST.MF. Locus and Target >>>>> Platform are not workarounds for such issues. >>>> >>> >> >>>>> Target Platforms are more the place where we manage dependency >>>>> consistency. >>>>> Having JBTIS target platform based on JBT target platform makes it >>>>> easier >>>>> to >>>>> provide compatibility. >>>> >>> >> >>>> Given that the target platforms align to a specific version, does it make >>>> sense to have more than one version available in Locus? The component >>>> will >>>> get the version specified in the TP, so why does it matter beyond that? >>>> The >>>> only situation I can think of is where you have different versions of the >>>> TP >>>> pointing to the same version of Locus. Just an observation. >>> >> > >>>>> Basically: >>>> >>> >> >>>>> * MANIFEST.MF/feature.xml define dependency >>>> >>> >> >>>>> * Target Platforms define the set of available dependency to resolve >>>>> against >>>> >>> >> >>>>> * Locus provides some artifacts in an Eclipse-friendly way. >>>> >>> >> > >>>>> -- >>>> >>> >> >>>>> Mickael Istria >>>> >>> >> >>>>> Eclipse developer at JBoss, by Red Hat >>>> >>> >> >>>>> My blog - My Tweets >>>> >>> >> > >>>>> _______________________________________________ >>>> >>> >> >>>>> jbosstools-dev mailing list >>>> >>> >> >>>>> jbosstools-dev(a)lists.jboss.org >>>> >>> >> >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> >>> >> > >>>> _______________________________________________ >>> >> >>>> jbosstools-dev mailing list >>> >> >>>> jbosstools-dev(a)lists.jboss.org >>> >> >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >> > >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev