5:21 p.m.
Andrew Rubinger created SHRINKDESC-113:
------------------------------------------
Summary: Move DescriptorNamespace out of the Public API
Key: SHRINKDESC-113
URL: https://issues.jboss.org/browse/SHRINKDESC-113
Project: ShrinkWrap Descriptors
Issue Type: Task
Reporter: Andrew Rubinger
Assignee: Andrew Rubinger
This needs some discussion before being done. It'd break backwards-compatibility with
the 1.x series.
DescriptorNamespace is mutable, which conflicts with the goals outlined in SHRINKDESC-21.
We're not really testing its direct usage at the moment, and I wonder what reason
end-users would have to be invoking its operations to muck around with the
"namespace" of a domain object. Currently all descriptors are supporting its
operations by extension:
{code}public interface WebAppDescriptor extends Descriptor,
DescriptorNamespace<WebAppDescriptor>{code}
...and the methods in question as defined by DescriptorNamespace are:
{code}
public T addDefaultNamespaces();
public T addNamespace(String name, String value);
public List<String> getNamespaces();
public T removeAllNamespaces();{code}
Note that Ralf's work in SHRINKDESC-21 also splits this into DescriptorNamespace and
DescriptorMutableNamespace.
My feeling is that neither should be part of the API; maybe SPI or just internals.
Discuss if it's appropriate to remove this and break the backwards-compatibility with
the 1.x series. In this case, I'm willing to entertain this exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:19 p.m.
[
https://issues.jboss.org/browse/SHRINKDESC-113?page=com.atlassian.jira.pl...
]
Ken Finnigan commented on SHRINKDESC-113:
-----------------------------------------
Also can't think of a reason why you'd be messing with namespaces when either
trying to read items from a Descriptor, or creating them.
Would it be used to test invalid namespaces throw accurate errors in containers? About
the only thing I can think of.
Would be in favour of it moving to at a minimum SPI, if not just internals.
Move DescriptorNamespace out of the Public API
----------------------------------------------
Key: SHRINKDESC-113
URL: https://issues.jboss.org/browse/SHRINKDESC-113
Project: ShrinkWrap Descriptors
Issue Type: Task
Reporter: Andrew Rubinger
Assignee: Andrew Rubinger
This needs some discussion before being done. It'd break backwards-compatibility
with the 1.x series.
DescriptorNamespace is mutable, which conflicts with the goals outlined in SHRINKDESC-21.
We're not really testing its direct usage at the moment, and I wonder what reason
end-users would have to be invoking its operations to muck around with the
"namespace" of a domain object. Currently all descriptors are supporting its
operations by extension:
{code}public interface WebAppDescriptor extends Descriptor,
DescriptorNamespace<WebAppDescriptor>{code}
...and the methods in question as defined by DescriptorNamespace are:
{code}
public T addDefaultNamespaces();
public T addNamespace(String name, String value);
public List<String> getNamespaces();
public T removeAllNamespaces();{code}
Note that Ralf's work in SHRINKDESC-21 also splits this into DescriptorNamespace and
DescriptorMutableNamespace.
My feeling is that neither should be part of the API; maybe SPI or just internals.
Discuss if it's appropriate to remove this and break the backwards-compatibility with
the 1.x series. In this case, I'm willing to entertain this exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:38 a.m.
[
https://issues.jboss.org/browse/SHRINKDESC-113?page=com.atlassian.jira.pl...
]
Ralf Battenfeld commented on SHRINKDESC-113:
--------------------------------------------
Fair question. I remember we discussed this a little bit
here:https://community.jboss.org/message/605293#605293
The common agreement was to provide CRUD operations for the namespaces. I can think of the
case that an end user wants to change the url from http:/... to file://.. for validation
purposes, or to get rid of the namespaces at all.
I agree that this is of limited value, except we make a mistake by configuring the
namespaces...
Personally, I would keep it and not to lock-in this. May we also should think that the
metadata-parser-plugin could be used outside of the descriptors we generate.
Move DescriptorNamespace out of the Public API
----------------------------------------------
Key: SHRINKDESC-113
URL: https://issues.jboss.org/browse/SHRINKDESC-113
Project: ShrinkWrap Descriptors
Issue Type: Task
Reporter: Andrew Rubinger
Assignee: Andrew Rubinger
This needs some discussion before being done. It'd break backwards-compatibility
with the 1.x series.
DescriptorNamespace is mutable, which conflicts with the goals outlined in SHRINKDESC-21.
We're not really testing its direct usage at the moment, and I wonder what reason
end-users would have to be invoking its operations to muck around with the
"namespace" of a domain object. Currently all descriptors are supporting its
operations by extension:
{code}public interface WebAppDescriptor extends Descriptor,
DescriptorNamespace<WebAppDescriptor>{code}
...and the methods in question as defined by DescriptorNamespace are:
{code}
public T addDefaultNamespaces();
public T addNamespace(String name, String value);
public List<String> getNamespaces();
public T removeAllNamespaces();{code}
Note that Ralf's work in SHRINKDESC-21 also splits this into DescriptorNamespace and
DescriptorMutableNamespace.
My feeling is that neither should be part of the API; maybe SPI or just internals.
Discuss if it's appropriate to remove this and break the backwards-compatibility with
the 1.x series. In this case, I'm willing to entertain this exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:56 a.m.
[
https://issues.jboss.org/browse/SHRINKDESC-113?page=com.atlassian.jira.pl...
]
Dan Allen commented on SHRINKDESC-113:
--------------------------------------
I think that namespace manipulation is acceptable as a general purpose facility for XML
dialects, but perhaps something we want "frozen" for standard descriptors such
as web.xml, persistence.xml, etc.
Thus, another alternative here is to allow concrete descriptors (like WebAppDescriptor) to
freeze the namespaces, such that the methods either don't perform any action or throw
an exception when manipulation of the namespaces is attempted. The freeze setting would be
interweaved by the generator, such that you could recreate a clone of the descriptor into
your own package to reenable namespace modification.
Move DescriptorNamespace out of the Public API
----------------------------------------------
Key: SHRINKDESC-113
URL: https://issues.jboss.org/browse/SHRINKDESC-113
Project: ShrinkWrap Descriptors
Issue Type: Task
Reporter: Andrew Rubinger
Assignee: Andrew Rubinger
This needs some discussion before being done. It'd break backwards-compatibility
with the 1.x series.
DescriptorNamespace is mutable, which conflicts with the goals outlined in SHRINKDESC-21.
We're not really testing its direct usage at the moment, and I wonder what reason
end-users would have to be invoking its operations to muck around with the
"namespace" of a domain object. Currently all descriptors are supporting its
operations by extension:
{code}public interface WebAppDescriptor extends Descriptor,
DescriptorNamespace<WebAppDescriptor>{code}
...and the methods in question as defined by DescriptorNamespace are:
{code}
public T addDefaultNamespaces();
public T addNamespace(String name, String value);
public List<String> getNamespaces();
public T removeAllNamespaces();{code}
Note that Ralf's work in SHRINKDESC-21 also splits this into DescriptorNamespace and
DescriptorMutableNamespace.
My feeling is that neither should be part of the API; maybe SPI or just internals.
Discuss if it's appropriate to remove this and break the backwards-compatibility with
the 1.x series. In this case, I'm willing to entertain this exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:52 p.m.
[
https://issues.jboss.org/browse/SHRINKDESC-113?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKDESC-113:
--------------------------------------------
Perhaps instead of "Freezing" the namespaces we instead allow them to be mutable
only in the Descriptor mutable view?
Move DescriptorNamespace out of the Public API
----------------------------------------------
Key: SHRINKDESC-113
URL: https://issues.jboss.org/browse/SHRINKDESC-113
Project: ShrinkWrap Descriptors
Issue Type: Task
Reporter: Andrew Rubinger
Assignee: Andrew Rubinger
This needs some discussion before being done. It'd break backwards-compatibility
with the 1.x series.
DescriptorNamespace is mutable, which conflicts with the goals outlined in SHRINKDESC-21.
We're not really testing its direct usage at the moment, and I wonder what reason
end-users would have to be invoking its operations to muck around with the
"namespace" of a domain object. Currently all descriptors are supporting its
operations by extension:
{code}public interface WebAppDescriptor extends Descriptor,
DescriptorNamespace<WebAppDescriptor>{code}
...and the methods in question as defined by DescriptorNamespace are:
{code}
public T addDefaultNamespaces();
public T addNamespace(String name, String value);
public List<String> getNamespaces();
public T removeAllNamespaces();{code}
Note that Ralf's work in SHRINKDESC-21 also splits this into DescriptorNamespace and
DescriptorMutableNamespace.
My feeling is that neither should be part of the API; maybe SPI or just internals.
Discuss if it's appropriate to remove this and break the backwards-compatibility with
the 1.x series. In this case, I'm willing to entertain this exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5089
days inactive
5107
days old
shrinkwrap-issues@lists.jboss.org
4 comments
4 participants
participants (4)
-
Andrew Rubinger (JIRA) -
Dan Allen (JIRA)
-
Ken Finnigan (JIRA)
-
Ralf Battenfeld (JIRA)