<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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 <a
href="https://issues.jboss.org/browse/JBIDE-12248">https://issues.jboss.org/browse/JBIDE-12248</a>
(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. <br>
<br>
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.<br>
<br>
Thanks<br>
Denis<br>
<br>
On 09/12/2012 10:02 AM, Mickael Istria wrote:<br>
</div>
<blockquote cite="mid:5050C024.5050803@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi all,<br>
<br>
We'd like to provide an improvement to target-platform management
that would make them more reliable, thanks to more validation, and
more automation (less manual error-prone maintainance).<br>
The first step consists in this bug: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://issues.jboss.org/browse/JBIDE-12565">https://issues.jboss.org/browse/JBIDE-12565</a><br>
The idea is to automatically generate unified.target and
local.target from multiple.target. Also, we'll split the
target-platforms in several maven artifacts (GAVs), so that we can
publish them more incrementally and perform much more validation
to guarantee that what is published is always synchronized with
our sites.<br>
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.<br>
<br>
The plan is the following:<br>
Step 1: I set up the CI job for this new mechanism (since artifact
changed it won't collide with current platforms). Publication of
the aggregated target site will still be done by previous job.<br>
Step 2: when we are in a good state, remove publication of
aggregated target site from current job and move it to the new one<br>
Step 3: when we are in a good state, change profiles in parent pom
to use new targets<br>
Step 4: remove old jobs from Jenkins and old target-platform
mechanism from SVN.<br>
Step 5: there's no step 5.<br>
<br>
I'll start tomorrow with Step 1, the goal is to have all this
finished for Tuesday (before code-freeze).<br>
<br>
Please share any concern.<br>
Cheers,<br>
<div class="moz-signature">-- <br>
Mickael Istria<br>
Eclipse developer at <a moz-do-not-send="true"
href="http://www.jboss.org/tools">JBoss, by Red Hat</a><br>
<a moz-do-not-send="true"
href="http://mickaelistria.wordpress.com">My blog</a> - <a
moz-do-not-send="true" href="http://twitter.com/mickaelistria">My
Tweets</a></div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
jbosstools-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jbosstools-dev">https://lists.jboss.org/mailman/listinfo/jbosstools-dev</a></pre>
</blockquote>
<br>
</body>
</html>