> Noone uses it right now since it is not set up as it should be
afaik
>
> I would/want to use it if we enable slide planner mode on it so the dependencies
becomes *deterministic*. They aren't now.
Depends on what you mean by deterministic.
I assume you have followed the tycho dev list - if not look up slicer mode and the
discussions around it.
without it the dependencies/target platforms are not resolved deterministically.
And just to be clear what I mean with deterministic is that if our TP says
org.x.z.y-1.2.3
and the update site only have org.x.z.y-1.2.4 the build *must* fail.
It doesn't if the other p2 metadata features/plugin's allows 1.2.4 in its set.
To reproduce it is tricky - hence why I suggest go look at slicer mode and the discussions
around it.
Currently, the script that
allows you to turn a .target file into an update site can run in two modes:
* useLatest=true (get whatever versions of the listed IUs are available
on the upstream sites) and
fine - nice to developing.
* useLatest=false (use exactly the versions of IUs listed in the
.target
file)
this is fine for building the site - but I assume it has the same problems as tycho has
for this if it uses plain p2
or is this using slice mode to make sure its the right version ?
Anyway, just having an updatesite doesn't help if my current mirror doesn't have
the proper version - then my build
can still succeed when it shouldn't.
Does that not meet both the need to resolve a TP on disk from the
explicit versions listed, or to update it from the latest in the
requirements mirror? (eg., when it's time to move from SR1 to SR2)
I think the problem is that you guys are approaching this from how to build the
updatesites - and here your scripts/workflows suggestions are good.
But it doesn't improve our guarantees of having builds being deterministic (unless you
stop using mirrors and dont use the same ~/.m2/repo for different builds)
> And then I would like to get target files that I can apply in
eclipse - but the current one is just too big/slow to work.
How would you propose bifurcating them? What features would be in what
chunks? Maven bucket? SOA bucket? Teiid bucket? Need some idea how to
break this into smaller pieces.
If you can tell me a way to do the split I can take a look at what can of
"splits" these would make sense in.
But intuitively I would like a "base eclipse" which is more or less
"eclipse JEE" and then a TP for each "major" feature that needs more
than "base eclipse".
And if that ends up being everyone having an extra TP then I would look at those and see
if there are common grounds we could move down in the "base".
> Using an updatesite would not help on that either afaik.
An update site w/ all the featureless plugins referenced by a top-level
feature which would provide a way to easily install the whole site into
your Eclipse either by hand or via p2.director script? Yes, yes it would.
So now we are introducing a "virtual" top-level feature into developers machines
that will prevent any updates and not be like what our users actually run against ?
That's broken IMO
> /max
>
> On Mar 14, 2012, at 3:55 PM, Mickael Istria wrote:
>
>> Hi all,
>>
>> This is an important question for us.
>> Nick and I are now convinced that .target files are not the panacea to drive
dependency management at build time. It adds a lot of additional steps and it does not
work that easily in the Maven way. We are thinking of some alternatives way to provide a
"dependency" repository that would contain only the necessary stuff for you to
work on your component. Then we'll just manage this repository instead of a .target
file, it should make our daily work better and remove lot of complexity.
>> See
https://issues.jboss.org/browse/JBIDE-10915 and comments starting from here
https://issues.jboss.org/browse/JBIDE-11157?focusedCommentId=12676643&...
for more details/debate.
>>
>> So we more and more think this .target file is useless, and we'd like to get
rid of it (uselessness is bad). But before that, we'd like to know whether some of you
do use the generated .target file. If yes, we'll have to think on a better way to make
everyone happy. So if you use .target file, raise your hand!
>> --
>> 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
>
>
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev