<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/07/2013 08:47 AM, Alexey Kazakov
wrote:<br>
</div>
<blockquote cite="mid:51135BFB.6060204@exadel.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 02/06/2013 11:31 PM, Mickael
Istria wrote:<br>
</div>
<blockquote cite="mid:5113583D.4010309@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
I have the opposite feeling: some people will be happy to see
them working on Juno. Why updating MANIFEST and block that? What
is the added value?<br>
</blockquote>
<br>
IMO we just don't know if the stuff works on Juno if we don't test
it on Juno and even don't build it against Juno. Right now (we
moved to Kepler just a week ago) it should work but I won't be
sure about it in a month.<br>
And probably there will be plenty of users who will try to install
JBT on Juno without understanding that they are doing it on their
own risk.<br>
</blockquote>
Enabling API Tools in your IDE will help you to detect when you use
recent API, and will suggest you to update your MANIFEST
accordingly.<br>
If you prefer updating poms, that's not bad and we won't care while
it works on Kepler. IMO, It's just sad to not benefit from
modularity provided by OSGi that makes that one can pick up some
subsets of the application if he wants to make a custom package of
his own. But providing this ability to our users is not something we
care that much.<br>
So in the end; do what you want, it just has to work with Kepler.<br>
<div class="moz-signature">-- <br>
Mickael Istria<br>
Eclipse developer at <a href="http://www.jboss.org/tools">JBoss,
by Red Hat</a><br>
<a href="http://mickaelistria.wordpress.com">My blog</a> - <a
href="http://twitter.com/mickaelistria">My Tweets</a></div>
</body>
</html>