[jbosstools-dev] Who uses .target file?

[Max Rydahl Andersen]

>> 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&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-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 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
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> 
>