[jbosstools-dev] Locus Repository Usage

Fri Aug 16 10:23:35 EDT 2013

1.1.0.CI == 1.1.0.x

I've been pushing for Alpha, Beta, CR, Final releases, but until we get 
something stable enough to formerly release, we're just using .CI as a 
replaceable placeholder. As you can see in the /integration/locus/ 
folder below, we did do a 1.0.0.Final release, adhering to the JBoss 
community versioning guidelines [1].

[1] https://community.jboss.org/wiki/JBossProjectVersioning

---

Max, what's confusing is your statement:

"making it never than any 1.0.0.Alpha/Beta release....thats confusing 
What happend to using nightly site"

Are you seriously having trouble locating the sites?

The nightly update site is where all our nightlies are. Under 
/updates/nightly/. Seems logical, no?

http://download.jboss.org/jbosstools/updates/nightly/locus/

The latest integration builds are under /updates/integration/:

http://download.jboss.org/jbosstools/updates/integration/locus/

See also:

http://download.jboss.org/jbosstools/updates/development/locus/
http://download.jboss.org/jbosstools/updates/stable/locus/

If that's not straightforward, have you tried google?

http://lmgtfy.com/?q=jboss+locus+integration+update

N

On 08/16/2013 03:25 AM, Max Andersen wrote:
> 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 at 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 at lists.jboss.org
>>>>>
>>>>
>>>
>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>
>>>>
>>>
>>
>>>>> _______________________________________________
>>>>
>>>
>>>>> jbosstools-dev mailing list
>>>>
>>>
>>>>> jbosstools-dev at lists.jboss.org
>>>>
>>>
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>
>>>
>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com