You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by CD...@hannaford.com on 2007/04/13 11:38:25 UTC
Adding JSR-286 API jar to a Maven repository
Hi all,
As part of the development of the JSR-286 Reference Implementation, a copy
of the portlet API jar (found here:
http://ipc658.inf-swt.uni-jena.de/spec/JSR%202.0%20API/lib/) needs to be
deployed to a Maven 2 repository. I was wondering which repository should
I use for this purpose? Should it be the pluto-staging or apache.snapshot
repository noted in the root pom.xml file or somewhere else?
I also need to know what is the appropriate naming convention to use for
this file (i.e. the version element in the pom.xml). The current
portlet-2.0.jar is based on the Early Draft 2, Revision 13 of the JSR-286
spec, so it seems like the version element value should be something like
'2.0-ED2-Rev13'. I'm not sure if we need to append 'SNAPSHOT' to this
version value. Please advise?
I am assuming that the groupId would be javax.portlet and the artifactId
would be portlet-api for this file as is now the case for the
portlet-1.0.jar file that contains the JSR-168 API.
/Craig
Re: Adding JSR-286 API jar to a Maven repository
Posted by Stefan Hepper <st...@apache.org>.
After discussing this with Torsten I think the simplest way to resolve
this is to put the source files into the pluto repository with the
additional notice that these are non-final and may change (see the
updated jira comment from Torsten)
Hope this works for everybody.
Stefan
Carsten Ziegeler wrote:
> Ate Douma wrote:
>
>> Carsten Ziegeler wrote:
>>> Stefan Hepper wrote:
>>>>>>
>>>> Not sure what was decided here...
>>>>
>>>> As long as the jar file is marked as draft version of JSR 286 I
>>>> don't have any issues with putting them in a Apache repository.
>>>> Once the JSR 286 is final and approved we plan to submit the source
>>>> code of the files under the Apache license to the pluto project,
>>>> like we did with JSR 168.
>>>>
>>> As the code is currently not Apache, it seems a little bit strange
>>> to put this into an Apache repository. It's not an Apache release or
>>> a snapshot of an Apache project right now.
>>> So what about putting it into the official maven repository?
>> I think we might be very careful with doing that if even allowed,
>> e.g. it should be made very clear this will not be an official, ASF
>> endorsed released artifact, draft or not.
> Absolutely, that's why I think it shouldn't be "us" (= pluto) doing
> this, but ibm or the university of jena.
>
>> But by simply putting the jar in the official maven repository, with
>> all the required license and notice files etc. already in place might
>> easily give the impression it *is* an ASF endorsed artifact.
> There should be a clear notice in it which gives the correct impression.
>>
>> I wonder though why the api is needed to be "released" already at the
>> moment.
>> AFAIK, its mainly used/needed for the pluto JSR-286 branch, and for
>> that one can easily check it out and build the whole branch, there's
>> no need to have the api jar available in a remote repository for
>> that, and I would suggest not to bother with it right now.
> True - and it's the easiest and simplest solution for now.
>
> Carsten
>>
>> Ate
>>
>>> Carsten
>>> --Carsten Ziegeler
>>
>
> --
> Carsten Ziegeler
>
>
>
>
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Carsten Ziegeler <cz...@apache.org>.
Ate Douma wrote:
> Carsten Ziegeler wrote:
>> Stefan Hepper wrote:
>>>>>
>>> Not sure what was decided here...
>>>
>>> As long as the jar file is marked as draft version of JSR 286 I
>>> don't have any issues with putting them in a Apache repository.
>>> Once the JSR 286 is final and approved we plan to submit the
>>> source code of the files under the Apache license to the pluto
>>> project, like we did with JSR 168.
>>>
>> As the code is currently not Apache, it seems a little bit strange
>> to put this into an Apache repository. It's not an Apache release
>> or a snapshot of an Apache project right now.
>> So what about putting it into the official maven repository?
> I think we might be very careful with doing that if even allowed,
> e.g. it should be made very clear this will not be an official, ASF
> endorsed released artifact, draft or not.
Absolutely, that's why I think it shouldn't be "us" (= pluto) doing
this, but ibm or the university of jena.
> But by simply putting the jar in the official maven repository,
> with all the required license and notice files etc. already in
> place might easily give the impression it *is* an ASF endorsed
> artifact.
There should be a clear notice in it which gives the correct impression.
>
> I wonder though why the api is needed to be "released" already at
> the moment.
> AFAIK, its mainly used/needed for the pluto JSR-286 branch, and for
> that one can easily check it out and build the whole branch,
> there's no need to have the api jar available in a remote
> repository for that, and I would suggest not to bother with it
> right now.
True - and it's the easiest and simplest solution for now.
Carsten
>
> Ate
>
>> Carsten
>> --
>> Carsten Ziegeler
>
--
Carsten Ziegeler
Re: Adding JSR-286 API jar to a Maven repository
Posted by Ate Douma <at...@douma.nu>.
Carsten Ziegeler wrote:
>
> Stefan Hepper wrote:
>
>>>>
>> Not sure what was decided here...
>>
>> As long as the jar file is marked as draft version of JSR 286 I don't
>> have any issues with putting them in a Apache repository.
>> Once the JSR 286 is final and approved we plan to submit the source
>> code of the files under the Apache license to the pluto project, like
>> we did with JSR 168.
>>
> As the code is currently not Apache, it seems a little bit strange to
> put this into an Apache repository. It's not an Apache release or a
> snapshot of an Apache project right now.
>
> So what about putting it into the official maven repository?
I think we might be very careful with doing that if even allowed, e.g. it should be made very clear this will not be an official, ASF endorsed released
artifact, draft or not.
But by simply putting the jar in the official maven repository, with all the required license and notice files etc. already in place might easily give the
impression it *is* an ASF endorsed artifact.
I wonder though why the api is needed to be "released" already at the moment.
AFAIK, its mainly used/needed for the pluto JSR-286 branch, and for that one can easily check it out and build the whole branch, there's no need to have the api
jar available in a remote repository for that, and I would suggest not to bother with it right now.
Ate
>
> Carsten
> --
> Carsten Ziegeler
>
>
>
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefan Hepper wrote:
>>>
> Not sure what was decided here...
>
> As long as the jar file is marked as draft version of JSR 286 I
> don't have any issues with putting them in a Apache repository.
> Once the JSR 286 is final and approved we plan to submit the source
> code of the files under the Apache license to the pluto project,
> like we did with JSR 168.
>
As the code is currently not Apache, it seems a little bit strange to
put this into an Apache repository. It's not an Apache release or a
snapshot of an Apache project right now.
So what about putting it into the official maven repository?
Carsten
--
Carsten Ziegeler
Re: Adding JSR-286 API jar to a Maven repository
Posted by Stefan Hepper <st...@apache.org>.
Ralph Goers wrote:
> Stefan Hepper wrote:
>> Ralph Goers wrote:
>>
>>> We also have a requirement to have our theme process some portlets
>>> differently than others. Ideally, a portlet (and pages for that
>>> matter) should be able to have attributes associated with them in
>>> the portlet.xml that the theme can interrogate.
>>>
>> The portlet can do this today: it can set things as init params in
>> the portlet.xml or as response properties at runtime.
> I don't recall reading how those are made available to the theme.
Given that themes are not part of JSR 286 this will be vendor specific.
>>> We also have to share attributes between portlets and several
>>> servlets. Our current vendor supports this including in servlet
>>> filters in front of the portal. I haven't read the spec in a draft
>>> or two, but I assume sharing is still limited to shared render
>>> parameters. I have no idea why this limitation exists. I heard
>>> something about it being not implementable in all containers, but
>>> that doesn't make sense since the portal we are using runs in
>>> virtually every container.
>>>
>> No, the spec does not limit the sharing of parameters to only
>> portlets, but on the other side, how would a portal implementation
>> know that a URL targeted to a servlet should contain the current
>> shared render parameters?
> Our portal requires that shared parameters be namespaced and the
> portal be configured with the namespaces to share. They are available
> to everything (including action requests). This may not be ideal but
> it is better than nothing. We end up having to leverage our vendor's
> post login hook and then store our data in the servlet session.
>>> In short, the spec allows me to build fairly simple portlets but is
>>> completely deficient in when it comes to building applications made
>>> up of groups of related portlets.
>>>
>> I completely disagree with that assessment. If you have a loosely
>> coupled portlet component model in your mind JSR 286 will provide you
>> with many things to create really complex applications based on
>> different portlets in different portlet apps.
>> If you expect that JSR 286 will provide you a model where you can
>> create larger, pre-packaged apps that consists of pages, portlets on
>> the pages, wires between these portlets, and themes for these pages,
>> I agree that JSR 286 will not help you here and you need vendor
>> extensions for now. On the other hand you get this JSR by end of this
>> year instead of end of 2009....
> To give you a perspective, the application is for online banking. Each
> of the portlets provides different functionality. However, many of the
> portlets share the user's account information, etc. Some information,
> such as the list of accounts, current balance, etc. needs to be
> retrieved during login and then shared across all the portlets. From a
> portal perspective it isn't an extraordinarily complex application. We
> have several portlets on one page that all need access to an account's
> history for some number of days so they can do various things with it.
> This kind of stuff is very messy to do with the current portlet spec
> and 286 doesn't seem to help much. Having to be tied to one vendor is
> a problem as it makes it difficult to sell the product to larger
> banks, which presumably would prefer to use the portal of their choosing.
>
One implementation that works with JSR 286 is that you register for the
navigationalContextChange event, trigger that event when the page is
loaded the first time, set the customer id as a shared render parameter.
For providing the account history to different portlets you would create
a service that would retrieve this once and cache it and this service
can be called by different portlets.
> Obviously, I don't want to wait until 2009 - but it sure sounds like
> I'm going to have to wait anyway. Frankly, there are only a few items
> in 286 that are of interest to me, such as support for fragments. For
> example, I already have portlet filters using Spring. So I'd gladly
> wait 6 more months to get some of these larger issues dealt with.
>
What you are asking for takes at least two more years of discussion, not
just 6 month.
Stefan
> Ralph
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Ralph Goers <Ra...@dslextreme.com>.
Stefan Hepper wrote:
> Ralph Goers wrote:
>> The discussion we had some months ago. I have application logic that
>> needs to be exercised upon login. Currently I can do this through my
>> portal vendors extensions. I also have several portlets on a page
>> that need to use the same initialization. The only way to do this now
>> is extremely clumsy as each portlet has to do it and check that it
>> hasn't already been completed. A better mechanism would have been to
>> provide a way to invoke a method when a page is accessed.
> As explained such page behavior is beyond the JSR 286 scope and would
> need to be addressed in a future version and then define a more
> complete page model.
I know. But I think that was my point. It is a feature that is missing
that I need today.
>> We also have a requirement to have our theme process some portlets
>> differently than others. Ideally, a portlet (and pages for that
>> matter) should be able to have attributes associated with them in the
>> portlet.xml that the theme can interrogate.
>>
> The portlet can do this today: it can set things as init params in the
> portlet.xml or as response properties at runtime.
I don't recall reading how those are made available to the theme.
>> We also have to share attributes between portlets and several
>> servlets. Our current vendor supports this including in servlet
>> filters in front of the portal. I haven't read the spec in a draft or
>> two, but I assume sharing is still limited to shared render
>> parameters. I have no idea why this limitation exists. I heard
>> something about it being not implementable in all containers, but
>> that doesn't make sense since the portal we are using runs in
>> virtually every container.
>>
> No, the spec does not limit the sharing of parameters to only
> portlets, but on the other side, how would a portal implementation
> know that a URL targeted to a servlet should contain the current
> shared render parameters?
Our portal requires that shared parameters be namespaced and the portal
be configured with the namespaces to share. They are available to
everything (including action requests). This may not be ideal but it is
better than nothing. We end up having to leverage our vendor's post
login hook and then store our data in the servlet session.
>> In short, the spec allows me to build fairly simple portlets but is
>> completely deficient in when it comes to building applications made
>> up of groups of related portlets.
>>
> I completely disagree with that assessment. If you have a loosely
> coupled portlet component model in your mind JSR 286 will provide you
> with many things to create really complex applications based on
> different portlets in different portlet apps.
> If you expect that JSR 286 will provide you a model where you can
> create larger, pre-packaged apps that consists of pages, portlets on
> the pages, wires between these portlets, and themes for these pages, I
> agree that JSR 286 will not help you here and you need vendor
> extensions for now. On the other hand you get this JSR by end of this
> year instead of end of 2009....
To give you a perspective, the application is for online banking. Each
of the portlets provides different functionality. However, many of the
portlets share the user's account information, etc. Some information,
such as the list of accounts, current balance, etc. needs to be
retrieved during login and then shared across all the portlets. From a
portal perspective it isn't an extraordinarily complex application. We
have several portlets on one page that all need access to an account's
history for some number of days so they can do various things with it.
This kind of stuff is very messy to do with the current portlet spec and
286 doesn't seem to help much. Having to be tied to one vendor is a
problem as it makes it difficult to sell the product to larger banks,
which presumably would prefer to use the portal of their choosing.
Obviously, I don't want to wait until 2009 - but it sure sounds like I'm
going to have to wait anyway. Frankly, there are only a few items in
286 that are of interest to me, such as support for fragments. For
example, I already have portlet filters using Spring. So I'd gladly
wait 6 more months to get some of these larger issues dealt with.
Ralph
Re: Adding JSR-286 API jar to a Maven repository
Posted by Stefan Hepper <st...@apache.org>.
Ralph Goers wrote:
> The discussion we had some months ago. I have application logic that
> needs to be exercised upon login. Currently I can do this through my
> portal vendors extensions. I also have several portlets on a page that
> need to use the same initialization. The only way to do this now is
> extremely clumsy as each portlet has to do it and check that it hasn't
> already been completed. A better mechanism would have been to provide
> a way to invoke a method when a page is accessed.
As explained such page behavior is beyond the JSR 286 scope and would
need to be addressed in a future version and then define a more complete
page model.
> We also have a requirement to have our theme process some portlets
> differently than others. Ideally, a portlet (and pages for that
> matter) should be able to have attributes associated with them in the
> portlet.xml that the theme can interrogate.
>
The portlet can do this today: it can set things as init params in the
portlet.xml or as response properties at runtime.
> We also have to share attributes between portlets and several
> servlets. Our current vendor supports this including in servlet
> filters in front of the portal. I haven't read the spec in a draft or
> two, but I assume sharing is still limited to shared render
> parameters. I have no idea why this limitation exists. I heard
> something about it being not implementable in all containers, but that
> doesn't make sense since the portal we are using runs in virtually
> every container.
>
No, the spec does not limit the sharing of parameters to only portlets,
but on the other side, how would a portal implementation know that a URL
targeted to a servlet should contain the current shared render parameters?
> In short, the spec allows me to build fairly simple portlets but is
> completely deficient in when it comes to building applications made up
> of groups of related portlets.
>
I completely disagree with that assessment. If you have a loosely
coupled portlet component model in your mind JSR 286 will provide you
with many things to create really complex applications based on
different portlets in different portlet apps.
If you expect that JSR 286 will provide you a model where you can create
larger, pre-packaged apps that consists of pages, portlets on the pages,
wires between these portlets, and themes for these pages, I agree that
JSR 286 will not help you here and you need vendor extensions for now.
On the other hand you get this JSR by end of this year instead of end of
2009....
Stefan
> Ralph
>
> Stefan Hepper wrote:
>> JSR 286 is in feature lock-down mode now. What use cases are you
>> referring too that cannot be done with JSR 286 involving several
>> portlets?
>>
>> Stefan
>>
>>
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Ralph Goers <Ra...@dslextreme.com>.
The discussion we had some months ago. I have application logic that
needs to be exercised upon login. Currently I can do this through my
portal vendors extensions. I also have several portlets on a page that
need to use the same initialization. The only way to do this now is
extremely clumsy as each portlet has to do it and check that it hasn't
already been completed. A better mechanism would have been to provide a
way to invoke a method when a page is accessed. We also have a
requirement to have our theme process some portlets differently than
others. Ideally, a portlet (and pages for that matter) should be able to
have attributes associated with them in the portlet.xml that the theme
can interrogate.
We also have to share attributes between portlets and several servlets.
Our current vendor supports this including in servlet filters in front
of the portal. I haven't read the spec in a draft or two, but I assume
sharing is still limited to shared render parameters. I have no idea why
this limitation exists. I heard something about it being not
implementable in all containers, but that doesn't make sense since the
portal we are using runs in virtually every container.
In short, the spec allows me to build fairly simple portlets but is
completely deficient in when it comes to building applications made up
of groups of related portlets.
Ralph
Stefan Hepper wrote:
> JSR 286 is in feature lock-down mode now. What use cases are you
> referring too that cannot be done with JSR 286 involving several
> portlets?
>
> Stefan
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Stefan Hepper <st...@apache.org>.
JSR 286 is in feature lock-down mode now. What use cases are you
referring too that cannot be done with JSR 286 involving several portlets?
Stefan
Ralph Goers wrote:
> I have a couple of thoughts
>
> 1. It doesn't seem kosher to have the jar in an open source project
> without the source that goes with it.
> 2. How close is JSR 286 to being done? I still have major issues with
> it as it is virtually impossible to build an application containing
> several portlets without resorting to portal specific enhancements.
> Ralph
>
> Stefan Hepper wrote:
>> Not sure what was decided here...
>>
>> As long as the jar file is marked as draft version of JSR 286 I don't
>> have any issues with putting them in a Apache repository.
>> Once the JSR 286 is final and approved we plan to submit the source
>> code of the files under the Apache license to the pluto project, like
>> we did with JSR 168.
>>
>> Stefan
>>
>>
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Ralph Goers <Ra...@dslextreme.com>.
I have a couple of thoughts
1. It doesn't seem kosher to have the jar in an open source project
without the source that goes with it.
2. How close is JSR 286 to being done? I still have major issues with
it as it is virtually impossible to build an application containing
several portlets without resorting to portal specific enhancements.
Ralph
Stefan Hepper wrote:
> Not sure what was decided here...
>
> As long as the jar file is marked as draft version of JSR 286 I don't
> have any issues with putting them in a Apache repository.
> Once the JSR 286 is final and approved we plan to submit the source
> code of the files under the Apache license to the pluto project, like
> we did with JSR 168.
>
> Stefan
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Stefan Hepper <st...@apache.org>.
Dettborn wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ate Douma schrieb:
>
>> Carsten Ziegeler wrote:
>>
>>> David H. DeWolf wrote:
>>>
>>>> The biggest question is probably concerning licensing and if we're
>>>> allowed to publish it. This may not be an issue, but it's
>>>> something we need to look into before we move forward.
>>>>
> Yes this will be a problem, under this point of view this will be a
> big problem. So there won't be so many api changes, so we can let it
> as it is.
>
>>> Yepp,
>>>
>>> I'm not sure why we have to deploy this into a public available
>>> repository? Shouldn't the api be just a module which is build
>>> during the
>>> whole build as well?
>>>
>> I agree, this shouldn't be made available in a public repository yet
>> and I also don't see any technical reason why it should.
>> You really would need to get clearance from IBM for that.
>>
>>
>>> For the version I guess '2.0-ED2-Rev13' is fine.
>>>
>> Yes, not SNAPSHOT for sure.
>>
Not sure what was decided here...
As long as the jar file is marked as draft version of JSR 286 I don't
have any issues with putting them in a Apache repository.
Once the JSR 286 is final and approved we plan to submit the source code
of the files under the Apache license to the pluto project, like we did
with JSR 168.
Stefan
Re: Adding JSR-286 API jar to a Maven repository
Posted by Dettborn <de...@web.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ate Douma schrieb:
> Carsten Ziegeler wrote:
>> David H. DeWolf wrote:
>>> The biggest question is probably concerning licensing and if we're
>>> allowed to publish it. This may not be an issue, but it's
>>> something we need to look into before we move forward.
Yes this will be a problem, under this point of view this will be a
big problem. So there won't be so many api changes, so we can let it
as it is.
>> Yepp,
>>
>> I'm not sure why we have to deploy this into a public available
>> repository? Shouldn't the api be just a module which is build
>> during the
>> whole build as well?
> I agree, this shouldn't be made available in a public repository yet
> and I also don't see any technical reason why it should.
> You really would need to get clearance from IBM for that.
>
>>
>> For the version I guess '2.0-ED2-Rev13' is fine.
> Yes, not SNAPSHOT for sure.
>
>>
>> Carsten
>>> CDoremus@hannaford.com wrote:
>>>> Hi all,
>>>>
>>>> As part of the development of the JSR-286 Reference
>>>> Implementation, a copy of the portlet API jar (found here:
>>>> http://ipc658.inf-swt.uni-jena.de/spec/JSR%202.0%20API/lib/)
>>>> needs to be deployed to a Maven 2 repository. I was wondering
>>>> which repository should I use for this purpose? Should it be the
>>>> pluto-staging or apache.snapshot repository noted in the root
>>>> pom.xml file or somewhere else?
>>>>
>>>> I also need to know what is the appropriate naming convention to
>>>> use for this file (i.e. the version element in the pom.xml). The
>>>> current portlet-2.0.jar is based on the Early Draft 2, Revision
>>>> 13 of the JSR-286 spec, so it seems like the version element
>>>> value should be something like '2.0-ED2-Rev13'. I'm not sure if
>>>> we need to append 'SNAPSHOT' to this version value. Please advise?
>>>>
>>>> I am assuming that the groupId would be javax.portlet and the
>>>> artifactId would be portlet-api for this file as is now the case
>>>> for the portlet-1.0.jar file that contains the JSR-168 API.
>>>> /Craig
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGIJiDwaBuBD/AhYARAixbAKDMFEoifGfSKBXH5JR0XdGU98XRQwCfVdAs
S96sUMHl1KjD/cAVXj8vwo4=
=/QNZ
-----END PGP SIGNATURE-----
Re: Adding JSR-286 API jar to a Maven repository
Posted by Ate Douma <at...@douma.nu>.
Carsten Ziegeler wrote:
> David H. DeWolf wrote:
>> The biggest question is probably concerning licensing and if we're
>> allowed to publish it. This may not be an issue, but it's something we
>> need to look into before we move forward.
> Yepp,
>
> I'm not sure why we have to deploy this into a public available
> repository? Shouldn't the api be just a module which is build during the
> whole build as well?
I agree, this shouldn't be made available in a public repository yet and I also don't see any technical reason why it should.
You really would need to get clearance from IBM for that.
>
> For the version I guess '2.0-ED2-Rev13' is fine.
Yes, not SNAPSHOT for sure.
>
> Carsten
>> CDoremus@hannaford.com wrote:
>>> Hi all,
>>>
>>> As part of the development of the JSR-286 Reference Implementation, a
>>> copy of the portlet API jar (found here:
>>> http://ipc658.inf-swt.uni-jena.de/spec/JSR%202.0%20API/lib/) needs to be
>>> deployed to a Maven 2 repository. I was wondering which repository
>>> should I use for this purpose? Should it be the pluto-staging or
>>> apache.snapshot repository noted in the root pom.xml file or somewhere
>>> else?
>>>
>>> I also need to know what is the appropriate naming convention to use for
>>> this file (i.e. the version element in the pom.xml). The current
>>> portlet-2.0.jar is based on the Early Draft 2, Revision 13 of the
>>> JSR-286 spec, so it seems like the version element value should be
>>> something like '2.0-ED2-Rev13'. I'm not sure if we need to append
>>> 'SNAPSHOT' to this version value. Please advise?
>>>
>>> I am assuming that the groupId would be javax.portlet and the artifactId
>>> would be portlet-api for this file as is now the case for the
>>> portlet-1.0.jar file that contains the JSR-168 API.
>>> /Craig
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Ralph Goers <Ra...@dslextreme.com>.
Since this isn't a formal release I would expect it to just be a
SNAPSHOT release.
Ralph
Carsten Ziegeler wrote:
> David H. DeWolf wrote:
>
>> The biggest question is probably concerning licensing and if we're
>> allowed to publish it. This may not be an issue, but it's something we
>> need to look into before we move forward.
>>
> Yepp,
>
> I'm not sure why we have to deploy this into a public available
> repository? Shouldn't the api be just a module which is build during the
> whole build as well?
>
> For the version I guess '2.0-ED2-Rev13' is fine.
>
> Carsten
>
>> CDoremus@hannaford.com wrote:
>>
>>> Hi all,
>>>
>>> As part of the development of the JSR-286 Reference Implementation, a
>>> copy of the portlet API jar (found here:
>>> http://ipc658.inf-swt.uni-jena.de/spec/JSR%202.0%20API/lib/) needs to be
>>> deployed to a Maven 2 repository. I was wondering which repository
>>> should I use for this purpose? Should it be the pluto-staging or
>>> apache.snapshot repository noted in the root pom.xml file or somewhere
>>> else?
>>>
>>> I also need to know what is the appropriate naming convention to use for
>>> this file (i.e. the version element in the pom.xml). The current
>>> portlet-2.0.jar is based on the Early Draft 2, Revision 13 of the
>>> JSR-286 spec, so it seems like the version element value should be
>>> something like '2.0-ED2-Rev13'. I'm not sure if we need to append
>>> 'SNAPSHOT' to this version value. Please advise?
>>>
>>> I am assuming that the groupId would be javax.portlet and the artifactId
>>> would be portlet-api for this file as is now the case for the
>>> portlet-1.0.jar file that contains the JSR-168 API.
>>> /Craig
>>>
>
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Elliot Metsger <em...@jhu.edu>.
I agree there may be licensing issues. As far as why publish the
artifact, I presume that individuals who want to try and write portlets
to the 2.0 api would need to depend on it in their poms.
Elliot
Carsten Ziegeler wrote:
> David H. DeWolf wrote:
>> The biggest question is probably concerning licensing and if we're
>> allowed to publish it. This may not be an issue, but it's something we
>> need to look into before we move forward.
> Yepp,
>
> I'm not sure why we have to deploy this into a public available
> repository? Shouldn't the api be just a module which is build during the
> whole build as well?
>
> For the version I guess '2.0-ED2-Rev13' is fine.
>
> Carsten
>> CDoremus@hannaford.com wrote:
>>> Hi all,
>>>
>>> As part of the development of the JSR-286 Reference Implementation, a
>>> copy of the portlet API jar (found here:
>>> http://ipc658.inf-swt.uni-jena.de/spec/JSR%202.0%20API/lib/) needs to be
>>> deployed to a Maven 2 repository. I was wondering which repository
>>> should I use for this purpose? Should it be the pluto-staging or
>>> apache.snapshot repository noted in the root pom.xml file or somewhere
>>> else?
>>>
>>> I also need to know what is the appropriate naming convention to use for
>>> this file (i.e. the version element in the pom.xml). The current
>>> portlet-2.0.jar is based on the Early Draft 2, Revision 13 of the
>>> JSR-286 spec, so it seems like the version element value should be
>>> something like '2.0-ED2-Rev13'. I'm not sure if we need to append
>>> 'SNAPSHOT' to this version value. Please advise?
>>>
>>> I am assuming that the groupId would be javax.portlet and the artifactId
>>> would be portlet-api for this file as is now the case for the
>>> portlet-1.0.jar file that contains the JSR-168 API.
>>> /Craig
>
>
Re: Adding JSR-286 API jar to a Maven repository
Posted by Carsten Ziegeler <cz...@apache.org>.
David H. DeWolf wrote:
> The biggest question is probably concerning licensing and if we're
> allowed to publish it. This may not be an issue, but it's something we
> need to look into before we move forward.
Yepp,
I'm not sure why we have to deploy this into a public available
repository? Shouldn't the api be just a module which is build during the
whole build as well?
For the version I guess '2.0-ED2-Rev13' is fine.
Carsten
>
> CDoremus@hannaford.com wrote:
>> Hi all,
>>
>> As part of the development of the JSR-286 Reference Implementation, a
>> copy of the portlet API jar (found here:
>> http://ipc658.inf-swt.uni-jena.de/spec/JSR%202.0%20API/lib/) needs to be
>> deployed to a Maven 2 repository. I was wondering which repository
>> should I use for this purpose? Should it be the pluto-staging or
>> apache.snapshot repository noted in the root pom.xml file or somewhere
>> else?
>>
>> I also need to know what is the appropriate naming convention to use for
>> this file (i.e. the version element in the pom.xml). The current
>> portlet-2.0.jar is based on the Early Draft 2, Revision 13 of the
>> JSR-286 spec, so it seems like the version element value should be
>> something like '2.0-ED2-Rev13'. I'm not sure if we need to append
>> 'SNAPSHOT' to this version value. Please advise?
>>
>> I am assuming that the groupId would be javax.portlet and the artifactId
>> would be portlet-api for this file as is now the case for the
>> portlet-1.0.jar file that contains the JSR-168 API.
>> /Craig
>
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: Adding JSR-286 API jar to a Maven repository
Posted by "David H. DeWolf" <dd...@apache.org>.
The biggest question is probably concerning licensing and if we're
allowed to publish it. This may not be an issue, but it's something we
need to look into before we move forward.
CDoremus@hannaford.com wrote:
>
> Hi all,
>
> As part of the development of the JSR-286 Reference Implementation, a
> copy of the portlet API jar (found here:
> http://ipc658.inf-swt.uni-jena.de/spec/JSR%202.0%20API/lib/) needs to be
> deployed to a Maven 2 repository. I was wondering which repository
> should I use for this purpose? Should it be the pluto-staging or
> apache.snapshot repository noted in the root pom.xml file or somewhere
> else?
>
> I also need to know what is the appropriate naming convention to use for
> this file (i.e. the version element in the pom.xml). The current
> portlet-2.0.jar is based on the Early Draft 2, Revision 13 of the
> JSR-286 spec, so it seems like the version element value should be
> something like '2.0-ED2-Rev13'. I'm not sure if we need to append
> 'SNAPSHOT' to this version value. Please advise?
>
> I am assuming that the groupId would be javax.portlet and the artifactId
> would be portlet-api for this file as is now the case for the
> portlet-1.0.jar file that contains the JSR-168 API.
> /Craig