Actually, both multiple and unified have source jars. If the goal had
been to make these contain different content, they should be named as
such. Today, the only distinction is that as Denis points out, multiple
points to the composite requirements site, and therefore may be
validated even if stuff is not explicitly stated in the multiple.target
file, whereas unified.target points to the aggregated update site
produced by resolving multiple.target to disk.
As such, unified.target will fail to validate should anything needed be
missing from the .target file.
As we also want to introduce more .target flavours, we'll need a whole
matrix of them:
no-sources and with-sources :: JBIDE-11689
minimum-eclipse and latest-eclipse :: JBIDE-10312
JBT multiple and JBT unified
as well as
JBDS multiple and JDS unified :: JBDS-2276
That's 2x2x2x2=16 target platforms to maintain.
HOWEVER...
* we can generate unified from multiple, by simply changing the URL
* we can generate no-sources from with-sources by excluding .source from
the IU list and removing the p2 instruction to include sources
That leaves (JBDS + JBT) * (minimum + latest) = 4 .target files to
maintain by hand.
That's only twice as much to maintain as we had for JBT3.3/JBDS5. :D
N
On 09/14/2012 06:53 AM, Max Rydahl Andersen wrote:
>>> About the file we have, I sent some mails a few month ago
on this topic, I'll try to sum it up:
>>> * multiple.target: points to the composite target site, good to use inside
IDE with PDE since it also contains source (PDE is greedy and also finds sources from the
composite)
>> should really get another name than multiple.
> why not:
> multiple -> composite
> local is replaced by maven mirroring
> unified - > aggregated
wether they are composite, aggregated, multiple or unified is rather irrelevant IMO. (its
important for build setup for sure)
Its whats in them that is different - one has source jars, the others dont.
One is for building against, the other is for PDE.
multiple shouldn't actually be used by anyone but PDE users.
or unified should get these added too.
...but the build need to be very clear that the final result does not include the full
target platform since that would now point to unnecessary sources
/max
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)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