Upcoming change for TP 4.40.0.Alpha1-SNAPSHOT => Luna M2
by Mickael Istria
Hi all,
Here is a proposal for a new 4.40.0.Alpha1-SNAPSHOT target platform: https://github.com/jbosstools/jbosstools-target-platforms/pull/21
It consists in the following changes:
* JBIDE-15374 (Move to Kepler Luna M2)
Additionally to version upgrades, this changes introduce those 3 new bundles into the target platform:
* org.eclipse.osgi.compatibility.state[1.0.0.v20130906-1833]
* org.apache.commons.compress[1.4.1.v201301140946]
* org.eclipse.jgit.archive[3.1.0.201310021548-r]
Please review this PR and yell if there is anything shocking. You can use the following stuff to try to build your component against this suggested PR:
jbosstools-target-platforms$ git fetch mistria JBIDE-15374
jbosstools-target-platforms$ git checkout FETCH_HEAD
jbosstools-target-platforms$ cd jbosstools/multiple
multiple$ mvn clean install -P \!multiple2repo
multiple$ cd /path/to/your/component
component$ mvn clean verify -Dtpc.version=4.31.0.Alpha1-SNAPSHOT -Pmultiple
When done, please add your feedback on https://issues.jboss.org/browse/JBIDE-15374
Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
11 years, 3 months
How do I compile against org.jboss.tools.tests?
by Ian Tewksbury
Hi all,
I am working on developing eclipse windup plugin and trying to bang out
some unit tests for my validator. I would like to take advantage of the
utilities in org.jboss.tools.tests for importing test projects into the
workspace.
Problem is when I add org.jboss.tools.tests to my MANIFEST.MF eclipse
wines that it cannot find that bundle.
What do you all use for a target platform to prevent eclipse from getting
upset and allowing you to leverage content assist and such?
I followed the instructions here,
https://community.jboss.org/wiki/HowToBuildJBossTools40WithMaven3, to
download the Juno target platform, but it does not seem to include the
tests, so that did not help.
Suggestions?
Thanks & Blue Skies,
~Ian
11 years, 3 months
Version bumps for JBT 4.1.1 / JBT 4.2
by Nick Boldt
/me forwards this to the other list as requested
-------- Original Message --------
Subject: Re: Version bumps for JBT 7.1.0 / JBDS 8.0.0
Date: Sat, 5 Oct 2013 11:04:34 +0200
From: Max Rydahl Andersen <manderse(a)redhat.com>
To: Alexey Kazakov <akazakov(a)exadel.com>
CC: Nick Boldt <nboldt(a)redhat.com>, external-exadel-list(a)redhat.com
btw. please use jbosstools-dev for tech stuff like this - not
external-exadel-list.
/max
On Fri, Oct 04, 2013 at 12:03:09PM -0700, Alexey Kazakov wrote:
>OK, I got it.
>We have changed CDI and JSF in 4.1.x since 4.1.0.Final. And we have
>bumped CDI version (1.5.0->1.5.1) and JSF (3.5.0->3.5.1).
>Seam has not changed since 4.1.0.Final (no code changes, no version
>bumping) because we thought we should not bump unchanged components.
>OK. It's not correct anymore (if it ever was) and we should bump the
>unchanged seam component for 4.1.1.Beta1 too (3.5.0->3.5.1) because we
>have changed and bumped CDI and JSF which are parts of the same github
>repo.
>I will fix it for Beta1 for seam.
>
>
>On 10/04/2013 11:33 AM, Nick Boldt wrote:
>>Yes, that was the suggestion from Max yesterday.
>>
>>He seems to want to treat entire github repos as single entities
>>when dealing with version bumps.
>>
>>So, if ANY of the subcomponents in a repo change, ALL the
>>subcomponents should increment their .y or .z digit accordingly.
>>
>>In the attachments on this thread, I've assumed that the reason
>>nothing was bumped is because nothing had changed, so that bumping
>>from 3.5.0 to 3.5.1 and 3.5.100 was reasonable.
>>
>>If in fact something DID change, or WILL change before GA of JBDS
>>7.1 or 8.0, then perhaps 3.6.0 is a better version to use. The
>>amount of change determines which version makes more sense, and of
>>course you'll know that more than I will since you're committing the
>>changes.
>>
>>
>>On 10/04/2013 02:15 PM, Alexey Kazakov wrote:
>>>So if we have bumped javaee (because of changes in cdi and jsf) we
>>>should bump seam too even if it doesn't have any changes, correct?
>>>
>>>On 10/04/2013 11:10 AM, Nick Boldt wrote:
>>>>Max,
>>>>
>>>>I took a look a copy of the latest versionwatch report, dumped it into
>>>>OpenOffice Calc, and cleaned out all the places where features &
>>>>versions WERE incremented.
>>>>
>>>>What's left is a list of plugins and features in JBDS 7.x (4.1.x
>>>>branch) and 8.0 (master branch) where it appears that some things
>>>>haven't been correctly upversioned.
>>>>
>>>>Worst offender is org.jboss.tools.vpe, where master branch is 3.5.0
>>>>but 4.1.x branch is 3.5.1. Other IUs listed should move up too since
>>>>their parent projects have bumped (ie., if anything in Base has
>>>>bumped, so too should runtime and usage; if part of JavaEE has bumped,
>>>>so too should Seam).
>>>>
>>>>See attached screenshot and .ods spreadsheet. I haven't opened JIRAs
>>>>for these issues yet - wanted your +1 on them first.
>>>>
>>>>
>>>
>>
>
11 years, 3 months
BuildContext in M2E Builders
by Rob Cernich
Hey all,
I've been deep in the SwitchYard M2E build participant recently trying to figure out why we're ending up with stale markers in the workspace. One thing I've found is that items refreshed by the resources mojo don't show up until they are refreshed by the m2e builder, which happens after all the build participants have executed (i.e. refreshes the files passed to BuildContext.refresh()). This is problematic for me because I'm using scanners created off the context to check for changed files and am missing changes to resource files that have been copied to target/classes. My plugin is executing in the process-classes phase, so I would expect the updated resources to be available.
I'm not a Maven expert, but it seems to me that if I'm scanning for changed files, I should be able to see _all_ the files that have changed, including those changed as a result of previous executions in the same context. I would consider the current behavior a bug in the Eclipse BuildContext, but I'm not sure how it's supposed to work to begin with. If any of you m2e experts could chime in with your thoughts, that would be much appreciated.
Thanks in advance,
Rob
11 years, 4 months
Querying a p2 repo from a Mojo
by Mickael Istria
Hi all,
I would like to write a Mojo for the "verify" goal which takes as input
a baseline, and compare output of the module build with a baseline to
tell whether the version of current module should be bumped. So far the
only criterion would simply be that for bundle x.y.z, if baseline
already contains x.y.z2 with z2 >= z, then build would fail or warn to
remind the developer to bump the version.
[ You'll notice there that this is not the process used by Eclipse
platform, as it implies that versions should be bumped systematically
whereas Platform build tends to re-use artifacts as much as possible. So
the use-case mentioned about is not a baseline replacement, but more a
version conformance taking baseline as reference ]
This "ValidateVersionAgainstBaselineMojo" would simply need to execute a
query against the baseline repositories. However, it's not very trivial
to implement such p2 related task with Tycho as such actions have to be
turned into services. So far, I've found that the service which seems
the closest from the ability to make queries against a p2 repo is the
BaselineService. However, it is too limited as it only checks bundles
that match exactly (x.y.z.qualifier equal), whereas I'd like basically
to put some version range. Is there currently a way to ask for a bundle
of given version range from a Mojo or should I propose a patch that adds
such a method to the BaselineService? The method would look like
public Collection<IP2Artifact> getBundles(Collection<MavenRepositoryLocation> baselineLocations, String bundleId, VersionRange range);
Does this use-case make sense to you? Is there any chance that if I
write such a method, it gets integrated in Tycho so I can go ahead and
write a Mojo?
When I'm done with this very simple Mojo, I'd like to go a step forward
and implement another Mojo that gives hints about semantic versioning,
as BND does
http://blog.osgi.org/2013/09/baselining-semantic-versioning-made-easy.html
, reusing recent BND improvements and API.
Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
11 years, 4 months
How should we deal with components of projects which have not changed since JBT 4.1.0.Final (eg., jbosstools-base/runtime) ?
by Nick Boldt
In looking at the JBT 4.1.1.Alpha2 build [1], I see that some features
have not yet changed since JBT 4.1.0.Final [2]. This is fine for a
project like GWT or Freemarker, where the entire project is versioned
the same way and we can simply include the previous .Final release, but
for a subcomponent of a project, like the runtime component in
jbosstools-base [3], this presents a question.
[1] http://download.jboss.org/jbosstools/updates/nightly/core/4.1.kepler/
[2] http://download.jboss.org/jbosstools/updates/stable/kepler/
[3]
http://download.jboss.org/jbosstools/builds/staging/jbosstools-base_41/al...
Currently, the base build [3] is producing this plugin:
org.jboss.tools.runtime.core 2.1.0.Alpha2-v20130927-0137-B114
But the JBT 4.1.1.Alpha2 build [1] contains this version, which is
code-wise identical except for the qualifier change in the manifest.
org.jboss.tools.runtime.core 2.1.0.Final-v20130717-0450-B102
Where it becomes an issue is that when we start building 4.1.1.Final in
November, we will be including both 2.1.0.Final-v20130717-0450-B102
(from JBT 4.1.0.Final) and 2.1.0.Final-v20131200-0000-Bxxx (from JBT
4.1.1.Final). Since these are bitwise identical, there's no point making
users update from an identical feature or plugin to a newer identical
version.
So how do we prevent the build from including a newer-versioned but
identical feature or plugin?
The only thing I can currently think of is to *exclude* these features
from the base_41 update site [3] so that only the older version from [2]
will be included.
This is basically the process I used to build JBT 4.1.0.1 - I excluded
everything from jbosstools-central's site/category.xml except the
feature which had actually changed [4].
[4]
https://github.com/jbosstools/jbosstools-central/commit/16279020cbf872f4e...
Looking for feedback here -- is this a good idea?
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
11 years, 4 months
