You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Felipe Leme <ja...@felipeal.net> on 2005/07/11 05:01:49 UTC

[VOTE] Future of the Jakarta Taglibs Project

Hi all,

As you know, there's been a proposal on general@jakarta to create a 
Jakarta sub-project (whose name haven't been decided yet) to provide 
web-related Java components (such as filters, servlets and taglibs).

Given the current status of the Jakarta Taglibs Project - where there 
isn't much going on by the committers, most of the activities are 
JSTL-related user questions or issues with the sandbox taglibs - it has 
been also discussed if the Taglibs project should be merged with this 
new project.

So, I'd like to officially call that vote:

[ ] +1 - merge Jakarta Taglibs Project into this new project
[ ] -1 - no, let's keep Jakarta Taglibs Project as is
[ ] -1 - let's wait the new project be officially created/incubated
[ ] +0 - whatever
[ ] ?? - <<put your comment here>>


In case the +1s win, we have do decide some issues, such as:

1.Jakarta Standard Taglibs should be a project of its own, given the 
fact that it produces standard, JCP-compliant taglibs and as such have 
peculiar characteristics.

[ ] +1 let's create a new project for these taglibs
[ ] -1 please, leave it with us wherever we go
[ ] -0 dude, the +1 didn't win the first vote, so we are not merging
[ ] ?? - <<put your comment here>>

2.What about the other taglibs? Should we migrate them as is to the new 
project or should we leave them behind and create new taglibs from 
scratch (reusing existing code, of course)?

2.1 [ ] migrate all of them
2.2 [ ] leave them behind (on a read-only SVN access, with the latest 
releases, etc..) and let's create new ones from scratch - that would 
give us a chance to refactor the existing code.
2.3 [ ] it's too early to decide that
2.? [ ] <<put your comment here>>

If 2.1 wins, I guess we can just move the SVN code to the new project 
(once it's created) and evolve from there. But if 2.2 wins, we still 
have at least one more issue to decide (I hope that won't be a bias for 
people to vote on 2.1 :-):

2.2.1 Last releases

[ ] +1 release a final version for each existing taglib (and a 1.0 for 
those never released) before "closing the doors"
[ ] -1 no, leave them as is - we better do the new releases in the new 
projects
[ ] ?? - explain why


Finally, there are other issues that we will need to handle after the 
merge (*if* we merge), such as if the committers will be 'migrated' as 
well, what to do with the taglibs that are overlapped by JSTL, should we 
change the way the documentation and TLDs are generated, etc - but let's 
focus on the issues above for now.


-- Felipe










---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org


Re: [VOTE] Future of the Jakarta Taglibs Project

Posted by Henri Yandell <fl...@gmail.com>.
On 7/10/05, Felipe Leme <ja...@felipeal.net> wrote:
> Oops, forgot my votes...
> 
> 
> Felipe Leme wrote:
> 
> > [X] +1 - merge Jakarta Taglibs Project into this new project

+1, but slightly different in that we should move taglibs individually
over to the new project rather than the whole lot. We should only move
active ones over at first, and then later ones that are dormant (but
still have good reason to exist).

> > 1.Jakarta Standard Taglibs should be a project of its own, given the

+1, subproject of Jakarta

> > 2.What about the other taglibs? Should we migrate them as is to the new
> 
> > 2.2 [X] leave them behind (on a read-only SVN access, with the latest
> > releases, etc..) and let's create new ones from scratch - that would
> 
> > 2.2.1 Last releases
> >
> > [X] +1 release a final version for each existing taglib (and a 1.0 for
> > those never released) before "closing the doors"

-0. Don't see why they need to have a final taglibs release, provided
the versions in the new subproject follow the same contract etc.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org


Re: [VOTE] Future of the Jakarta Taglibs Project

Posted by Felipe Leme <ja...@felipeal.net>.
Oops, forgot my votes...


Felipe Leme wrote:

> [X] +1 - merge Jakarta Taglibs Project into this new project

> 1.Jakarta Standard Taglibs should be a project of its own, given the 

> [X] +1 let's create a new project for these taglibs

> 2.What about the other taglibs? Should we migrate them as is to the new 

> 2.2 [X] leave them behind (on a read-only SVN access, with the latest 
> releases, etc..) and let's create new ones from scratch - that would 

> 2.2.1 Last releases
> 
> [X] +1 release a final version for each existing taglib (and a 1.0 for 
> those never released) before "closing the doors"

PS: by existing taglib, I mean existing taglib that have had changes on 
the CVS code since the last release...

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org


Re: [VOTE] Future of the Jakarta Taglibs Project

Posted by Sam Ruby <ru...@apache.org>.
Justyna Horwat wrote:
> 
> I agree with Henri about moving only the active projects at first. That 
> way we would make sure that we have the community support for those 
> projects. We can then move other taglibs on an interest and support basis.

+1

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org


Re: [VOTE] Future of the Jakarta Taglibs Project

Posted by Justyna Horwat <ho...@horwat.com>.
> [ X] +1 - merge Jakarta Taglibs Project into this new project
> [X ] +1 let's create a new project for these taglibs
> 2.2 [X ] leave them behind (on a read-only SVN access, with the latest 
> releases, etc..) and let's create new ones from scratch - that would 
> give us a chance to refactor the existing code
  [X ] +1 release a final version for each existing taglib (and a 1.0 
for those never released) before "closing the doors"

If there are any changes to the taglibs since the last release then we 
should do one final release before "closing the doors". If we don't do 
so then these updates may be lost. We should also do the 1.0 release 
for unreleased taglibs since that will allow us to use that release as 
a basis from when the migration to the new project occurred.

I agree with Henri about moving only the active projects at first. That 
way we would make sure that we have the community support for those 
projects. We can then move other taglibs on an interest and support 
basis.

Thanks,

Justyna

On Jul 10, 2005, at 8:01 PM, Felipe Leme wrote:

> Hi all,
>
> As you know, there's been a proposal on general@jakarta to create a 
> Jakarta sub-project (whose name haven't been decided yet) to provide 
> web-related Java components (such as filters, servlets and taglibs).
>
> Given the current status of the Jakarta Taglibs Project - where there 
> isn't much going on by the committers, most of the activities are 
> JSTL-related user questions or issues with the sandbox taglibs - it 
> has been also discussed if the Taglibs project should be merged with 
> this new project.
>
> So, I'd like to officially call that vote:
>
> [ ] +1 - merge Jakarta Taglibs Project into this new project
> [ ] -1 - no, let's keep Jakarta Taglibs Project as is
> [ ] -1 - let's wait the new project be officially created/incubated
> [ ] +0 - whatever
> [ ] ?? - <<put your comment here>>
>
>
> In case the +1s win, we have do decide some issues, such as:
>
> 1.Jakarta Standard Taglibs should be a project of its own, given the 
> fact that it produces standard, JCP-compliant taglibs and as such have 
> peculiar characteristics.
>
> [ ] +1 let's create a new project for these taglibs
> [ ] -1 please, leave it with us wherever we go
> [ ] -0 dude, the +1 didn't win the first vote, so we are not merging
> [ ] ?? - <<put your comment here>>
>
> 2.What about the other taglibs? Should we migrate them as is to the 
> new project or should we leave them behind and create new taglibs from 
> scratch (reusing existing code, of course)?
>
> 2.1 [ ] migrate all of them
> 2.2 [ ] leave them behind (on a read-only SVN access, with the latest 
> releases, etc..) and let's create new ones from scratch - that would 
> give us a chance to refactor the existing code.
> 2.3 [ ] it's too early to decide that
> 2.? [ ] <<put your comment here>>
>
> If 2.1 wins, I guess we can just move the SVN code to the new project 
> (once it's created) and evolve from there. But if 2.2 wins, we still 
> have at least one more issue to decide (I hope that won't be a bias 
> for people to vote on 2.1 :-):
>
> 2.2.1 Last releases
>
> [ ] +1 release a final version for each existing taglib (and a 1.0 for 
> those never released) before "closing the doors"
> [ ] -1 no, leave them as is - we better do the new releases in the new 
> projects
> [ ] ?? - explain why
>
>
> Finally, there are other issues that we will need to handle after the 
> merge (*if* we merge), such as if the committers will be 'migrated' as 
> well, what to do with the taglibs that are overlapped by JSTL, should 
> we change the way the documentation and TLDs are generated, etc - but 
> let's focus on the issues above for now.
>
>
> -- Felipe
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org


Re: [RESULT] Future of the Jakarta Taglibs Project

Posted by Rahul P Akolkar <ak...@us.ibm.com>.
Felipe Leme <ja...@felipeal.net> wrote on 08/07/2005 10:25:28 PM:
<snip/>
> Proposal 4: Release a final version for each existing taglib left behind
> 
> 2 +1 (Felipe Leme, Justyna Horwart, Abey Mullassery)
<snap/>

You meant 3.

<snip/> 
> PS: sorry for the delay on sending the results, but I've been offline in 

> the last weeks as I just moved to a new house
<snap/>

Congratulations!

-Rahul

[RESULT] Future of the Jakarta Taglibs Project

Posted by Felipe Leme <ja...@felipeal.net>.
Hi again,

Here are the results for my [VOTE] proposal:


Proposal 1: merge Jakarta Taglibs Project into this new project

5 +1 (Felipe Leme, Henri Yandell, Justyna Horwart, Martin Cooper, Abey 
Mullassery)
1 +0 (Rahul Akolkar)

Notes: Hen said that we should move taglibs individually over to the new 
project rather than the whole lot; Justina and Sam agreed

Conclusion: approved


Proposal 2: Jakarta Standard Taglibs should be a project of its ow

6 +1 (Felipe Leme, Henri Yandell, Justyna Horwart, Martin Cooper, Abey 
Mullassery, Rahul Akolkar)

Conclusion: approved

Proposal 3: leave the other (than Standard) taglibs behind (i.e., leave 
the code on CVS/SVN and create new taglibs from scratch)

6 +1 (Felipe Leme, Henri Yandell, Justyna Horwart, Martin Cooper, Abey 
Mullassery, Rahul Akolkar)

Conclusion: approved

Proposal 4: Release a final version for each existing taglib left behind

2 +1 (Felipe Leme, Justyna Horwart, Abey Mullassery)
1 -0 (Henri Yandell)
2 -1 (Rahul Akolkar, Martin Cooper)

Conclusion: inconclusive :-(

So, I'm sending a message to the PMC stating that we decided that:

1.The Jakarta Taglibs Project would like to be merged into the new 
Jakarta Web Commons (or whatever its named) project
2.The Jakarta Standard Taglib should be a project of its own
3.The remaining taglibs would be gradually migrated to the new project, 
the most actives first
4.It's not decided yet if the migrated taglibs would have a newer 
release prior to the migration

Finally, there is one thing that worries me at this moment: looks like 
the new project is dormant, at least I haven't seen any message in the 
General@Jakarta for a while. Hopefully this message will wake it up...

Regards,

Felipe

PS: sorry for the delay on sending the results, but I've been offline in 
the last weeks as I just moved to a new house

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org


Re: [VOTE] Future of the Jakarta Taglibs Project

Posted by Martin Cooper <ma...@apache.org>.

On Mon, 11 Jul 2005, Felipe Leme wrote:

> [X] +1 - merge Jakarta Taglibs Project into this new project
> [ ] -1 - no, let's keep Jakarta Taglibs Project as is
> [ ] -1 - let's wait the new project be officially created/incubated
> [ ] +0 - whatever
> [ ] ?? - <<put your comment here>>

> [X] +1 let's create a new [Jakarta sub-]project for these taglibs
> [ ] -1 please, leave it with us wherever we go
> [ ] -0 dude, the +1 didn't win the first vote, so we are not merging
> [ ] ?? - <<put your comment here>>

> 2.1 [ ] migrate all of them
> 2.2 [X] leave them behind (on a read-only SVN access, with the latest 
> releases, etc..) and let's create new ones from scratch - that would give us 
> a chance to refactor the existing code.
> 2.3 [ ] it's too early to decide that
> 2.? [ ] <<put your comment here>>

> [ ] +1 release a final version for each existing taglib (and a 1.0 for those 
> never released) before "closing the doors"
> [X] -1 no, leave them as is - we better do the new releases in the new 
> projects
> [ ] ?? - explain why

The problem I have with doing "final" releases before moving them is that 
such releases would be entirely artificial. There may not be any coherent 
set of functionality to define such a release. Worse, creating a release 
for taglibs that have not been released before sets a precedent, and nails 
down an API we might not want to keep. Finally, it involves work for not 
good reason.

Nothing will be lost in moving from Taglibs to the new project, since it 
will almost certainly be accomplished via an 'svn move', so I see no good 
reason to insert this artificial step into the process.

--
Martin Cooper

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org