Re: [jira] [Commented] (DELTASPIKE-308) Port functionality from Seam Mail module
Apache commons has commons-mail...and Seam 3 Mail including its template rendering, Seam 3 includes another renderer module , but not released yet. So I think if possible to complete the things are not included in Seam 3 . 1. complete another Render module for template rendering. 2. Is there some approaches to listen the mail arrival...(portable in different application server) 3. Asynchronous sending email, and I was using JMS and Seam 3 Mail to send emails asynchronously, https://github.com/hantsy/seam3-mail-demo . In fact, I hope DeltaSpike can provide a seamless asynchronous solution(schedule, task, asyn like the Spring one) in CDI bean(POJO andEJB ). Hantsy On 4/11/2013 16:39, Romain Manni-Bucau (JIRA) wrote: [ https://issues.apache.org/jira/browse/DELTASPIKE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628772#comment-13628772 ] Romain Manni-Bucau commented on DELTASPIKE-308: --- about 3 i just say, whichever the api you propose each project will wrap it more or less to make it adapted to its case and once done standard api is not awfull compared to the fluent one. maybe it just misses some conventions Port functionality from Seam Mail module Key: DELTASPIKE-308 URL: https://issues.apache.org/jira/browse/DELTASPIKE-308 Project: DeltaSpike Issue Type: Wish Reporter: Adrian Mitev Assignee: Cody Lerum Priority: Minor Fix For: 0.5-incubating seam-mail is a nice module that eases the mail sending and contains a fluent api for that. Such API will be very useful for many users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- Fulltime Java EE Freelancer/Developer from China. Blog: http://hantsy.blogspot.com LinkedIn: http://cn.linkedin.com/in/hantsy Hire me on oDesk https://www.odesk.com/users/%7E01364b53cb1f4c5597 or Elance http://hantsy.elance.com.
Re: [jira] [Commented] (DELTASPIKE-315) Provide a producer for EntityManagerFactories
I hope there are some properties to mange the FlashMode, LockMode,
Transaction isolate level etc.
Hantsy
On 2/22/2013 07:18, Jason Porter (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DELTASPIKE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13583656#comment-13583656
]
Jason Porter commented on DELTASPIKE-315:
-
Do we need a way to pass other properties into the EMF? I like what you have
here Mark, seems nice and easy.
Provide a producer for EntityManagerFactories
-
Key: DELTASPIKE-315
URL: https://issues.apache.org/jira/browse/DELTASPIKE-315
Project: DeltaSpike
Issue Type: Bug
Components: JPA-Module
Affects Versions: 0.3-incubating
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 0.4-incubating
I found myself using the following pattern quite often in projects in the
last time. I have a @Qualifier UnitName(value) and a producer for a
@Dependent EntityManagerFactory for it. The configuration is mostly provided
via the persistenceProperties Map in
EntityManagerFactory#createEntityManagerFactory(unitname,
persistenceProperties);
We can further tweak the config lookup path and define a route which makes
the most sense.
This can be used to create the EntityManager producer very easily.
@ApplicationScoped
public class MyEntityManagerProducer {
private @Inject @UnitName(orderUnit) EntityManagerFactory emf;
@Produces @RequestScoped
public EntityManager createEm() {
return emf.createEntityManager();
}
.. + disposer
}
Please note that the EMF producer doens't clash with anything else as it
only produces EMFs with the Qualifier @UnitName!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-295) JsfMessageProducer createJsfMessage return type should be parametrized
hmm doesn't this info get erased anyway?
This used to work fine in all other containers.
I'm fine with changing this if it still works with all the other containers.
LieGrue,
strub
- Original Message -
From: Marek Schmidt (JIRA) j...@apache.org
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Thursday, November 29, 2012 4:48 PM
Subject: [jira] [Created] (DELTASPIKE-295) JsfMessageProducer
createJsfMessage return type should be parametrized
Marek Schmidt created DELTASPIKE-295:
Summary: JsfMessageProducer createJsfMessage return type should
be
parametrized
Key: DELTASPIKE-295
URL: https://issues.apache.org/jira/browse/DELTASPIKE-295
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 0.4-incubating
Environment: Current 0.4-incubating snapshot, Weld 2.0.0.Beta1
Reporter: Marek Schmidt
Fix For: 0.4-incubating
The
{code}
public JsfMessage createJsfMessage(InjectionPoint injectionPoint)
{code}
should probably be
{code}
public T JsfMessageT createJsfMessage(InjectionPoint
injectionPoint)
{code}
instead.
The problem manifests itself in Weld 2.0.0.Beta1:
{noformat}
Tests in error:
org.apache.deltaspike.test.jsf.impl.message.JsfMessageTest: Could not
deploy
to container: {JBAS014671: Failed services =
{jboss.deployment.unit.\jsfMessageTest.war\.WeldService
= org.jboss.msc.service.StartException in service
jboss.deployment.unit.\jsfMessageTest.war\.WeldService:
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied
dependencies for type [JsfMessageUserMessage] with qualifiers [@Default]
at injection point [[BackedAnnotatedField] @Inject private
org.apache.deltaspike.test.jsf.impl.message.beans.JsfMessageBackingBean.msg]}}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events.
static final String MARKER =
ViewContext.class.getName() + '.' + MARKER;
// make sure to use one marker per view for all of it's instances
private Object getMarker(MapString, Object attributes) {
if (attributes.containsKey(ViewContext.MARKER)) {
return attributes.get(ViewContext.MARKER);
} else {
Long marker = System.currentTimeMillis();
attributes.put(ViewContext.MARKER, marker);
return marker;
}
}
@Override
public Class? extends Annotation getScope() {
return ViewScoped.class;
}
@Override
public T T get(final ContextualT contextual,
final CreationalContextT creationalContext) {
UIViewRoot viewRoot = this.getViewRoot();
if (viewRoot == null) {
throw new ContextNotActiveException();
}
if (contextual instanceof Bean) {
Bean bean = (Bean) contextual;
String name = bean.getName();
MapString, Object viewMap = viewRoot.getViewMap();
if (viewMap.containsKey(name)) {
return (T) viewMap.get(name);
} else {
Object marker = this.getMarker(viewRoot.getAttributes());
BeanInfoT beanInfo = new BeanInfo(
marker, this.queue, contextual, creationalContext);
T instance = beanInfo.getInstance();
viewMap.put(name, instance);
this.set.add(beanInfo);
return instance;
}
} else {
return null;
}
}
@Override
public T T get(ContextualT contextual) {
UIViewRoot viewRoot = this.getViewRoot();
if (viewRoot == null) {
throw new ContextNotActiveException();
}
if (contextual instanceof Bean) {
Bean bean = (Bean) contextual;
String name = bean.getName();
MapString, Object viewMap = viewRoot.getViewMap();
return (T) viewMap.get(name);
} else {
return null;
}
}
@Override
public boolean isActive() {
return this.getViewRoot() != null;
}
// this is bad, yes, does @PreDestroy work on Context objects?
@Override
protected void finalize() throws Throwable {
try {
this.run = false;
} finally {
super.finalize();
}
}
}
Cheers,
Radu Creanga
On Mon, Nov 19, 2012 at 5:35 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi radu,
imo we have 3 easy options:
#1
we continue to rely on jsf-events and just add a session-scoped bean which
triggers the cleanup via its @PreDestroy callback (if the cleanup wasn't
done already).
(we also need one to cleanup the window-context.)
#2
since we also need to track the view-ids for the view-access-scope, we just
use a similar implementation (which follows the rules of the view-scope) and
map it to @ViewScoped.
#3
like #2 but with the help of the window-context (instead of the view-map) -
similar to [1].
regards,
gerhard
[1]
http://os890.blogspot.co.at/2011/06/session-based-view-scope-with-codi.html
2012/11/19 Mark Struberg strub...@yahoo.de
Hi Radu!
Yes, we already discussed this and agreed to import it.
Txs 4 your report!
LieGrue,
strub
From: Radu Creanga rdc...@gmail.com
To: deltaspike-dev@incubator.apache.org
Sent: Sunday, November 18, 2012 11:56 PM
Subject: Re: [jira] [Created] (DELTASPIKE-293) Improve the
ViewScopedContext by observing ServletContext and HttpSession lifecycle
events.
Hello everyone,
It seems this will require ServletContext events and Session events to
be published to the CDI event bus, which in turn requires adding the
appropriate listeners to web.xml until CDI 1.1. I know Seam Solder has
these listeners implemented. Are there plans to import it into
DeltaSpike?
Radu Creanga
On Sun, Nov 18, 2012 at 4:32 PM, Radu Creanga (JIRA) j...@apache.org
wrote:
Radu Creanga created DELTASPIKE-293:
---
Summary: Improve the ViewScopedContext by observing
ServletContext and HttpSession lifecycle events.
Key: DELTASPIKE-293
URL:
https://issues.apache.org/jira/browse/DELTASPIKE-293
Project: DeltaSpike
Issue Type: Improvement
Components: JSF-Module
Affects Versions: 0.4-incubating
Reporter: Radu Creanga
Fix For: 0.5-incubating
The CDI specification states that Context implementations are
responsible for destroying instances it creates. The current
ViewScopedContext relies on PreDestroyViewMapEvents to be notified when a
view map is destroyed. But, the JSF 2.0 and 2.1 spec only fire this event
when a view map is replaced. This means that in most cases, instances
created
Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events.
To: deltaspike-dev@incubator.apache.org Sent: Sunday, November 18, 2012 11:56 PM Subject: Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. Hello everyone, It seems this will require ServletContext events and Session events to be published to the CDI event bus, which in turn requires adding the appropriate listeners to web.xml until CDI 1.1. I know Seam Solder has these listeners implemented. Are there plans to import it into DeltaSpike? Radu Creanga On Sun, Nov 18, 2012 at 4:32 PM, Radu Creanga (JIRA) j...@apache.org wrote: Radu Creanga created DELTASPIKE-293: --- Summary: Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. Key: DELTASPIKE-293 URL: https://issues.apache.org/jira/browse/DELTASPIKE-293 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.4-incubating Reporter: Radu Creanga Fix For: 0.5-incubating The CDI specification states that Context implementations are responsible for destroying instances it creates. The current ViewScopedContext relies on PreDestroyViewMapEvents to be notified when a view map is destroyed. But, the JSF 2.0 and 2.1 spec only fire this event when a view map is replaced. This means that in most cases, instances created by ViewScopedContext are not properly destroyed. The ViewScopedContext should be observing ServletContext and HttpSession lifecycle events instead in order to ensure that all instances it creates are properly destroyed. Visible improvements resulting out of this would be that the @PostConstruct method of @ViewScoped beans is invoked. Additionally, this will probably result in better memory usage, since instances that are not properly destroyed are not eligible for GC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events.
hi radu, as mentioned before: once we have at least something similar to the window-handling of codi, it's just about some lines of code we just have to agree on #2 or #3 before we can start with it. regards, gerhard 2012/11/21 Radu Creanga rdc...@gmail.com Hello everyone, Gerhard, you're right, it's way simpler than that. I looked over the rules again like you suggested and sure I was complicating things. So, the rules: 1. A @ViewScoped bean will live as long as you're submitting the form to the same view again and again. In other words, as long as when the action method(s) returns null or even void, the bean will be there in the next request. Once you navigate to a different view, then the bean will be trashed. For this we can continue to rely on JSF events, or use a navigation observer like in #3. 2. The case when that event is not fired is when the session expires but no navigation has been performed. For example, 2 get requests to the same URL will result in the view for the first request to never get cleaned up. For this, a session bean would be enough. The implementation currently present in DS destroys instances in 1, but not in 2. So, assuming these are the only requirements, the attached patch adds support for 2 (using a session bean, no weak references or anything like that.). Anyhow, this may not be what you all are looking for but it is quite simple and working (basically #1). Gerhard, I considered both #2 and #3, and I understand how it would work given your article and reading documentation. But, I don't yet have a good grasp of the code base to implement them. I'll continue looking into it, maybe something good comes out. Happy Thanksgiving to all the people who celebrate it tomorrow. :) Radu Creanga
Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events.
of the view-scope) and map it to @ViewScoped. #3 like #2 but with the help of the window-context (instead of the view-map) - similar to [1]. regards, gerhard [1] http://os890.blogspot.co.at/2011/06/session-based-view-scope-with-codi.html 2012/11/19 Mark Struberg strub...@yahoo.de Hi Radu! Yes, we already discussed this and agreed to import it. Txs 4 your report! LieGrue, strub From: Radu Creanga rdc...@gmail.com To: deltaspike-dev@incubator.apache.org Sent: Sunday, November 18, 2012 11:56 PM Subject: Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. Hello everyone, It seems this will require ServletContext events and Session events to be published to the CDI event bus, which in turn requires adding the appropriate listeners to web.xml until CDI 1.1. I know Seam Solder has these listeners implemented. Are there plans to import it into DeltaSpike? Radu Creanga On Sun, Nov 18, 2012 at 4:32 PM, Radu Creanga (JIRA) j...@apache.org wrote: Radu Creanga created DELTASPIKE-293: --- Summary: Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. Key: DELTASPIKE-293 URL: https://issues.apache.org/jira/browse/DELTASPIKE-293 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.4-incubating Reporter: Radu Creanga Fix For: 0.5-incubating The CDI specification states that Context implementations are responsible for destroying instances it creates. The current ViewScopedContext relies on PreDestroyViewMapEvents to be notified when a view map is destroyed. But, the JSF 2.0 and 2.1 spec only fire this event when a view map is replaced. This means that in most cases, instances created by ViewScopedContext are not properly destroyed. The ViewScopedContext should be observing ServletContext and HttpSession lifecycle events instead in order to ensure that all instances it creates are properly destroyed. Visible improvements resulting out of this would be that the @PostConstruct method of @ViewScoped beans is invoked. Additionally, this will probably result in better memory usage, since instances that are not properly destroyed are not eligible for GC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events.
agree. A context must not use weak references imo. If that is the case a user just uses the wrong scope ;) As for example this e.g. looks much more like what we have (in CODI and will be in DS as well) with the @ViewAccessScoped. But just let the ideas flow, it's always good to add fresh ideas! LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Tuesday, November 20, 2012 10:38 PM Subject: Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. hi radu, it's way simpler - just look at the rule/s of the view-scope and not at the implementation you are trying to fix... - imo we don't need weak references for it. once we have at least something similar to the window-handling of codi, it's just about some lines of code (if we agree on #2 or #3). (if you like #3, you can use the add-on for codi right now.) regards, gerhard 2012/11/20 Radu Creanga rdc...@gmail.com ...
Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events.
Hi Radu! Yes, we already discussed this and agreed to import it. Txs 4 your report! LieGrue, strub From: Radu Creanga rdc...@gmail.com To: deltaspike-dev@incubator.apache.org Sent: Sunday, November 18, 2012 11:56 PM Subject: Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. Hello everyone, It seems this will require ServletContext events and Session events to be published to the CDI event bus, which in turn requires adding the appropriate listeners to web.xml until CDI 1.1. I know Seam Solder has these listeners implemented. Are there plans to import it into DeltaSpike? Radu Creanga On Sun, Nov 18, 2012 at 4:32 PM, Radu Creanga (JIRA) j...@apache.org wrote: Radu Creanga created DELTASPIKE-293: --- Summary: Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. Key: DELTASPIKE-293 URL: https://issues.apache.org/jira/browse/DELTASPIKE-293 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.4-incubating Reporter: Radu Creanga Fix For: 0.5-incubating The CDI specification states that Context implementations are responsible for destroying instances it creates. The current ViewScopedContext relies on PreDestroyViewMapEvents to be notified when a view map is destroyed. But, the JSF 2.0 and 2.1 spec only fire this event when a view map is replaced. This means that in most cases, instances created by ViewScopedContext are not properly destroyed. The ViewScopedContext should be observing ServletContext and HttpSession lifecycle events instead in order to ensure that all instances it creates are properly destroyed. Visible improvements resulting out of this would be that the @PostConstruct method of @ViewScoped beans is invoked. Additionally, this will probably result in better memory usage, since instances that are not properly destroyed are not eligible for GC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events.
hi radu, imo we have 3 easy options: #1 we continue to rely on jsf-events and just add a session-scoped bean which triggers the cleanup via its @PreDestroy callback (if the cleanup wasn't done already). (we also need one to cleanup the window-context.) #2 since we also need to track the view-ids for the view-access-scope, we just use a similar implementation (which follows the rules of the view-scope) and map it to @ViewScoped. #3 like #2 but with the help of the window-context (instead of the view-map) - similar to [1]. regards, gerhard [1] http://os890.blogspot.co.at/2011/06/session-based-view-scope-with-codi.html 2012/11/19 Mark Struberg strub...@yahoo.de Hi Radu! Yes, we already discussed this and agreed to import it. Txs 4 your report! LieGrue, strub From: Radu Creanga rdc...@gmail.com To: deltaspike-dev@incubator.apache.org Sent: Sunday, November 18, 2012 11:56 PM Subject: Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. Hello everyone, It seems this will require ServletContext events and Session events to be published to the CDI event bus, which in turn requires adding the appropriate listeners to web.xml until CDI 1.1. I know Seam Solder has these listeners implemented. Are there plans to import it into DeltaSpike? Radu Creanga On Sun, Nov 18, 2012 at 4:32 PM, Radu Creanga (JIRA) j...@apache.org wrote: Radu Creanga created DELTASPIKE-293: --- Summary: Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. Key: DELTASPIKE-293 URL: https://issues.apache.org/jira/browse/DELTASPIKE-293 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.4-incubating Reporter: Radu Creanga Fix For: 0.5-incubating The CDI specification states that Context implementations are responsible for destroying instances it creates. The current ViewScopedContext relies on PreDestroyViewMapEvents to be notified when a view map is destroyed. But, the JSF 2.0 and 2.1 spec only fire this event when a view map is replaced. This means that in most cases, instances created by ViewScopedContext are not properly destroyed. The ViewScopedContext should be observing ServletContext and HttpSession lifecycle events instead in order to ensure that all instances it creates are properly destroyed. Visible improvements resulting out of this would be that the @PostConstruct method of @ViewScoped beans is invoked. Additionally, this will probably result in better memory usage, since instances that are not properly destroyed are not eligible for GC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-293) Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events.
Hello everyone, It seems this will require ServletContext events and Session events to be published to the CDI event bus, which in turn requires adding the appropriate listeners to web.xml until CDI 1.1. I know Seam Solder has these listeners implemented. Are there plans to import it into DeltaSpike? Radu Creanga On Sun, Nov 18, 2012 at 4:32 PM, Radu Creanga (JIRA) j...@apache.org wrote: Radu Creanga created DELTASPIKE-293: --- Summary: Improve the ViewScopedContext by observing ServletContext and HttpSession lifecycle events. Key: DELTASPIKE-293 URL: https://issues.apache.org/jira/browse/DELTASPIKE-293 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.4-incubating Reporter: Radu Creanga Fix For: 0.5-incubating The CDI specification states that Context implementations are responsible for destroying instances it creates. The current ViewScopedContext relies on PreDestroyViewMapEvents to be notified when a view map is destroyed. But, the JSF 2.0 and 2.1 spec only fire this event when a view map is replaced. This means that in most cases, instances created by ViewScopedContext are not properly destroyed. The ViewScopedContext should be observing ServletContext and HttpSession lifecycle events instead in order to ensure that all instances it creates are properly destroyed. Visible improvements resulting out of this would be that the @PostConstruct method of @ViewScoped beans is invoked. Additionally, this will probably result in better memory usage, since instances that are not properly destroyed are not eligible for GC. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Resolved] (DELTASPIKE-285) MinimalMessagesTest fails on WLS12c
Thanks a lot Rudy! Do you also know anything about the following WLS related issues? https://issues.apache.org/jira/browse/DELTASPIKE-241 https://issues.apache.org/jira/browse/DELTASPIKE-261 LieGrue, strub - Original Message - From: Rudy De Busscher (JIRA) j...@apache.org To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, October 22, 2012 6:00 PM Subject: [jira] [Resolved] (DELTASPIKE-285) MinimalMessagesTest fails on WLS12c [ https://issues.apache.org/jira/browse/DELTASPIKE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudy De Busscher resolved DELTASPIKE-285. - Resolution: Fixed Fix Version/s: 0.4-incubating MinimalMessagesTest fails on WLS12c --- Key: DELTASPIKE-285 URL: https://issues.apache.org/jira/browse/DELTASPIKE-285 Project: DeltaSpike Issue Type: Test Components: Core Affects Versions: 0.2-incubating Environment: WLS12C Reporter: Rudy De Busscher Priority: Minor Fix For: 0.4-incubating Was already a long time on my TODO list Test archive fails during deployment with org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [MessageContext] with qualifiers [@Default] at injection point [[field] @Inject private org.apache.deltaspike.test.core.api.message.MessageContextTest.messageContext] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Resolved] (DELTASPIKE-285) MinimalMessagesTest fails on WLS12c
Hi Mark, Working on them when I have time. Since this is not much lately, It will take some more time I'm afraid before they get fixed. but eventually Rudy On 24 October 2012 10:22, Mark Struberg strub...@yahoo.de wrote: Thanks a lot Rudy! Do you also know anything about the following WLS related issues? https://issues.apache.org/jira/browse/DELTASPIKE-241 https://issues.apache.org/jira/browse/DELTASPIKE-261 LieGrue, strub - Original Message - From: Rudy De Busscher (JIRA) j...@apache.org To: deltaspike-dev@incubator.apache.org Cc: Sent: Monday, October 22, 2012 6:00 PM Subject: [jira] [Resolved] (DELTASPIKE-285) MinimalMessagesTest fails on WLS12c [ https://issues.apache.org/jira/browse/DELTASPIKE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudy De Busscher resolved DELTASPIKE-285. - Resolution: Fixed Fix Version/s: 0.4-incubating MinimalMessagesTest fails on WLS12c --- Key: DELTASPIKE-285 URL: https://issues.apache.org/jira/browse/DELTASPIKE-285 Project: DeltaSpike Issue Type: Test Components: Core Affects Versions: 0.2-incubating Environment: WLS12C Reporter: Rudy De Busscher Priority: Minor Fix For: 0.4-incubating Was already a long time on my TODO list Test archive fails during deployment with org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [MessageContext] with qualifiers [@Default] at injection point [[field] @Inject private org.apache.deltaspike.test.core.api.message.MessageContextTest.messageContext] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Resolved] (DELTASPIKE-161) veto internal beans annotated with @Typed()
such classes are still known by the container and that isn't needed. regards, gerhard 2012/6/10 Mark Struberg strub...@yahoo.de No, they are NOT injectable via @Inject, only with @New (which isn't widely used). Additionally vetoing @Typed() beans make absolutely no sense imo. It just costs performance at startup. And if we do it for _all_ beans, then it could have a negative effect if people like to use @New (rarely used, but still). LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Sent: Saturday, June 9, 2012 10:19 PM Subject: Re: [jira] [Resolved] (DELTASPIKE-161) veto internal beans annotated with @Typed() yes - we are using @Typed() (empty) only for internal util- and helper-classes which shouldn't be beans - but if we don't veto such classes, it doesn't make sense to mark such classes with @Typed(). (as you said - they are still injectable beans (at least with @New).) as an alternative we can disable the possibility to deactivate @Exclude for internal classes, however, this ticket is open (and in progress) since april - please start such discussions a bit earlier (if possible). regards, gerhard 2012/6/9 Mark Struberg strub...@yahoo.de @New in combination with @Typed is perfectly fine! @Typed is perfectly fine on it's own. Using @Exclude() is only fine as long as you don't disable it. As this scenario is possible, we shall only use @Typed() and not use @Exclude() in DS internally. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Saturday, June 9, 2012 12:05 PM Subject: Re: [jira] [Resolved] (DELTASPIKE-161) veto internal beans annotated with @Typed() hi, right now we only use @Typed() for util, helper,... classes. we can change it at any time if we really have a case which isn't just theory (imo we shouldn't use @Typed() in combination with @New at all). regards, gerhard 2012/6/9 Mark Struberg strub...@yahoo.de I don't get that issue. Yes, we should not use @Exclude() instead of @Typed internally. But no, we MUST NOT veto() beans which are @Typed()! @Typed() beans can still be used for @New! LieGrue, strub - Original Message - From: Gerhard Petracek (JIRA) j...@apache.org To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, June 7, 2012 2:12 PM Subject: [jira] [Resolved] (DELTASPIKE-161) veto internal beans annotated with @Typed() [ https://issues.apache.org/jira/browse/DELTASPIKE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-161. - Resolution: Fixed veto internal beans annotated with @Typed() --- Key: DELTASPIKE-161 URL: https://issues.apache.org/jira/browse/DELTASPIKE-161 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.2-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.3-incubating we shouldn't use @Exclude internally because it's possible to deactivate it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Resolved] (DELTASPIKE-161) veto internal beans annotated with @Typed()
I don't get that issue. Yes, we should not use @Exclude() instead of @Typed internally. But no, we MUST NOT veto() beans which are @Typed()! @Typed() beans can still be used for @New! LieGrue, strub - Original Message - From: Gerhard Petracek (JIRA) j...@apache.org To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, June 7, 2012 2:12 PM Subject: [jira] [Resolved] (DELTASPIKE-161) veto internal beans annotated with @Typed() [ https://issues.apache.org/jira/browse/DELTASPIKE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-161. - Resolution: Fixed veto internal beans annotated with @Typed() --- Key: DELTASPIKE-161 URL: https://issues.apache.org/jira/browse/DELTASPIKE-161 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.2-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.3-incubating we shouldn't use @Exclude internally because it's possible to deactivate it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Resolved] (DELTASPIKE-161) veto internal beans annotated with @Typed()
@New in combination with @Typed is perfectly fine! @Typed is perfectly fine on it's own. Using @Exclude() is only fine as long as you don't disable it. As this scenario is possible, we shall only use @Typed() and not use @Exclude() in DS internally. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Saturday, June 9, 2012 12:05 PM Subject: Re: [jira] [Resolved] (DELTASPIKE-161) veto internal beans annotated with @Typed() hi, right now we only use @Typed() for util, helper,... classes. we can change it at any time if we really have a case which isn't just theory (imo we shouldn't use @Typed() in combination with @New at all). regards, gerhard 2012/6/9 Mark Struberg strub...@yahoo.de I don't get that issue. Yes, we should not use @Exclude() instead of @Typed internally. But no, we MUST NOT veto() beans which are @Typed()! @Typed() beans can still be used for @New! LieGrue, strub - Original Message - From: Gerhard Petracek (JIRA) j...@apache.org To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, June 7, 2012 2:12 PM Subject: [jira] [Resolved] (DELTASPIKE-161) veto internal beans annotated with @Typed() [ https://issues.apache.org/jira/browse/DELTASPIKE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-161. - Resolution: Fixed veto internal beans annotated with @Typed() --- Key: DELTASPIKE-161 URL: https://issues.apache.org/jira/browse/DELTASPIKE-161 Project: DeltaSpike Issue Type: Improvement Components: Core Affects Versions: 0.2-incubating Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.3-incubating we shouldn't use @Exclude internally because it's possible to deactivate it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Updated] (DELTASPIKE-13) Choose documentation format and tools
I'm going to resurrect this thread, see if we can come to a consensus on what we want to use for documentation. As I currently understand things there are a few options on the table for documentation of DeltaSpike: * Apache CMS -- AIUI, this is a perl script that runs some extra stuff. More info and history is available at http://www.apache.org/dev/cms. Not sure if you have to be using SVN to get the rebuild on checkin support or not. * DocBook -- I think we're all familiar with DocBook. * Sphinx or plain ReStructuredText -- A wiki markup. Somewhat difficult to use and remember, heavily used in the Python community * Markdown -- We all know what that is. It has native support in apache-cms. Great for simple stuff, starts breaking down quickly when used for technical documentation * asciidoc -- Another wiki markup.http://www.methods.co.nz/asciidoc/. Easy to use, very similar to markdown, more expressive, very similar feature set to docbook. Earlier in this thread we wanted to have the ability to have buildable docs by maven. However, if there isn't a plugin already available, which to my knowledge would take out everything but docbook and sphinx, possibly markdown, we'd have to build one. We also want it easy for contributors to use, which is a downside to docbook and sphinx. If anyone has any others they'd like to put into the match, please speak up. On Fri, Apr 13, 2012 at 5:57 PM, Gerhard Petracek (Updated) (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/DELTASPIKE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Gerhard Petracek updated DELTASPIKE-13: --- Fix Version/s: 0.4-incubating Choose documentation format and tools - Key: DELTASPIKE-13 URL: https://issues.apache.org/jira/browse/DELTASPIKE-13 Project: DeltaSpike Issue Type: Task Reporter: Shane Bryzak Assignee: Jason Porter Fix For: 0.4-incubating We need to decide on a documentation format for the DeltaSpike documentation. Requirements are: 1. Kept in the VCS with the DeltaSpike codebase 2. Buildable with Maven 3. Can generate multiple formats, including HTML and PDF Currently the industry standard is DocBook, however there may be other alternatives which are more suitable. Suggestions welcome here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: [jira] [Updated] (DELTASPIKE-13) Choose documentation format and tools
@ our apache-cms experts: it would be nice if you share your experience at the previous thread (see [1]). regards, gerhard [1] http://s.apache.org/QIe 2012/5/4 Jason Porter lightguard...@gmail.com I'm going to resurrect this thread, see if we can come to a consensus on what we want to use for documentation. As I currently understand things there are a few options on the table for documentation of DeltaSpike: * Apache CMS -- AIUI, this is a perl script that runs some extra stuff. More info and history is available at http://www.apache.org/dev/cms. Not sure if you have to be using SVN to get the rebuild on checkin support or not. * DocBook -- I think we're all familiar with DocBook. * Sphinx or plain ReStructuredText -- A wiki markup. Somewhat difficult to use and remember, heavily used in the Python community * Markdown -- We all know what that is. It has native support in apache-cms. Great for simple stuff, starts breaking down quickly when used for technical documentation * asciidoc -- Another wiki markup.http://www.methods.co.nz/asciidoc/. Easy to use, very similar to markdown, more expressive, very similar feature set to docbook. Earlier in this thread we wanted to have the ability to have buildable docs by maven. However, if there isn't a plugin already available, which to my knowledge would take out everything but docbook and sphinx, possibly markdown, we'd have to build one. We also want it easy for contributors to use, which is a downside to docbook and sphinx. If anyone has any others they'd like to put into the match, please speak up. On Fri, Apr 13, 2012 at 5:57 PM, Gerhard Petracek (Updated) (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/DELTASPIKE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-13: --- Fix Version/s: 0.4-incubating Choose documentation format and tools - Key: DELTASPIKE-13 URL: https://issues.apache.org/jira/browse/DELTASPIKE-13 Project: DeltaSpike Issue Type: Task Reporter: Shane Bryzak Assignee: Jason Porter Fix For: 0.4-incubating We need to decide on a documentation format for the DeltaSpike documentation. Requirements are: 1. Kept in the VCS with the DeltaSpike codebase 2. Buildable with Maven 3. Can generate multiple formats, including HTML and PDF Currently the industry standard is DocBook, however there may be other alternatives which are more suitable. Suggestions welcome here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
+1 I like the approach. On 27 Mar 2012, at 21:06, Gerhard Petracek wrote: hi jason, in case of AnnotationBuilder we can think about reducing the technical visibility. for the other parts it should be enough to reduce the visibility via an organizational approach e.g. via moving them to the util package (that's similar to [1]). so we can document that there is just quite special stuff. - most users just have to look at the api package to use the core, some might need the spi package to change the behaviour of some parts) and for very special cases they can have a look at the util package. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE-88 2012/3/27 Jason Porter lightguard...@gmail.com This is fine and all, but I don't really see how this helps with the visibility issue which started this discussion. Moving them to a different package will still have the same problem. Sent from my iPhone On Mar 27, 2012, at 11:35, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi pete, at least it would be great to have a separation. (so i suggested to move it e.g. to the util-package or a sub-package of it). regards, gerhard 2012/3/27 Pete Muir pm...@redhat.com This was one of the main purposes of Solder, which is where these classes come from. Perhaps we need a deltaspike toolbox module. On 26 Mar 2012, at 22:01, Matt Benson wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
+1 LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Wednesday, March 28, 2012 1:43 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner +1 I like the approach. On 27 Mar 2012, at 21:06, Gerhard Petracek wrote: hi jason, in case of AnnotationBuilder we can think about reducing the technical visibility. for the other parts it should be enough to reduce the visibility via an organizational approach e.g. via moving them to the util package (that's similar to [1]). so we can document that there is just quite special stuff. - most users just have to look at the api package to use the core, some might need the spi package to change the behaviour of some parts) and for very special cases they can have a look at the util package. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE-88 2012/3/27 Jason Porter lightguard...@gmail.com This is fine and all, but I don't really see how this helps with the visibility issue which started this discussion. Moving them to a different package will still have the same problem. Sent from my iPhone On Mar 27, 2012, at 11:35, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi pete, at least it would be great to have a separation. (so i suggested to move it e.g. to the util-package or a sub-package of it). regards, gerhard 2012/3/27 Pete Muir pm...@redhat.com This was one of the main purposes of Solder, which is where these classes come from. Perhaps we need a deltaspike toolbox module. On 26 Mar 2012, at 22:01, Matt Benson wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
This was one of the main purposes of Solder, which is where these classes come from. Perhaps we need a deltaspike toolbox module. On 26 Mar 2012, at 22:01, Matt Benson wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Jason Porter Fix For: 0.2-incubating ... since those classes aren't intended to be used by users, we should re-visit them. if we can't keep them package-private, we could move them to the util-package (like we did with ClassDeactivation now ClassDeactivationUtils) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
hi pete, at least it would be great to have a separation. (so i suggested to move it e.g. to the util-package or a sub-package of it). regards, gerhard 2012/3/27 Pete Muir pm...@redhat.com This was one of the main purposes of Solder, which is where these classes come from. Perhaps we need a deltaspike toolbox module. On 26 Mar 2012, at 22:01, Matt Benson wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Jason Porter Fix For: 0.2-incubating ... since those classes aren't intended to be used by users, we should re-visit them. if we can't keep them package-private, we could move them to the util-package (like we did with ClassDeactivation now ClassDeactivationUtils) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
This is fine and all, but I don't really see how this helps with the visibility issue which started this discussion. Moving them to a different package will still have the same problem. Sent from my iPhone On Mar 27, 2012, at 11:35, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi pete, at least it would be great to have a separation. (so i suggested to move it e.g. to the util-package or a sub-package of it). regards, gerhard 2012/3/27 Pete Muir pm...@redhat.com This was one of the main purposes of Solder, which is where these classes come from. Perhaps we need a deltaspike toolbox module. On 26 Mar 2012, at 22:01, Matt Benson wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Jason Porter Fix For: 0.2-incubating ... since those classes aren't intended to be used by users, we should re-visit them. if we can't keep them package-private, we could move them to the util-package (like we did with ClassDeactivation now ClassDeactivationUtils) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
hi jason, in case of AnnotationBuilder we can think about reducing the technical visibility. for the other parts it should be enough to reduce the visibility via an organizational approach e.g. via moving them to the util package (that's similar to [1]). so we can document that there is just quite special stuff. - most users just have to look at the api package to use the core, some might need the spi package to change the behaviour of some parts) and for very special cases they can have a look at the util package. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE-88 2012/3/27 Jason Porter lightguard...@gmail.com This is fine and all, but I don't really see how this helps with the visibility issue which started this discussion. Moving them to a different package will still have the same problem. Sent from my iPhone On Mar 27, 2012, at 11:35, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi pete, at least it would be great to have a separation. (so i suggested to move it e.g. to the util-package or a sub-package of it). regards, gerhard 2012/3/27 Pete Muir pm...@redhat.com This was one of the main purposes of Solder, which is where these classes come from. Perhaps we need a deltaspike toolbox module. On 26 Mar 2012, at 22:01, Matt Benson wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
It could, I sort of envisioned that's what Core was for. On Mon, Mar 26, 2012 at 15:01, Matt Benson gudnabr...@gmail.com wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Jason Porter Fix For: 0.2-incubating ... since those classes aren't intended to be used by users, we should re-visit them. if we can't keep them package-private, we could move them to the util-package (like we did with ClassDeactivation now ClassDeactivationUtils) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
'Core' means that this are all things which will not only run in Java EE but also in Java SE. This includes end-user functionality as well as Extension programmer tools. We just need to put them into different packages. Core just means that we don't force any additional dependencies on our users. The reason I don't like to split those things out into own jars is that it soon gets really complicated to get the modularity right without restricting ourselfs too much. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org; gudnabr...@gmail.com Cc: Sent: Monday, March 26, 2012 11:07 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner It could, I sort of envisioned that's what Core was for. On Mon, Mar 26, 2012 at 15:01, Matt Benson gudnabr...@gmail.com wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Jason Porter Fix For: 0.2-incubating ... since those classes aren't
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
Makes sense, guys--back to the peanut gallery for me. :) Matt On Mon, Mar 26, 2012 at 4:36 PM, Mark Struberg strub...@yahoo.de wrote: 'Core' means that this are all things which will not only run in Java EE but also in Java SE. This includes end-user functionality as well as Extension programmer tools. We just need to put them into different packages. Core just means that we don't force any additional dependencies on our users. The reason I don't like to split those things out into own jars is that it soon gets really complicated to get the modularity right without restricting ourselfs too much. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org; gudnabr...@gmail.com Cc: Sent: Monday, March 26, 2012 11:07 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner It could, I sort of envisioned that's what Core was for. On Mon, Mar 26, 2012 at 15:01, Matt Benson gudnabr...@gmail.com wrote: Could it be that certain classes belong in some DS artifact that is meant to serve as a toolbox for extension authors, then? Matt On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote: For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Jason Porter Fix For: 0.2-incubating ... since those classes aren't intended to be used by users, we should re-visit them. if we can't keep them package-private, we could move them to the util-package (like we did with ClassDeactivation now ClassDeactivationUtils) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Jason Porter Fix For: 0.2-incubating ... since those classes aren't intended to be used by users, we should re-visit them. if we can't keep them package-private, we could move them to the util-package (like we did with ClassDeactivation now ClassDeactivationUtils) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Jason Porter Fix For: 0.2-incubating ... since those classes aren't intended to be used by users, we should re-visit them. if we can't keep them package-private, we could move them to the util-package (like we did with ClassDeactivation now ClassDeactivationUtils) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner
For now, the wiki is as good as anywhere else. Sent from my iPhone On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote: Ok, I see that they are not used. So, what is the objection to these classes? No clear use case? If so, where do I document the use cases? IMO they are all useful things for extension authors. On 25 Mar 2012, at 18:15, Pete Muir wrote: Maybe this is just a cultural mismatch. Do Apache projects expect people to rely on the API packages and Implementation packages when writing code? Anyway, this goes back to my original question. How do you reduce the visibility of these classes without affecting the API. Other classes expose them via methods, so it's not as simple as just reduce the visibility... On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: imo they shouldn't be part of the api and i'm not sure if they fit in the spi package, because you don't need them to customize deltaspike. they are just helpers which are even quite special for extensions authors. regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com Yes, this is definitely all squarely aimed at extension authors and not end user apps IMO. On 25 Mar 2012, at 18:03, Mark Struberg wrote: Is this useful for Extension implementers? If so we might think about putting them into spi packages? LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Sunday, March 25, 2012 6:36 PM Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner On 25 Mar 2012, at 17:30, Gerhard Petracek wrote: hi pete, that would be possible e.g. with AnnotationBuilder. however, it isn't possible with all of them. Why? - we already moved internal helpers to org.apache.deltaspike.core.util if we need them in the api-module. they might not provide a stable api (over time) or are quite special. we moved them there to remove the visibility via an organizational approach. I have no problem with this approach. Perhaps you could expand on what you mean here then? Do you mean extract interfaces from these classes and move the implementation to core? I can't see how you can reduce the visibility without changing the API? regards, gerhard 2012/3/25 Pete Muir pm...@redhat.com I assume you mean the visibility of the constructors of AnnotationBuilder, ImmutableInjectioPoint, InjectableMethod, and ParameterValue? Begin forwarded message: From: Gerhard Petracek (Created) (JIRA) j...@apache.org Subject: [jira] [Created] (DELTASPIKE-129) re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner Date: 25 March 2012 16:39:27 GMT+01:00 To: deltaspike-dev@incubator.apache.org re-visit visibility of AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and ParameterValueRedefiner --- Key: DELTASPIKE-129 URL: https://issues.apache.org/jira/browse/DELTASPIKE-129 Project: DeltaSpike Issue Type: Task Components: Core Affects Versions: 0.1-incubating Reporter: Gerhard Petracek Assignee: Jason Porter Fix For: 0.2-incubating ... since those classes aren't intended to be used by users, we should re-visit them. if we can't keep them package-private, we could move them to the util-package (like we did with ClassDeactivation now ClassDeactivationUtils) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-61) global alternatives
I filed a Weld issue to track this (https://issues.jboss.org/browse/WELD-1066) Mark, could you comment on the issue with an example of how this is configured in OWB so that Weld is aligned if possible? Thanks. On 01/26/2012 07:09 PM, Mark Struberg wrote: yup, thats CDI-18 [1] But I fear that CDI-1.1 containers will be mainstream only in 2 years or so. Instead I'd welcome if Weld would introduce a flag (for their CDI-1.0 implementations) where this can be enabled - like OWB does. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-18 - Original Message - From: Adam Warskiad...@softwaremill.pl To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, January 26, 2012 6:46 PM Subject: Re: [jira] [Created] (DELTASPIKE-61) global alternatives Wasn't global alternative enablement a feature planned for CDI 1.1? And, besides, that's how it works in Weld currently anyway as far as I know ;) Adam On Jan 26, 2012, at 4:00 PM, Gerhard Petracek (Created) (JIRA) wrote: global alternatives --- Key: DELTASPIKE-61 URL: https://issues.apache.org/jira/browse/DELTASPIKE-61 Project: DeltaSpike Issue Type: New Feature Components: Core Affects Versions: 0.1 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.2 @Alternative should work across BDAs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Adam Warski CTO, SoftwareMill http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org +48 660 703 691
Re: [jira] [Created] (DELTASPIKE-61) global alternatives
hi jozef, it's org.apache.webbeans.useBDABeansXMLScanner and i added it as comment to WELD-1066. regards, gerhard 2012/2/13 Jozef Hartinger jhart...@redhat.com I filed a Weld issue to track this (https://issues.jboss.org/** browse/WELD-1066 https://issues.jboss.org/browse/WELD-1066) Mark, could you comment on the issue with an example of how this is configured in OWB so that Weld is aligned if possible? Thanks. On 01/26/2012 07:09 PM, Mark Struberg wrote: yup, thats CDI-18 [1] But I fear that CDI-1.1 containers will be mainstream only in 2 years or so. Instead I'd welcome if Weld would introduce a flag (for their CDI-1.0 implementations) where this can be enabled - like OWB does. LieGrue, strub [1] https://issues.jboss.org/**browse/CDI-18https://issues.jboss.org/browse/CDI-18 - Original Message - From: Adam Warskiad...@softwaremill.pl To: deltaspike-dev@incubator.**apache.orgdeltaspike-dev@incubator.apache.org Cc: Sent: Thursday, January 26, 2012 6:46 PM Subject: Re: [jira] [Created] (DELTASPIKE-61) global alternatives Wasn't global alternative enablement a feature planned for CDI 1.1? And, besides, that's how it works in Weld currently anyway as far as I know ;) Adam On Jan 26, 2012, at 4:00 PM, Gerhard Petracek (Created) (JIRA) wrote: global alternatives --- Key: DELTASPIKE-61 URL: https://issues.apache.org/** jira/browse/DELTASPIKE-61https://issues.apache.org/jira/browse/DELTASPIKE-61 Project: DeltaSpike Issue Type: New Feature Components: Core Affects Versions: 0.1 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.2 @Alternative should work across BDAs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/**jira/secure/**ContactAdministrators!default. **jspahttps://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/** software/jira http://www.atlassian.com/software/jira -- Adam Warski CTO, SoftwareMill http://twitter.com/#!/**adamwarski http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org +48 660 703 691
Re: [jira] [Commented] (DELTASPIKE-64) review and discuss @Secured
I personally like the binding approach a little better. It seems to be more
similar to the CDI way of doing interceptors (which, at the end of the day
is essentially what we're doing). However, we have seen a need of doing
@Admin || @User or @Admin @User. The and is fairly easy, but the or is
currently not covered and we need to be able to do that.
On Tue, Jan 31, 2012 at 04:56, Shane Bryzak (Commented) (JIRA)
j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/DELTASPIKE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13196852#comment-13196852]
Shane Bryzak commented on DELTASPIKE-64:
In Seam Security we have a system of typesafe security annotations.
Essentially, it's up to the developer to create the annotations required
for the authorization checks in their application. The security binding
annotations are annotated with @SecurityBindingType, here's an example:
@SecurityBindingType
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Admin {
}
The annotation may declare member variables also which are taken into
account for the authorization check, unless the member is annotated
@Nonbinding.
Authorizer methods are used to determine whether a user has sufficient
privileges to invoke a secured method. The @Secures annotation is used in
combination with the security binding type annotation to declare the
authorizer method, eg:
public @Secures @Admin boolean isAdmin(Identity identity) {
return identity.hasRole(admin, USERS, GROUP);
}
This allows combinations of security binding types to be declared on a
single method or class, and also has the advantage of allowing the user to
declare all of their security business logic in a single bean. Once the
security binding type annotation and the authorizer method is declared, it
is then a simple matter of applying the annotation:
@Admin
public void doSomethingRestricted() {
messages.info(doSomethingRestricted() invoked);
}
review and discuss @Secured
---
Key: DELTASPIKE-64
URL: https://issues.apache.org/jira/browse/DELTASPIKE-64
Project: DeltaSpike
Issue Type: Sub-task
Components: Security-Module
Affects Versions: 0.1
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Fix For: 0.2
this feature is listed at
https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Rankingand
part of myfaces codi-core.
@Secured is a simple cdi interceptor annotation which allows to filter
method calls to cdi beans based on custom rules.
it's possible to specify 1-n custom implementations of
AccessDecisionVoter. those voters get invoked before the call is forwarded
to the target method (a voter is a cdi bean which gets resolved by its
concrete type). an implementation of AccessDecisionVoter can access the
InvocationContext to get further details about the target method to trigger
the corresponding evaluation. as a result voters return a set of violations
(SecurityViolation). if there is no violation, the target-method gets
executed. if there is at least one violation, an AccessDeniedException will
be thrown.
in addition an AccessDecisionVoterContext is needed to detect if there
is an ongoing security check (e.g. it's possible to use it in a custom
scope to avoid that a security check postpones the expiration).
(in myfaces codi it's also used to secure views via view-configs,
however, we will exclude this part for now.)
users can use those simple and generic apis to implement their own
access control and it will get used by other deltaspike modules
automatically (if they use the security-api).
(in an AccessDecisionVoter it's possible to integrate 3rd party
security-frameworks.)
usage of @Secured:
//...
@Secured({MyAccessDecisionVoter1.class, MyAccessDecisionVoter2.class})
public class SecuredBean
{
//...
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Re: [jira] [Created] (DELTASPIKE-61) global alternatives
hi adam, see http://s.apache.org/TFf regards, gerhard 2012/1/26 Adam Warski ad...@softwaremill.pl Wasn't global alternative enablement a feature planned for CDI 1.1? And, besides, that's how it works in Weld currently anyway as far as I know ;) Adam On Jan 26, 2012, at 4:00 PM, Gerhard Petracek (Created) (JIRA) wrote: global alternatives --- Key: DELTASPIKE-61 URL: https://issues.apache.org/jira/browse/DELTASPIKE-61 Project: DeltaSpike Issue Type: New Feature Components: Core Affects Versions: 0.1 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.2 @Alternative should work across BDAs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Adam Warski CTO, SoftwareMill http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org +48 660 703 691
Re: [jira] [Created] (DELTASPIKE-61) global alternatives
yup, thats CDI-18 [1] But I fear that CDI-1.1 containers will be mainstream only in 2 years or so. Instead I'd welcome if Weld would introduce a flag (for their CDI-1.0 implementations) where this can be enabled - like OWB does. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-18 - Original Message - From: Adam Warski ad...@softwaremill.pl To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, January 26, 2012 6:46 PM Subject: Re: [jira] [Created] (DELTASPIKE-61) global alternatives Wasn't global alternative enablement a feature planned for CDI 1.1? And, besides, that's how it works in Weld currently anyway as far as I know ;) Adam On Jan 26, 2012, at 4:00 PM, Gerhard Petracek (Created) (JIRA) wrote: global alternatives --- Key: DELTASPIKE-61 URL: https://issues.apache.org/jira/browse/DELTASPIKE-61 Project: DeltaSpike Issue Type: New Feature Components: Core Affects Versions: 0.1 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.2 @Alternative should work across BDAs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Adam Warski CTO, SoftwareMill http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org +48 660 703 691
Re: [jira] [Created] (DELTASPIKE-61) global alternatives
yes, I think this is an easy feature to implement even in CDI-1.0 containers, because it doesn't require an API change! Thus we can easily add those features even for older EE servers and make it switchable. We now just need to get the interceptor ordering finally to the paper ;) LieGrue, strub - Original Message - From: Pete Muir pm...@redhat.com To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Thursday, January 26, 2012 9:15 PM Subject: Re: [jira] [Created] (DELTASPIKE-61) global alternatives Sent it to Jozef as an idea to do this in Weld :-) On 26 Jan 2012, at 18:09, Mark Struberg wrote: yup, thats CDI-18 [1] But I fear that CDI-1.1 containers will be mainstream only in 2 years or so. Instead I'd welcome if Weld would introduce a flag (for their CDI-1.0 implementations) where this can be enabled - like OWB does. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-18 - Original Message - From: Adam Warski ad...@softwaremill.pl To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, January 26, 2012 6:46 PM Subject: Re: [jira] [Created] (DELTASPIKE-61) global alternatives Wasn't global alternative enablement a feature planned for CDI 1.1? And, besides, that's how it works in Weld currently anyway as far as I know ;) Adam On Jan 26, 2012, at 4:00 PM, Gerhard Petracek (Created) (JIRA) wrote: global alternatives --- Key: DELTASPIKE-61 URL: https://issues.apache.org/jira/browse/DELTASPIKE-61 Project: DeltaSpike Issue Type: New Feature Components: Core Affects Versions: 0.1 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.2 @Alternative should work across BDAs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Adam Warski CTO, SoftwareMill http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org +48 660 703 691
Re: [jira] [Commented] (DELTASPIKE-36) review and discuss ConfiguredValueResolver
Do you have a link to where this is in OWB? example maybe?
On Tue, Dec 27, 2011 at 6:04 PM, Gerhard Petracek (Commented) (JIRA)
j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/DELTASPIKE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176350#comment-13176350]
Gerhard Petracek commented on DELTASPIKE-36:
if we agree on a manual implementation, we can fix the first disadvantage.
e.g .
public class CustomConfiguredValueResolver implements
ConfiguredValueResolver
{
@Delegate //gets injected manually as soon as it is needed during the
bootstrapping process of the cdi container
private ConfiguredValueResolver defaultConfiguredValueResolver;
//...
}
- a custom implementation can delegate to the default implementation
without knowing it
review and discuss ConfiguredValueResolver
--
Key: DELTASPIKE-36
URL: https://issues.apache.org/jira/browse/DELTASPIKE-36
Project: DeltaSpike
Issue Type: Task
Components: Core
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
for several features we need a pluggable config-service which has to be
independent of cdi because it's needed e.g. during the bootstrapping
process of a cdi container.
an implementation is aware of a config source like property-files or xml
files or jndi values and has to return 1-n configured values for a given
key.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (DELTASPIKE-36) review and discuss ConfiguredValueResolver
Gerhard,
Apologies for jumping the gun. didn't read right and thought this was the
discuss.
John
On Tue, Dec 27, 2011 at 6:36 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi john,
thx for the question. i added the link to the jira issue.
i'll start a thread about it (similar to the other feature threads) as soon
as the jira issue is ready for the discussion.
regards,
gerhard
2011/12/28 John D. Ament john.d.am...@gmail.com
Do you have a link to where this is in OWB? example maybe?
On Tue, Dec 27, 2011 at 6:04 PM, Gerhard Petracek (Commented) (JIRA)
j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/DELTASPIKE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176350#comment-13176350
]
Gerhard Petracek commented on DELTASPIKE-36:
if we agree on a manual implementation, we can fix the first
disadvantage.
e.g .
public class CustomConfiguredValueResolver implements
ConfiguredValueResolver
{
@Delegate //gets injected manually as soon as it is needed during the
bootstrapping process of the cdi container
private ConfiguredValueResolver defaultConfiguredValueResolver;
//...
}
- a custom implementation can delegate to the default implementation
without knowing it
review and discuss ConfiguredValueResolver
--
Key: DELTASPIKE-36
URL:
https://issues.apache.org/jira/browse/DELTASPIKE-36
Project: DeltaSpike
Issue Type: Task
Components: Core
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
for several features we need a pluggable config-service which has to
be
independent of cdi because it's needed e.g. during the bootstrapping
process of a cdi container.
an implementation is aware of a config source like property-files or
xml
files or jndi values and has to return 1-n configured values for a
given
key.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools
Just a follow up, there is at least one well known Java Project using Sphinx for documentation: Selenium, also Spock is using it, though they're not building their docs as part of a CI job. A large list of projects using Sphinx is also available at [1]. The Selenium pom [2] uses antrun to call the build file (make, sh, python, etc) for the docs. There's also readthedocs [3] which is interesting and hosts the docs there. Some more info to think about. The project Dan and I linked to also looks like it's fairly decent for what it does. [1] http://sphinx.pocoo.org/examples.html [2] http://code.google.com/p/selenium/source/browse/websites/www.seleniumhq.org/pom.xml [3] http://readthedocs.org/ On Fri, Dec 23, 2011 at 12:50, Dan Allen dan.j.al...@gmail.com wrote: On Fri, Dec 23, 2011 at 13:18, Gerhard Petracek gerhard.petra...@gmail.comwrote: if there are too many open questions right now, i would suggest that we start with docbook and evaluate the alternatives within the next weeks. Choosing docbook for this reason seems like just giving up before the match begins. Jason is absolutely right that docbook is a huge barrier to open source contributions and totally overkill/bloatware for writing sentences. Sphinx allows you to do just that, write sentences. No B.S. No special editor. No angled brackets. Just type. It's essentially markdown, or a variant of it [1], put into a scaffolding for a book. The Maven plugin seems very up to date and I really doubt there will be much trouble to get it to run [2]. With Sphinx, you are going to get better docs from day one. Any project should jump at that prospect, given how notorious projects are for having bad docs. Sphinx is a tool that makes it easy to create intelligent and beautiful documentation Btw, we aren't necessarily advocating for Sphinx as we are advocating for writing docs in plain text. Sphinx just happens to offer the best scaffolding for that purpose. And proven. -Dan [1] http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#quick-syntax-overview [2] https://github.com/tomdz/sphinx-maven/blob/master/README.md -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools
On Fri, Dec 23, 2011 at 15:20, Gerhard Petracek gerhard.petra...@gmail.comwrote: i said: if there are too many open questions right now,... Understood. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction
Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools
Dan, I also like the results Andrew and Aslak had with that for the new Arquillian page. Could you probably provide a skeleton and sample integration which we can tweak? Best would be if you just create a git-clone and provide that on github. then we play around with it and if it turns out to be good, then we can just push this branch to ds.asf:master wdyt? LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 9:20 PM Subject: Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools hi dan, i said: if there are too many open questions right now,... we already discussed that we would use as few docbook-tags as possible (in any case). however, we are going to commit features quite soon and i would prefer to have at least the basic descriptions in the repository from the very beginning (instead of just waiting until this topic is resolved). regards, gerhard 2011/12/23 Dan Allen dan.j.al...@gmail.com On Fri, Dec 23, 2011 at 13:18, Gerhard Petracek gerhard.petra...@gmail.comwrote: if there are too many open questions right now, i would suggest that we start with docbook and evaluate the alternatives within the next weeks. Choosing docbook for this reason seems like just giving up before the match begins. Jason is absolutely right that docbook is a huge barrier to open source contributions and totally overkill/bloatware for writing sentences. Sphinx allows you to do just that, write sentences. No B.S. No special editor. No angled brackets. Just type. It's essentially markdown, or a variant of it [1], put into a scaffolding for a book. The Maven plugin seems very up to date and I really doubt there will be much trouble to get it to run [2]. With Sphinx, you are going to get better docs from day one. Any project should jump at that prospect, given how notorious projects are for having bad docs. Sphinx is a tool that makes it easy to create intelligent and beautiful documentation Btw, we aren't necessarily advocating for Sphinx as we are advocating for writing docs in plain text. Sphinx just happens to offer the best scaffolding for that purpose. And proven. -Dan [1] http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#quick-syntax-overview [2] https://github.com/tomdz/sphinx-maven/blob/master/README.md -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction
Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools
+1 regards, gerhard 2011/12/23 Mark Struberg strub...@yahoo.de Dan, I also like the results Andrew and Aslak had with that for the new Arquillian page. Could you probably provide a skeleton and sample integration which we can tweak? Best would be if you just create a git-clone and provide that on github. then we play around with it and if it turns out to be good, then we can just push this branch to ds.asf:master wdyt? LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 9:20 PM Subject: Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools hi dan, i said: if there are too many open questions right now,... we already discussed that we would use as few docbook-tags as possible (in any case). however, we are going to commit features quite soon and i would prefer to have at least the basic descriptions in the repository from the very beginning (instead of just waiting until this topic is resolved). regards, gerhard 2011/12/23 Dan Allen dan.j.al...@gmail.com On Fri, Dec 23, 2011 at 13:18, Gerhard Petracek gerhard.petra...@gmail.comwrote: if there are too many open questions right now, i would suggest that we start with docbook and evaluate the alternatives within the next weeks. Choosing docbook for this reason seems like just giving up before the match begins. Jason is absolutely right that docbook is a huge barrier to open source contributions and totally overkill/bloatware for writing sentences. Sphinx allows you to do just that, write sentences. No B.S. No special editor. No angled brackets. Just type. It's essentially markdown, or a variant of it [1], put into a scaffolding for a book. The Maven plugin seems very up to date and I really doubt there will be much trouble to get it to run [2]. With Sphinx, you are going to get better docs from day one. Any project should jump at that prospect, given how notorious projects are for having bad docs. Sphinx is a tool that makes it easy to create intelligent and beautiful documentation Btw, we aren't necessarily advocating for Sphinx as we are advocating for writing docs in plain text. Sphinx just happens to offer the best scaffolding for that purpose. And proven. -Dan [1] http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#quick-syntax-overview [2] https://github.com/tomdz/sphinx-maven/blob/master/README.md -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction
Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools
Btw, I do *strongly* recommend using awestruct for creating the website. In 10+ years of creating websites (and applications) I've never encountered anything remotely as productive...esp when all you want to do is create web pages with information. -Dan On Fri, Dec 23, 2011 at 18:25, Dan Allen dan.j.al...@gmail.com wrote: On Fri, Dec 23, 2011 at 15:32, Mark Struberg strub...@yahoo.de wrote: Dan, I also like the results Andrew and Aslak had with that for the new Arquillian page. ...that was mostly done by me, Aslak and Sarah :) I think we are talking about two different things. For Arquillian, we have used Awestruct to build out a website which includes a section of tutorials written in the textile syntax and wrapped in a table of contents and navigation sidebar. Sphinx would be used for the reference guide (documenting each feature and how it's used). We've talked about doing the Arquillian reference guide in Awestruct too, but for now we think that pure reference should be in a dedicated reference guide. Like TorqueBox did, it's possible to dump that into the website, which we may end up doing later. Could you probably provide a skeleton and sample integration which we can tweak? We've been talking about creating a stub for other jboss.org projects to use, but atm I don't have the bandwidth for creating that archetype. You'd have to just clone the arquillian site and work from that starting point. https://github.com/arquillian/arquillian.github.com/tree/develop (the content is on the develop branch) -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction
Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools
On Fri, Dec 23, 2011 at 15:32, Mark Struberg strub...@yahoo.de wrote: Dan, I also like the results Andrew and Aslak had with that for the new Arquillian page. ...that was mostly done by me, Aslak and Sarah :) I think we are talking about two different things. For Arquillian, we have used Awestruct to build out a website which includes a section of tutorials written in the textile syntax and wrapped in a table of contents and navigation sidebar. Sphinx would be used for the reference guide (documenting each feature and how it's used). We've talked about doing the Arquillian reference guide in Awestruct too, but for now we think that pure reference should be in a dedicated reference guide. Like TorqueBox did, it's possible to dump that into the website, which we may end up doing later. Could you probably provide a skeleton and sample integration which we can tweak? We've been talking about creating a stub for other jboss.org projects to use, but atm I don't have the bandwidth for creating that archetype. You'd have to just clone the arquillian site and work from that starting point. https://github.com/arquillian/arquillian.github.com/tree/develop (the content is on the develop branch) -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction
Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools
There's this: https://github.com/tomdz/sphinx-maven If not, I'm sure we can write our own. If we with Sphinx then the question is CPython or Jython for running it. It also looks like there's an ant task wen you go the Jython route. Markdown would be fine, but what would you use to create other kinds of output? I also don't think Markdown has enough richness for documentation. As for the Confluence thing, it's a JBoss Confluence extension, so we'd have to install it. It also doesn't allow for the docs to be easily stored with the code. Sent from my iPhone On Dec 20, 2011, at 6:01, Antoine Sabot-Durand anto...@sabot-durand.net wrote: Sphinx looks nice but is there a maven plugin ? What about Markdown format, it's becoming very popular ? I know it's not directly manage by maven, but wasn't confluence supposed to help generate docbook format from wiki pages ? It could be a good way to keep docbook but have a nice way to generate it painlessly. +1 to have something easier than docbook or some optional helper to generate it. Antoine SABOT-DURAND Le 16 déc. 2011 à 01:01, Jason Porter a écrit : Shane's probably tired of hearing me harp on docbook, oh well :) Here's a tool that's nice to use, output is good and it has a great community following: http://sphinx.pocoo.org/ If we want to look into it, great, if we go back to docbook, great, I'll stop complaining and just use it. Buildable docs is fine, if we have to craft a maven plugin, fine. +1 for a set of a allowed docbook elements should we go with docbook +1 for continuing discussions on the mailing list. On Thu, Dec 15, 2011 at 16:53, Gerhard Petracek gerhard.petra...@gmail.comwrote: +1 for buildable docs if we keep the documentation inside the git repository. -1 for anything else than a maven plugin. if we don't have one for the documentation tool, we can impl. it (or we use a different tool). (+0 for docbook) +1 for an alternative, if it makes sense. @discussions: +1 for continuing to use the mailing list for the main discussion/s - it's easier to follow, mirrored, ... . regards, gerhard 2011/12/16 Jason Porter lightguard...@gmail.com We haven't been discussing other issues on jira, but on the mailing list. Sent from my iPhone On Dec 15, 2011, at 16:31, Shane Bryzak sbry...@gmail.com wrote: You need to add your objections to the issue ;) Buildable by Maven just means we can build the documentation as part of the standard project build/release process. On Fri, Dec 16, 2011 at 9:25 AM, Jason Porter lightguard...@gmail.com wrote: -1 to DocBook it's difficult to get people up to speed and is a turn off for new contributors. Also what exactly do you mean by buildable with maven? Does that mean we need a plugin? Can an ant task or other scripting work? On Thu, Dec 15, 2011 at 15:39, Shane Bryzak (Created) (JIRA) j...@apache.org wrote: Choose documentation format and tools - Key: DELTASPIKE-13 URL: https://issues.apache.org/jira/browse/DELTASPIKE-13 Project: DeltaSpike Issue Type: Task Reporter: Shane Bryzak Assignee: Gerhard Petracek We need to decide on a documentation format for the DeltaSpike documentation. Requirements are: 1. Kept in the VCS with the DeltaSpike codebase 2. Buildable with Maven 3. Can generate multiple formats, including HTML and PDF Currently the industry standard is DocBook, however there may be other alternatives which are more suitable. Suggestions welcome here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: [jira] [Created] (DELTASPIKE-13) Choose documentation format and tools
Shane's probably tired of hearing me harp on docbook, oh well :) Here's a tool that's nice to use, output is good and it has a great community following: http://sphinx.pocoo.org/ If we want to look into it, great, if we go back to docbook, great, I'll stop complaining and just use it. Buildable docs is fine, if we have to craft a maven plugin, fine. +1 for a set of a allowed docbook elements should we go with docbook +1 for continuing discussions on the mailing list. On Thu, Dec 15, 2011 at 16:53, Gerhard Petracek gerhard.petra...@gmail.comwrote: +1 for buildable docs if we keep the documentation inside the git repository. -1 for anything else than a maven plugin. if we don't have one for the documentation tool, we can impl. it (or we use a different tool). (+0 for docbook) +1 for an alternative, if it makes sense. @discussions: +1 for continuing to use the mailing list for the main discussion/s - it's easier to follow, mirrored, ... . regards, gerhard 2011/12/16 Jason Porter lightguard...@gmail.com We haven't been discussing other issues on jira, but on the mailing list. Sent from my iPhone On Dec 15, 2011, at 16:31, Shane Bryzak sbry...@gmail.com wrote: You need to add your objections to the issue ;) Buildable by Maven just means we can build the documentation as part of the standard project build/release process. On Fri, Dec 16, 2011 at 9:25 AM, Jason Porter lightguard...@gmail.com wrote: -1 to DocBook it's difficult to get people up to speed and is a turn off for new contributors. Also what exactly do you mean by buildable with maven? Does that mean we need a plugin? Can an ant task or other scripting work? On Thu, Dec 15, 2011 at 15:39, Shane Bryzak (Created) (JIRA) j...@apache.org wrote: Choose documentation format and tools - Key: DELTASPIKE-13 URL: https://issues.apache.org/jira/browse/DELTASPIKE-13 Project: DeltaSpike Issue Type: Task Reporter: Shane Bryzak Assignee: Gerhard Petracek We need to decide on a documentation format for the DeltaSpike documentation. Requirements are: 1. Kept in the VCS with the DeltaSpike codebase 2. Buildable with Maven 3. Can generate multiple formats, including HTML and PDF Currently the industry standard is DocBook, however there may be other alternatives which are more suitable. Suggestions welcome here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: jira for deltaspike
sbryzak On Tue, Dec 13, 2011 at 6:15 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: short addition: @all initial committers: please send your jira-username. regards, gerhard 2011/12/12 Gerhard Petracek gpetra...@apache.org hi @ all, i've created a jira project [1] for us. i haven't started to configure it. however, please answer to this mail, if you have suggestions for different settings. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE
Re: jira for deltaspike
For Seam 3, and actually all JBoss projects on GitHub, we've added a Git Pull Request sent step which the next step is Pull Request Closed or Rejected. Closed will move to Resolved. Rejected moves it back to open. It's something that everyone can add so community people can say they've sent a pull request for an issue. Since we won't officially be on github it may not work correctly, but something like that I think would be helpful. On Mon, Dec 12, 2011 at 13:26, Gerhard Petracek gpetra...@apache.orgwrote: hi jason, @current workflow: see [1] regards, gerhard [1] http://people.apache.org/~gpetracek/deltaspike/jira_workflow.png 2011/12/12 Jason Porter lightguard...@gmail.com What kind of workflow will we have? On Mon, Dec 12, 2011 at 12:21, Gerhard Petracek gpetra...@apache.org wrote: hi @ all, i've created a jira project [1] for us. i haven't started to configure it. however, please answer to this mail, if you have suggestions for different settings. regards, gerhard [1] https://issues.apache.org/jira/browse/DELTASPIKE -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
