[JBoss JIRA] (JBIDE-17811) Incorrect bean injection eligibility assumption for beans excluded using DeltaSpike @Exclude
by Ron Šmeral (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17811?page=com.atlassian.jira.plugi... ]
Ron Šmeral updated JBIDE-17811:
-------------------------------
Steps to Reproduce: Import https://github.com/jboss-developer/jboss-wfk-quickstarts/tree/2.6.0.CR1/d...
> Incorrect bean injection eligibility assumption for beans excluded using DeltaSpike @Exclude
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-17811
> URL: https://issues.jboss.org/browse/JBIDE-17811
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi-extensions
> Environment: JBDS 8.0.0.Beta2d
> Reporter: Ron Šmeral
>
> With the following classes on the classpath:
> {code:java|title=DeactivatableTest.java}
> @Inject
> private MyBean myBean;
> {code}
> {code:java|title=MyBean.java}
> @Exclude
> public class MyBean {}
> {code}
> {code:java|title=ExcludeExtensionDeactivator.java}
> public class ExcludeExtensionDeactivator implements ClassDeactivator {
> public Boolean isActivated(Class<? extends Deactivatable> targetClass {
> if (ExcludeExtension.class.equals(targetClass)) {
> return false;
> }
> return null;
> }
> }
> {code}
> ..the injection point in DeactivatableTest is marked with a warning:
> {noformat}
> No bean is eligible for injection to the injection point [JSR-299 §5.2.1] {noformat}
> ..which is incorrect. MyBean *is* eligible despite being annotated @Exclude, since ExcludeExtension is deactivated using the core DeltaSpike mechanism of deactivation (ClassDeactivator).
> There does not seem to be a (simple) solution to this other than executing the code in all available ClassDeactivators.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17811) Incorrect bean injection eligibility assumption for beans excluded using DeltaSpike @Exclude
by Ron Šmeral (JIRA)
Ron Šmeral created JBIDE-17811:
----------------------------------
Summary: Incorrect bean injection eligibility assumption for beans excluded using DeltaSpike @Exclude
Key: JBIDE-17811
URL: https://issues.jboss.org/browse/JBIDE-17811
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: cdi-extensions
Environment: JBDS 8.0.0.Beta2d
Reporter: Ron Šmeral
With the following classes on the classpath:
{code:java|title=DeactivatableTest.java}
@Inject
private MyBean myBean;
{code}
{code:java|title=MyBean.java}
@Exclude
public class MyBean {}
{code}
{code:java|title=ExcludeExtensionDeactivator.java}
public class ExcludeExtensionDeactivator implements ClassDeactivator {
public Boolean isActivated(Class<? extends Deactivatable> targetClass {
if (ExcludeExtension.class.equals(targetClass)) {
return false;
}
return null;
}
}
{code}
..the injection point in DeactivatableTest is marked with a warning:
{noformat}
No bean is eligible for injection to the injection point [JSR-299 §5.2.1] {noformat}
..which is incorrect. MyBean *is* eligible despite being annotated @Exclude, since ExcludeExtension is deactivated using the core DeltaSpike mechanism of deactivation (ClassDeactivator).
There does not seem to be a (simple) solution to this other than executing the code in all available ClassDeactivators.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3085) Should we be able to update JBDS 8.0.0.GA -> 8.1.0.Alpha1 via Early Access?
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-3085?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-3085:
--------------------------------------
Having it Early Access or not doesn't change anything technically, it's just the fact that it's installed from Central that matters.
Currently, what's difficult is the concept of downgrading, that is not provided by p2/Update UI nor by discovery APIs. I believe p2 has APIs and mechanism to do that, but since it is not a usage scenario that is part of Eclipse itself, it will be difficult to find things to re-use when implementing this.
Since Eclipse itself doesn't provide downgrading operations, that means that people who install with normal Eclipse Update UI won't be able to downgrade to older version.
> Should we be able to update JBDS 8.0.0.GA -> 8.1.0.Alpha1 via Early Access?
> ---------------------------------------------------------------------------
>
> Key: JBDS-3085
> URL: https://issues.jboss.org/browse/JBDS-3085
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Nick Boldt
> Assignee: Max Rydahl Andersen
>
> Max brought up a question on a call today:
> *Should we be able to update JBDS 8.0.0.GA -> 8.1.0.Alpha1 via Early Access?*
> This was supposedly in the original scope for the creation of a Early Access site, but I never saw that. So, in order to get some eyeballs on this idea, and to get buy-in from QE/doc/dev/PM/PgM/PL, I'm cc:'ing some people here so we can discuss the cons and cons of this idea.
> cc: [~mmusaji] [~mmurray] [~mmalina] [~maxandersen] [~mickael_istria][~ldimaggio] [~burrsutter] [~jpallich] [~rruss] [~fbricon]
> (Aside: has anyone noticed that there's an plethora of people with "M" names on this team?)
> Things to consider:
> a) what happens if an 8.0.0.GA user suddenly finds they've updated to an Alpha or Beta release? Can they uninstall? (Probably not, if they started with the installer; probably yes if they started from BYOE / Marketplace.)
> b) how will GSS support these "I was on GA but not I'm on Beta" users?
> c) What about project examples that might / might not be compatible between 8.0 and 8.x, eg., because of changes in Eclipse Luna or a new default runtime (EAP 6.3, 6.4) ?
> d) what could possibly go wrong?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17810) Document the need (and script the process) to ensure all branches have been created and all master branch root poms are correctly pointing at the latest parent pom
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17810?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-17810:
------------------------------------
Something based loosely on this:
{code}
for d in jbosstools-*; do cd $d; echo " == $d == "; gpuom; cat pom.xml | grep -A2 -B2 ">parent<"; cd ..; echo ""; done
(then check if the value shown is correct. gpuom is short for `git pull origin master`)
for d in aerogear browsersim forge freemarker hibernate jst openshift vpe; do cd jbosstools-${d}; echo " == $d == "; gpuom; cat pom.xml| grep -A1 -B1 ">parent<" | egrep "Alpha|Beta"; cd ..; echo ""; done
{code}
> Document the need (and script the process) to ensure all branches have been created and all master branch root poms are correctly pointing at the latest parent pom
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-17810
> URL: https://issues.jboss.org/browse/JBIDE-17810
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Beta3
> Reporter: Nick Boldt
>
> Document the need (and script the process) to ensure all branches have been created and all master branch root poms are correctly pointing at the latest parent pom
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17754) For JBIDE 4.2.0.Beta3: Code Freeze + Branch [Aerogear]
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17754?page=com.atlassian.jira.plugi... ]
Denis Golovin closed JBIDE-17754.
---------------------------------
Resolution: Done
released to master with updated reference to parent pom
> For JBIDE 4.2.0.Beta3: Code Freeze + Branch [Aerogear]
> ------------------------------------------------------
>
> Key: JBIDE-17754
> URL: https://issues.jboss.org/browse/JBIDE-17754
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: aerogear-hybrid
> Reporter: Nick Boldt
> Priority: Blocker
> Labels: task
> Fix For: 4.2.0.Beta3
>
>
> For JBIDE 4.2.0.Beta3 [Aerogear]: Please perform the following tasks:
> 0. If nothing has changed in your component since 4.1.1.Final / 7.1.0.GA (eg., XulRunner, GWT, Freemarker, BIRT), *{color:red}Reject this JIRA{color}*.
> Otherwise:
> 0. Make sure your component has no remaining unresolved JIRAs set for fixVersion = 4.2.0.Beta3
> [Unresolved JIRAs with fixVersion = 4.2.0.Beta3, 8.0.0.Beta3|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%2...]
> 1. Ensure your component features/plugins have been [properly upversioned|http://wiki.eclipse.org/Version_Numbering#Overall_example], eg., from 1.0.0 to 1.0.1.
> *NOTE:* If you already did this for the previous milestone you do *not* need to do so again.
> {code}
> mvn -Dtycho.mode=maven org.sonatype.tycho:tycho-versions-plugin:0.17.0:set-version -DnewVersion=1.0.1-SNAPSHOT
> {code}
> 2. Update your root pom to use parent pom version 4.2.0.Beta3-SNAPSHOT;
> {code}
> <parent>
> <groupId>org.jboss.tools</groupId>
> <artifactId>parent</artifactId>
> <version>4.2.0.Beta3-SNAPSHOT</version>
> </parent>
> {code}
> 3. Ensure you've built & run your plugin tests using the latest target platform version 4.40.0.Beta3-SNAPSHOT;
> {code}
> mvn clean verify -Dtpc.version=4.40.0.Beta3 # (if the TP is already released)
> or
> mvn clean verify -Dtpc.version=4.40.0.Beta3-SNAPSHOT # (if still being staged)
> {code}
> 4. Branch from your existing master branch into a new *{color:blue}jbosstools-4.2.0.Beta3x{color}* branch;
> {code}
> git checkout master
> git pull origin master
> git checkout -b jbosstools-4.2.0.Beta3x
> git push origin jbosstools-4.2.0.Beta3x
> {code}
> 5. *NOW THAT YOU HAVE BRANCHED*, check out your *{color:orange}master branch{color}*.
> {code}
> git checkout master
> git pull origin master
> {code}
> 6. Update your *{color:orange}master branch{color}* parent pom to use the latest version, *{color:orange}4.2.0.Beta3-SNAPSHOT{color}*:
> {code}
> <parent>
> <groupId>org.jboss.tools</groupId>
> <artifactId>parent</artifactId>
> <version>4.2.0.Beta3-SNAPSHOT</version>
> </parent>
> {code}
> Now, your root pom will use parent pom version:
> * *{color:blue}4.2.0.Beta3-SNAPSHOT{color}* in your *{color:blue}jbosstools-4.2.0.Beta3x{color}* branch, and
> * *{color:orange}4.2.0.Beta3-SNAPSHOT{color}* in your *{color:orange}master{color}* branch.
> 7. Close (do not resolve) this JIRA when done.
> 8. If you have any outstanding [New + Noteworthy JIRAs|https://issues.jboss.org/issues/?jql=%28%28project%20in%20%28JBDS%2...] to do, please complete them next.
> [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for Aerogear task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3087) Consider new installer packages
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-3087?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-3087:
--------------------------------------
It reminds me of the talk from mentor graphics at EclipseCon US. They have developed an RCP application installer that looks quite good and that natively understands Eclipse and p2 concepts. It would IMO be much better to try using it than to keep on maintaining the IzPack based installer.
https://github.com/MentorEmbedded/p2-installer
> Consider new installer packages
> -------------------------------
>
> Key: JBDS-3087
> URL: https://issues.jboss.org/browse/JBDS-3087
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Nick Boldt
>
> Today we have two installers:
> * Stand-alone Installer (504M)
> * Installer with EAP (642M)
> Both can be used for offline install, but both are large downloads.
> When installing JBDS IS offline, a user must download several archives:
> * JBDS installer jar (or update site zip)
> * JBDS target platform zip
> * JBDS IS zip
> And, there's no "stub installer for online" which would simply fetch the content needed to do the install from the update site, making the installer a much smaller (initial) download footprint.
> Therefore Max has suggested that we might want to add two new installers, resulting in this list:
> * Stand-alone Installer (504M)
> * Installer with EAP (642M)
> * Installer with Integration Stack (~750M)
> * Stub Installer (~10M)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months